Live data from Hacker News

X86 MMU fault handling is turing complete

github.com

11–20 of 41 posts

Re: X86 MMU fault handling is turing complete

#11
post #6
post #4

This is more or less the greatest thing I've learned about in the last couple years. What's happening here is that they're getting computation without executing any instructions , 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. This works because when you attemp…

The slides in the github repo ( https://github.com/jbangert/trapcc/blob/master/slides/PFLA-s... ) also have a few interesting points, like "No publicly available simulator implements this correctly" (how did they record the youtube video?) and a few vague hints about exploiting this for doing VM escapes.

> 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.

Re: X86 MMU fault handling is turing complete

#13
post #4

This is more or less the greatest thing I've learned about in the last couple years. What's happening here is that they're getting computation without executing any instructions , 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. This works because when you attemp…

Reminds me of "ICMP delay-line memory": http://stackoverflow.com/questions/12748246/sorting-1-millio...

Re: X86 MMU fault handling is turing complete

#14
post #11
post #6

Earlier quoted context omitted.

The slides in the github repo ( https://github.com/jbangert/trapcc/blob/master/slides/PFLA-s... ) also have a few interesting points, like "No publicly available simulator implements this correctly" (how did they record the youtube video?) and a few vague hints about exploiting this for doing VM escapes.

> 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.

Re: X86 MMU fault handling is turing complete

#15
post #9

Earlier quoted context omitted.

can you please elaborate?

It's computation that you can't see with a debugger, or with any sort of tracing.

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

Re: X86 MMU fault handling is turing complete

#18
post #15
post #9

Earlier quoted context omitted.

It's computation that you can't see with a debugger, or with any sort of tracing.

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.

Re: X86 MMU fault handling is turing complete

#19
post #18
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.

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(?)

Re: X86 MMU fault handling is turing complete

#20
post #18
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.

Ahh, ok. Might actually be enough to, say, copy an encryption key out of kernel memory then?
Post reply on HN