Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

X86 MMU fault handling is turing complete

github.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: X86 MMU fault handling is turing complete

#21

Post by jbangert »

mikeash wrote: post #14
calt wrote: post #11

Earlier quoted context omitted.

> how did they record the youtube video? By running it on a physical machine. Unless there is a requirement that the processor not be multitasking that I am missing.

The Life video pretty clearly shows it running in Bochs. I assume they fixed it up.

Author here: Actually, the slide 'no publically available simulator implements this correctly' is somewhat misleading (it had a follow up slide that I cut and replaced by verbal comments - I should re-add it to the PDF). What I meant is that the entire mechanism (Task switching, page fault handling, etc.) is not implemented correctly on any sim, i.e. you have subtly different behavior. This was quite a challenge in debugging this in the first place, so I actually wrote the code to work around any bochs quirks I encountered -- just so that I have a debug environment.

Re: X86 MMU fault handling is turing complete

#22

Post by ithkuil »

phyalow wrote: post #18
duaneb wrote: post #15

Earlier quoted context omitted.

You can't see the code, but surely it can't do anything useful—i.e. change anything outside its extremely limited memory.

If you read through the slides @ https://github.com/jbangert/trapcc/blob/master/slides/PFLA-s... there is potential to bypass hardware memory protection. Very interesting.

well, that's misleading.

The spec says "don't put a tss cross page boundary". This might also have been the case in some x86 implementations, but surely they fixed that once that hardware virtualization was implemented.

They actually depend on the sane behavior: they trigger the double fault when the cpu spills the tss across a page boundary.

They mention the manual because according to the manual their idea wouldn't work, but it does.

Then they also say "We should test it", and the result of the test is "CPU translates DWORD by DWORD" (i.e. doesn't miss a byte^H^H^H^Hword) And then a nice kitty to show how relieved they were from the good news! No dragons in the way.

--

(Unless I got all wrong, but this topic is not the simplest one to reverse engineer from some slides, did anybody find a presentation video? It would really help to hear somebody commenting those slides, otherwise is a nested puzzle. And where is the patched qemu so one can play with that?)

Re: X86 MMU fault handling is turing complete

#23

Post by jbangert »

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.

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.

Re: X86 MMU fault handling is turing complete

#25

Post by jbangert »

ithkuil wrote: post #22
phyalow wrote: post #18

Earlier quoted context omitted.

If you read through the slides @ https://github.com/jbangert/trapcc/blob/master/slides/PFLA-s... there is potential to bypass hardware memory protection. Very interesting.

well, that's misleading. The spec says "don't put a tss cross page boundary". This might also have been the case in some x86 implementations, but surely they fixed that once that hardware virtualization was implemented. They actually depend on the sane behavior: they trigger the double fault when the cpu spills the tss across a page boundary. They mention the manual because according to the manual their idea wouldn't…

Shmoocon will release the video of the presentation in a bit, until then here is our talk at CCC http://www.youtube.com/watch?v=NGXvJ1GKBKM

Re: X86 MMU fault handling is turing complete

#26

Post by jbangert »

0x0 wrote: post #19
phyalow wrote: post #18

Earlier quoted context omitted.

If you read through the slides @ https://github.com/jbangert/trapcc/blob/master/slides/PFLA-s... there is potential to bypass hardware memory protection. Very interesting.

I must have missed the limited ram access when I browsed the slides the first time, I just assumed the youtube Game of Life proved they were poking ascii 'X' chars into video ram at 0xb8000 or whatever. Is there a trick/cheat to how that visualization was done? Edit: browsed around the code some more and it seems the ascii visualization stuff is done in regular c/asm polling the "virtual game of life" mem(?)

Yes, there is a cheat, it moves values from RAM to VGA ...

Re: X86 MMU fault handling is turing complete

#28

Post by 0x0 »

jbangert wrote: post #26
0x0 wrote: post #19

Earlier quoted context omitted.

I must have missed the limited ram access when I browsed the slides the first time, I just assumed the youtube Game of Life proved they were poking ascii 'X' chars into video ram at 0xb8000 or whatever. Is there a trick/cheat to how that visualization was done? Edit: browsed around the code some more and it seems the ascii visualization stuff is done in regular c/asm polling the "virtual game of life" mem(?)

Yes, there is a cheat, it moves values from RAM to VGA ...

Thanks for clarifying, still extremely impressive!

I wonder if you'll receive any fun comments from Intel/AMD/etc. :)

Re: X86 MMU fault handling is turing complete

#30

Post by sounds »

jbangert wrote: post #23

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 an…

"memory access is extremely limited (essentially one DWORD per page" – referring to non-code addresses, yes? In the current (simplest) implementation, each instruction (a TSS) must be aligned across a page boundary. You do comment below that altering alignment could increase the available code space.

I'm wondering what method PFLA uses to read/write non-code addresses. Only one address per page can be addressed? I'll take a look at the compiler.

By simply expanding the addressing capability, a very tiny program could emulate an instruction stream from memory, overcoming the limited code space (at the cost of execution speed).

Cheers!

Post reply on HN