Hacker News new | past | comments | ask | show | jobs | submit login
Exploiting modern microarchitectures: Meltdown, Spectre, and other attacks [pdf] (redhat.com)
211 points by anarazel on Feb 4, 2018 | hide | past | web | favorite | 34 comments



This was the last talk at FOSDEM, there were over 1,400 people in the audience.

https://fosdem.org/2018/schedule/event/closing_keynote/

Video should be available soon.



This video isn't from FOSDEM but it appears to be the same talk / slides.




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.


And a great talk it was! Jon managed to make Spectre, Meltdown and a signifi part of modern processor design understanda in just 45 minutes.


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.


Also check out their EE380 talk.


Link?



Thanks for the comments all. Here's the video of my FOSDEM 2018 keynote that matches these slides, which is now available: https://video.fosdem.org/2018/Janson/closing_fosdem.webm or https://video.fosdem.org/2018/Janson/closing_fosdem.mp4


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?



I have a question about the retpoline code.

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 seems fairly plausible that that would have noticeably higher overhead.


What am I missing here, isn't int3 used for debugging purposes?


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.


> If the int3 happens to get hit by the other thread, just have the debug exception do nothing.

Doesn't that potentially crash the other thread because the rest of the instruction is still there?


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.


Perfect, thanks for the summary.


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.


> 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

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?


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.


MIPS is not vulnerable to either Meltdoown or Spectre.


And how did they achieve that? MIPS says their only high performance CPUs are vulnerable to Spectre.

https://www.mips.com/blog/mips-response-on-speculative-execu...


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.


SPARC isn't vulnerable to Meltdown either (based on public statements by Oracle and my own understanding of its address space separation).


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!


Which page?


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.


Deleted. Wrong thread


I think you may be on the wrong thread. Perhaps here is where you intended?

https://news.ycombinator.com/item?id=16302476


Thanks my good lad. Having multiple tabs open has failed me.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: