The right link to PacSec slides (sorry):
Mickey's and Jesse's slides from PacSec: http://goo.gl/Rgcwud -----Original Message----- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Dragos Ruiu Sent: December 23, 2015 8:24 PM To: 'Tinker' <ti...@openmailbox.org> Cc: 'Read, James C' <jcr...@essex.ac.uk>; 'Theo de Raadt' <dera...@cvs.openbsd.org>; 'OpenBSD general usage list' <misc@openbsd.org>; owner-m...@openbsd.org Subject: Re: Boot loader uses INT 13h [WAS BIOS call fallback] >On 2015-12-23 10:04, Dragos Ruiu wrote: >> Ok let me short circuit this meta discussion by saying that AFAIK now >> that the new Intel Skylake chips fixed many virtualization bugs > >Curious, where can I read about this, URL? The canonical reference is still (and I looked for better summaries but none are found): http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32 -architectures-optimization-manual.pdf http://goo.gl/Aq59Lm Its dense with info and tough to pull relevants bits out, but some clues are in there. My comments are based on verbal discussions with other non OBSD OS kernel developer, Intel folks who have boasted about running hundreds of VMs efficiently on a single (albeit Xeon) chip, and multiple folks who are doing security audits of different vendor's Virtualization Cores, that have all corroborated this not very well documented info, commenting especially that Intel had pulled back some not so ready for the real world features originally promised but eventually deprecating them in Broadwell (haven't checked the processor errata for details yet), which were now finally working in Skylake. Coincidentally tonight, this seemingly related and interesting new paper by Joanna Rutkowska (@rootkovska) "Intel x86 Considered Harmful" was released which proposes an intriguing security solution that sounds appealing at first, getting rid of all state in laptops - until you realize that doing this is almost impossible. For a counter example we had a great paper at PacSec this year from Intel's Mickey Shkatov and Jesse Michael discussing and enumerating many of the hidden state / firmware / processors in modern architectures that can be attacked and used as springboards including examples of pwnage using this soft, delicate, and unprotected underbelly of our computers. Modern architectures have so many mutable bits and embedded CPUs/PICs/FPGAs etc... that removing (or even locking them) is a task I daresay is beyond our reach at the moment - at least without making the computers nearly useless bricks. For another example, consider things like your keyboard controller, which is probably a National Semiconductor chip with yet another embedded 8051 core, and then some more of those in your mice and keyboards, and USB and other controllers, and so on. As a matter of fact just counting only the 8051 cores alone in a modern PC is so hard you are nearly guaranteed to miss a few on your first cut. Joanna's paper: http://goo.gl/8xhMo8 Mickey's and Jesse's slides from PacSec: http://goo.gl/8xhMo8 Returning back to the discussion where I suggested it would be nice to build OS kernels that would fail deliberately when virtualized to close off that class of malware, especially on the new Intel Skylake chips that have fixed so many virtualization bugs that they can (reportedly) run VT inside VT and nest virtualization so efficiently you can virtualize ridiculous numbers of VMs even inside each other, with so little overhead and few virtualization artifacts that they are nearly undetectable when virtualized. The prevailing attitude that this isn't in scope to worry about - to which I counter that if you don't worry about the overall platform security and just put blinders on to the hard problems, avoiding defensive mitigations for the weak architecture areas then you have already lost the security and integrity of your computers, and you are at the mercy of the sophisticated attackers. They aren't your computers anymore, you are just using them under the graces of what attack teams more advanced than you allow you to do. (bracing) This is an area where Win10 is clearly leading the pack based on the effort I see they are putting into repeatedly auditing all their codebase with smart outside experts and adding interesting new mitigations like wrappering and shimming vulnerable unchecked AMD microcode updates, and other weak hardware parts like USB etc... - and who would have guessed I would be saying that a few years ago! Yes, I put on my Nomex flame retardant suit before typing that sentence suggesting that OpenBSD development might actually take some cues from Windows, heresy I know, on an OpenBSD list. But this is just one person's opinion based on what I've seen, and the people I've talked to. I'll certainly continue to seek this kind of functionality and try to add it to my OpenBSD kernels myself if no-one else has anything useful to add. Bottom line: Sigh. Cheers, --dr P.S. Go ahead and tell me why I'm such an idiot now. But you have the data too, come to your own decisions, those are my current conclusions and plans.
