I'm looking forward to the video! Wish I could have been there but I had accidentally^W unfortunately booked my return flight just after the talk ended.
It's an earlier version from a Stanford session I did last week. But note that the Stanford one was a different audience, and a bit more flexible in time, so it went 2.5 hours and had fewer diagrams. The FOSDEM version was updated to fit for time based upon what I learned giving the earlier talk.
This is a 90-page book in the form of slides. It supposedly takes you from not understanding virtual memory up to understanding the details of modern side-channel attacks like Meltdown and Spectre. Either you know it mostly and this is boring, or you don't know it and you're in for a super-steep learning curve.
That plus a belgian beer, what else ? The guy presenting it live was very enthusiastic and you just can enjoy the whole thing. Seriously it's a thing to live.
I understand this is not related, but how did the counters hide after couples seconds in the pdf? Can I do this using Latex? But what a great presentation of hardware architecture!
Oh, Sorry I just realized this is the new version of Okular that does it (adding the number of the slide on top corner and auto hiding it). I thought it is the PDF file feature. Unfortunately, I cannot remove my post! Just switched to KDE and I was not used to seeing the slide counter.
Does anybody know why they used "lfence;jmp" or "pause;jmp" instead of "ud2" alone? The ud2 instruction has previously been recommended to stop speculative execution. Other good choices would be int3 (0xCC) and int1 (0xF1).
One use of int3 is debugging. That is the originally intended use. You can use it for other things.
It gets used for multi-threaded self-modifying code. Simply modifying the code can cause a crash due to an intermediate state. There are caches and there is an instruction prefetcher. To deal with this, first write out an int3 on the first byte of the instruction you wish to replace. The CPU is careful not to screw up in this case because int3 has to work for debugging. Next, update the rest of the instruction as desired, and then write the first byte over the int3. If the int3 happens to get hit by the other thread, just have the debug exception do nothing.
The carefulness around int3 will stop speculation. That is what is needed for a retpoline.
People have also used int3 for things related to copy protection. You could be silly and write an OS that used int3 to do system calls.
No, but it might if something other than an int3 were used. The particular byte value being written actually matters on some Intel processors. You have to first put 0xCC over the first byte of the opcode you want to modify. You can then freely mess with the rest of the instruction. After that, you make the first byte be what you actually want.
There is a discussion about it on the linux-kernel mailing list. Maybe you can find it.
It's the same way with ARM. A fair amount of CPUs simply don't do out-of-order or speculative execution to the point where they could be vulnerable. And of course, if they can't do that then there's no way they could be vulnerable to Spectre or Meltdown.
This seems to only be a video of the closing of FOSDEM. Some stats, thanking volunteers and reminders for people to clean after themselves.
Am I missing something?
35 comments
[ 2.1 ms ] story [ 80.1 ms ] threadhttps://fosdem.org/2018/schedule/event/closing_keynote/
Video should be available soon.
Or you sort-of-know-but-have-half-forgotten most of it and this is a nice refresher with a few interesting new bits thrown in?
https://news.ycombinator.com/item?id=16302476
Does anybody know why they used "lfence;jmp" or "pause;jmp" instead of "ud2" alone? The ud2 instruction has previously been recommended to stop speculative execution. Other good choices would be int3 (0xCC) and int1 (0xF1).
Here is somebody quoting from Intel's manual:
https://software.intel.com/en-us/forums/software-tuning-perf...
To me, it looks like you could save several bytes.
It gets used for multi-threaded self-modifying code. Simply modifying the code can cause a crash due to an intermediate state. There are caches and there is an instruction prefetcher. To deal with this, first write out an int3 on the first byte of the instruction you wish to replace. The CPU is careful not to screw up in this case because int3 has to work for debugging. Next, update the rest of the instruction as desired, and then write the first byte over the int3. If the int3 happens to get hit by the other thread, just have the debug exception do nothing.
The carefulness around int3 will stop speculation. That is what is needed for a retpoline.
People have also used int3 for things related to copy protection. You could be silly and write an OS that used int3 to do system calls.
Doesn't that potentially crash the other thread because the rest of the instruction is still there?
There is a discussion about it on the linux-kernel mailing list. Maybe you can find it.
https://www.mips.com/blog/mips-response-on-speculative-execu...