TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

X86 MMU fault handling is turing complete

417 点作者 mman超过 12 年前

11 条评论

tptacek超过 12 年前
This is more or less the greatest thing I've learned about in the last couple years.<p>What's happening here is that they're getting computation <i>without executing any instructions</i>, simply through the process of using the MMU hardware to "resolve addresses". The page directory system has been set up in such a way that address resolution effects a virtual machine that they can code to.<p>This works because when you attempt to resolve an invalid address, the CPU generates a trap (#PF), and the handling of that trap pushes information on the "stack". Each time you push data to the stack, you decrement the stack pointer. Eventually, the stack pointer underflows; when that happens, a different trap (#DF) fires. This mechanism put together gives you:<p><pre><code> if x &#60; 4 { goto b } else { x = x - 4 ; goto a } </code></pre> also known as "subtract and branch if less than or equal to zero", also known as "an instruction adequate to construct a one-instruction computer".<p>The virtual machine "runs" by generating an unending series of traps: in the "goto a" case, the result of translation is another address generating a trap. And so on.<p>The details of how this computer has "memory" and addresses instructions is even headachier. They're using the x86 TSS as "memory" and for technical reasons they get 16 slots (and thus instructions) to work with, but they have a compiler that builds arbitrary programs into 16-colored graphs to use those slots to express generic programs. Every emulator they could find crashes when they abuse the hardware task switching system this way.<p>Here's it running Conway's Life:<p><a href="http://youtubedoubler.com/?video1=E2VCwBzGdPM&#38;start1=0&#38;video2=eSRcvrVs5ug&#38;start2=0&#38;authorName=FAV" rel="nofollow">http://youtubedoubler.com/?video1=E2VCwBzGdPM&#38;start1=0&#...</a><p>Here's their talk for a few months back:<p><a href="http://www.youtube.com/watch?v=NGXvJ1GKBKM" rel="nofollow">http://www.youtube.com/watch?v=NGXvJ1GKBKM</a><p>The talk is great, but if you're not super interested in X86/X64 memory corruption countermeasures, you might want to skip the first 30 minutes.
评论 #5262039 未加载
评论 #5261835 未加载
评论 #5263305 未加载
jbangert超过 12 年前
Author here: While it is true that with the current implementation, memory access is extremely limited (essentially one DWORD per page, or about 0.1% of the available physical RAM) that limitation can certainly be avoided. For one, you could shift how the TSS is aligned (and align them differently for different instructions), multiplying your address space by a factor of 10 or so. Furthermore, you could also place another TSS somewhere in memory (only a few of the variables need to actually contain sane values) with an invalid EIP and use that as a 'load' instruction.<p>The easiest way however would be to use the TrapCC mechanism to transfer control between bits of normal assembler code (perhaps repurposed from other functions already in your kernel), doing something similar to ROP. Of course, for additional fun, feel free to throw in BX's Brainfuck interpreter in ELF and James Oakley's DWARF exception handler. We might drop a demo of this soon, i.e. implementing a self-decrypting binary via page faults.
评论 #5263070 未加载
networked超过 12 年前
&#62;Move, Branch if Zero, Decrement<p>This is basically the canonical instruction for OISCs (one instruction set computers). Wikipedia describes it pretty well: <a href="https://en.wikipedia.org/wiki/One_instruction_set_computer#Subtract_and_branch_if_less_than_or_equal_to_zero" rel="nofollow">https://en.wikipedia.org/wiki/One_instruction_set_computer#S...</a>.
majke超过 12 年前
There was a talk on 29c3 about this. Abstract:<p><a href="https://events.ccc.de/congress/2012/Fahrplan/events/5265.en.html" rel="nofollow">https://events.ccc.de/congress/2012/Fahrplan/events/5265.en....</a><p>video:<p><a href="https://www.youtube.com/watch?v=NGXvJ1GKBKM" rel="nofollow">https://www.youtube.com/watch?v=NGXvJ1GKBKM</a>
codex超过 12 年前
Another place for root kits to hide.
评论 #5261959 未加载
评论 #5262253 未加载
评论 #5261808 未加载
ars超过 12 年前
How fast (slow) is this relative to the host CPU?
评论 #5263709 未加载
rocky1138超过 12 年前
This is really interesting. In a way, it's a form of computer self-replication. Could the virtual machine created by the computer be considered offspring?<p>Is there a way the virtual machine might spawn another virtual machine child of its own?
ithkuil超过 12 年前
if you like this kind of things there is also:<p><a href="http://www.cs.dartmouth.edu/~bx/elf-bf-tools/slides/ELF-berlinsides-0x3.pdf" rel="nofollow">http://www.cs.dartmouth.edu/~bx/elf-bf-tools/slides/ELF-berl...</a>
traxtech超过 12 年前
That the hardware version of the brainfuck philosophy.
评论 #5267204 未加载
conductor超过 12 年前
Expect this technique in the future malwares and software protection DRM systems for making code analyzing harder.
general_failure超过 12 年前
somebody checked in vim backup files :-)