
Xen exploitation part 2: XSA-148, from guest to host - adamnemecek
http://blog.quarkslab.com/xen-exploitation-part-2-xsa-148-from-guest-to-host.html
======
chromakode
"This vulnerability is probably the worst ever seen affecting Xen and it was
introduced 7 years before its discovery. As demonstrated in this blogpost, it
is exploitable and a code execution within dom0 is not so difficult."

------
userbinator
Xen-like paravirtualisation has always seemed to me as more of a convenient
way to run multiple _well-behaved_ guests on the same hardware than any sort
of real security/isolation barrier, because of the cooperation that has to
occur between the guest and the host. It's sort of a leaky abstraction. I
think full virtualisation or even emulation can provide stronger
security/isolation, although the tradeoff is performance.

------
AdmiralAsshat
So this basically throws the whole premise of QubesOS out the window, it
seems.

Virtualization is hard.

~~~
ams6110
_You are absolutely deluded, if not stupid, if you think that a worldwide
collection of software engineers who can 't write operating systems or
applications without security holes, can then turn around and suddenly write
virtualization layers without security holes._

Theo de Raadt

~~~
runeks
So because 95% of worldwide software developers write PHP web servers full of
security holes, it is not possible for a different group of developer to
create a secure interface? None of these web developers ever cared one bit
about the security of their app. You can't compare that with someone intending
to develop a secure interface. Security doesn't happen by mistake.

The value proposition of Xen is that it's a well-defined interface. The host
OS kernel takes care of hardware initialization, and Xen becomes an interface
on top of this kernel, through which untrusted client applications access
hardware resources. So the innovation of Xen is not that it's supposedly bug-
free. It's that it separates concerns: not mixing together hardware
initialization (Linux) and resource access/isolation for user space code. That
alone leaves less room for bugs.

The value of Linux is its drivers, not the actual kernel. So let's use Linux
for its drivers, rather than as a standard library. The only reason people
use, for example, the Linux CPU scheduler, is that it's inextricably tied to
the Linux drivers, because no interface exists (all code runs in one huge
blob). This is what Xen wants to fix. If the Linux folks concentrated on
creating secure driver interfaces, rather than implementing CPU schedulers and
memory managers themselves, it would mean that all the other developers of the
world could write CPU schedulers, rather than only the select few people who
think they know the Linux code base (who still end up producing bugs). An
interface is worth so much more than just an implementation of one, because it
not only makes access easy for the client, but also makes the creation of new
server implementations easy (by having a well-defined protocol/interface to
which they must conform).

~~~
mshook
I don't read it like that.

From my point of view it's like saying if you sell virtualization as a way to
isolate different OSes + applications for security reasons (compared to cost
savings and all associated from using this kind of technology), clearly you
better think twice about that.

And really, it's pretty much always a selling point when you talk to a
marketing rep or your PHB or her/his PHBs.

------
TempleOSV409
I started identity mapping everything using 2 Meg as much as possible. Since
VGA A0000 BFFFF must be uncached, I had to map the lowest 2 Meg with 4K.

Then, I made an alias for the VGA.

Recently, I switched to 1 Gig pages. You probably did not know that there is a
bit in the CPUID that tells if 1 Gig pages are supported.

I have an alias for the first 4 Gig up toward top of my space. FEE00000 the
local apic and IOAPic and HPET must be uncached, so I access them in my 4Gig
alias up in high space.

