Hi, So what''s more secure? a HVM or a PV DomU? Which one of the architectures is more "open" for attacks, if someone wants to execute code in domain0 ? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Let me rephrase my question - What are the attack vectors for each architecture? For PV it''s the Paravirtualization API and hypercalls, and for HVM it''s the VMEXIT Parsing / QEMU states and hypercalls... Are there other attack vectors that may be used to hack from a domU or HVM into dom0? can we get an obvious conclusion about which architechture is more secure? PV or HVM? Thanks, David. On 12/18/06, David Pilger <pilger.david@gmail.com> wrote:> Hi, > > So what''s more secure? a HVM or a PV DomU? > Which one of the architectures is more "open" for attacks, if someone > wants to execute code in domain0 ? >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats
2006-Dec-19 10:17 UTC
RE: [Xen-devel] Re: What is more secure? HVM or PV ?
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > David Pilger > Sent: 19 December 2006 08:35 > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] Re: What is more secure? HVM or PV ? > > Let me rephrase my question - > What are the attack vectors for each architecture?What''s the goal of the attack - to take control of the system or to just be a nuisance and crash it? To take control, I suspect the easiest approach is known kernel holes and a direct attack on Dom0. DomU is probably capable of causing Dom0 to crash - at least there''s been bugs like that in the HVM side of the hypervisor - most of the PV side is probably more immunce thanks to greater maturity of the code. I''m pretty sure that if anyone actually KNOWS of a method to attack the system, then it would be on it''s way to being fixed. There''s no interface that actually allows the guest to ask for Dom0 to execute the guests code - but seeing as the code in Xen is large enough that it''s hard to track EVERYTHING, there may be some obscure way of making it misbehave. -- Mats> > For PV it''s the Paravirtualization API and hypercalls, and for HVM > it''s the VMEXIT Parsing / QEMU states and hypercalls... > > Are there other attack vectors that may be used to hack from a domU or > HVM into dom0? can we get an obvious conclusion about which > architechture is more secure? PV or HVM? > > Thanks, > David. > > On 12/18/06, David Pilger <pilger.david@gmail.com> wrote: > > Hi, > > > > So what''s more secure? a HVM or a PV DomU? > > Which one of the architectures is more "open" for attacks, > if someone > > wants to execute code in domain0 ? > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/19/06, Petersson, Mats <Mats.Petersson@amd.com> wrote:> > What''s the goal of the attack - to take control of the system or to just > be a nuisance and crash it?The goal is to gain control over domain0, as the root user.> > To take control, I suspect the easiest approach is known kernel holes > and a direct attack on Dom0. > > DomU is probably capable of causing Dom0 to crash - at least there''s > been bugs like that in the HVM side of the hypervisor - most of the PV > side is probably more immunce thanks to greater maturity of the code. >Are there any attack vectors that aren''t directly related to Xen if dealing with PV, such as kernel facilities + processor architecture or stuff like that? If we''ll look at it from a lines of code POV, then I guess that HVMs are less secure (vmexit handler / parsers / qemu), that code is not mature either. So, Is there any obvious conclusion about this topic? Or we can say that the security is the same in PV as in HVM? David. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
David Pilger <pilger.david@gmail.com> wrote:> > So, Is there any obvious conclusion about this topic? Or we can say > that the security is the same in PV as in HVM?Right now HVM is arguably slightly less secure compared to PV because of the QEMU backends running as root in dom0. The QEMU backends are more complex than the PV backend drivers and (arguably) more prone to bugs. Once the QEMU backends are moved into a separate domain, they would be equal in this respect since both will use the PV backends. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Williamson
2006-Dec-23 17:52 UTC
Re: [Xen-devel] Re: What is more secure? HVM or PV ?
> Let me rephrase my question - > What are the attack vectors for each architecture? > > For PV it''s the Paravirtualization API and hypercalls, and for HVM > it''s the VMEXIT Parsing / QEMU states and hypercalls...Well, in principle there aren''t any means of attacking ;-) Certainly, by design, neither *should* allow attacks on Xen or dom0 - explicit trust isn''t required.> Are there other attack vectors that may be used to hack from a domU or > HVM into dom0? can we get an obvious conclusion about which > architechture is more secure? PV or HVM?For PV: The explicit hypercall API would be one possible attack vector - exploiting any bugs in Xen. The memory mapping interface could also be an attack vector (including both the paravirtualised and various shadowing code paths). PV also could be attacked in principle via the frontend / backend drivers - if the backend driver could be compromised and made to execute arbitrary code (or even write abitrary code to dom0''s filesystem / swapfile for later executation) then it would be possible to take over the whole machine. The PV components have been in place for longer and have probably received more scrutiny. The HVM components are rather complex and have received, I think, less eyeballing. I''d guess (and it is really a guess) that I''d have more confidence in PV from a security point of view, but that''s definitely not to say that there''s anything specifically *wrong* with the HVM code, just that it''s less mature. Cheers, mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> For PV: > The explicit hypercall API would be one possible attack vector - exploiting > any bugs in Xen. The memory mapping interface could also be an attack vector > (including both the paravirtualised and various shadowing code paths). > > PV also could be attacked in principle via the frontend / backend drivers - if > the backend driver could be compromised and made to execute arbitrary code > (or even write abitrary code to dom0''s filesystem / swapfile for later > executation) then it would be possible to take over the whole machine. > > The PV components have been in place for longer and have probably received > more scrutiny. The HVM components are rather complex and have received, I > think, less eyeballing. I''d guess (and it is really a guess) that I''d have > more confidence in PV from a security point of view, but that''s definitely > not to say that there''s anything specifically *wrong* with the HVM code, just > that it''s less mature. >I agree, I think that because the PV API is also exposed to HVMs (PV-on-HVM), we can conclude that HVMs are theoretically less secure, becuase they have more attack vectors. David. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel