<div dir="ltr"><br>Ok, so pipacs is no joke, as is obvious to all of us, but I really wanted to drill down and shorten his point, which is this: <div>When you make a hypervisor do real work, you turn it into a kernel. And the level of access you have on a kernel (even sandboxed) for a reasonable workload is almost always enough to get full control of it. </div><div><br></div><div>I'm sure Halvar has some math which classifies the level of complexity a kernel needs before it is exploitable, but the general feeling is true. "Thin hypervisors" are a pipe dream. They almost always expand until you can get your printer to work.</div><div>-dave </div><div><br>Read below:<div><a href="http://theinvisiblethings.blogspot.pt/2010/08/skeletons-hidden-in-linux-closet.html">http://theinvisiblethings.blogspot.pt/2010/08/skeletons-hidden-in-linux-closet.html</a></div><div><br>Hi Joanna,<br><br>i think there's a misunderstanding regarding 'kernel exploits'. to explain i'll give you an analogy.<br><br>so-called return-to-libc attacks have been publicly known since at least solar_diz's famoust post on bugtraq in the previous millennium. i think it's obvious to anyone skilled in the art that the name of the technique itself has never prevented anyone from writing an exploit that relied on another piece of code, or even arbitrary chunks of code (vs. libc API calls). in fact we know it for a fact since there're even public exploits that do just that, many years before the current marketing distractment called ROP/JOP/etc entered the public mind as if they were something new. so what we can see here is an exploit technique named after its first public incarnation but that doesn't mean it wasn't meant to cover the whole set of techniques that relies on executing existing code, wherever it may be in memory.<br><br>now the analogy is that 'kernel exploits' never meant 'guest kernel exploits' (regardless of ring-0 or ring-3, or whatever), but they always meant 'exploits against bugs in the TCB'. and since in a traditional OS where such exploits were written originally the kernel code running in ring-0 happens to be part of the TCB, the name stuck.<br><br>now what this means for Qubes is that your claim about eliminating 'kernel-level exploits' would require no exploitable bugs in Xen (the hypervisor) and dom0 at least (be that by provable construction or just intrusion prevention techniques). and i think we all agree that you don't have such a thing, nor does anyone else to date ;). the alternative intrepretation of your claim would be that you solved the problem by declaring it not to be a problem (e.g., "we don't care about user->ring0 attacks in Qubes ' AppVMs", "In Qubes OS we assume the attacker already has root in the AppVM" or "We *really* don't care about the attacker going from user-to-root in a VM.") and i don't think you really meant that ;).  </div></div></div>