Monday, August 14, 2006

Hi, slashdot!

Dude. We're famous! Too bad the article write-up calls our paper a "white paper," a term which, for me, carries strong connotations of gradient-bordered, visio-encrusted pdfs in sans serif fonts that use the word "enterprise" more than "and" or "the." For the record, the string "enterprise" appears in our paper only as part of the names of Windows .Net Enterprise and RedHat Enterprise Linux.

Wednesday, August 09, 2006

"Blue Pill" is quasi-illiterate gibberish.

I'm surprised at the hullaballoo surrounding the so-called "blue pill" pseudo-exploit. The non-exploit consists of a boot-loaded VT/SVM hypervisor that "undetectably" compromises your chain-loaded host. Recall with me the fundamental theorem of VT/SVM: "VT and SVM make nothing possible that was not possible before." VMware's pre-VT/SVM products are an existence proof.

This case is particularly hilarious, because "cloaking" a rootkit is actually harder to do with VT/SVM than with plain-jane, pre-virtualization x86 technology. Without getting into all the gory details here, malicious code that runs at CPL 0 (a pre-requisite, remember, for the ostensible "attack") can simply map itself in a convenient portion of the kernel address space (say, the top megabyte), modify the limit fields in the running kernel's code and data descriptor table entries, et voila: it's "undetectable", at least in the limited sense in which the blue pill hypervisor was undetectable. Yeah, there are some dots to connect; you have to point the IDT at the rootkit, and you may even ultimately need an x86 emulator if the kernel tries really hard to detect you. But x86 emulators aren't exactly the stuff of science fiction; they're pretty much commodities, which is a handy thing, since you need one in VT/SVM hypervisors, too.

The funny thing is that setting up an IDT and smashing a few GDT entries is actually a good deal simpler than setting up a full-fledged hypervisor, which needs a richer set of trap handlers, its own address space, probably needs to set up a shadow CR3 to protect itself from the guest, certainly needs a GDT and IDT, and so on. Most of that "life support" code can simply be stolen from the exploited host if you take the simpler approach outlined above. I'll go so far as to say that this "blue pill" hype is straightforward attention-whoring; virtualization is hot, and finding some sense in which it might be "bad" seems contrarian and interesting, so people's ears prick up. There's really nothing to see here, though.

Tuesday, August 08, 2006

DTrace:MacOS X::Chocolate:Peanut Butter

Whoah. Between this, and the VT-enabled 64-bit Macs, I think Apple just sold me a computer.

(The careful reader might be wondering why the author of a paper that's somewhat critical of VT would be stoked about using VT for virtualization. The answer is: I spent a lot of time on that code, and even if it isn't quite the right approach, running my own code gives me the fun-sies. Plus, those new processors are just outrageously nice pieces of hardware all-around.)

Monday, August 07, 2006

A Comparison of Software and Hardware Techniques for x86 Virtualization

Our (very early) experiences with VT/SVM, contrasted with VMware's classic VMM. Enjoy. Also linked from the academic program page referenced below.

Wednesday, August 02, 2006

Secret stash of VMware academic publications

This page, carefully hidden under the link "Program resources" under the VMware academic program page, contains some published papers that VMware folks have put out over the years. Don't worry about the misleading title "Academic White Papers"; these are no-fooling, intellectually rigorous attempts at sharing knowledge at legit conferences. The odds of you finding this by just clicking around are near nil; I knew it existed, and couldn't figure it out without email from our webmaster. Enjoy!