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(?)
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?)
Most of the techniques described in the slides require ring-0 privileges (replacing descriptor tables and page tables etc). If you have those privileges, you can copy what you want anyway.
Unless the encryption key is guarded by something with SMM privileges -- has that been done?
Would that slow things down incredibly?