Hi Sir,
I have a question regarding the security of Xen. What are
the security threats in with Intel VT-x.
Thanks,
Praveen Kushwaha
________________________________________________________________________
_____________________
NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix Techno
Park, Noida | Tel: 120 436 6777 Extn 748
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Praveen Kushwaha > Sent: 12 January 2007 10:13 > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] Regarding Xen security.... > > Hi Sir, > > I have a question regarding the security of Xen. > What are the security threats in with Intel VT-x.Suppose we (as a community) did know of any "exploits" in the Intel or AMD virtualization technologies, would it make sense to distribute it to everyone? As far as I''m aware (and, although I work for AMD, I can''t say I know EVERYTHING, so there may be things that I''m not aware of), AMD SVM or Intel VT-x doesn''t add anything that increases security threats - in fact they both add a level of extra security, as you can prevent the software in the OS from actually touching hardware that you don''t explicitly give to the guest. Of course, broken kernel or other software will still potentially allow a user to gain access to the guest-domain - Xen doesn''t really fix kernel security in general (it may "accidentally", but it''s not there for that purpose). Obviously, for any virtualized environment, the security of the "host domain" (Dom0 in Xen) is critical to ensure that the other domains remain secure - so firewalling or otherwise preventing "outside access" to Dom0 is key to ensuring that the guest domains are secure - but that''s got nothing to do with any of the Virtualization Technology features in the processor. For further improved security, both AMD and Intel have features that are either already in the processor (AMD SVM) or planned for near-time release (Intel''s LaGrande/Trusted eXecution Technology/TXT), which allow the execution environment to be checked before it''s loaded, to ensure that the host domain and it''s relevant components are indeed what the system owner/user expects them to be - and once that''s secure, you can then verify (or measure as it''s called in security circles) the kernel loaded as DomU. -- Mats> > > > > > Thanks, > > Praveen Kushwaha > > > ______________________________________________________________ > _______________________________ > > NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix > Techno Park, Noida | Tel: 120 436 6777 Extn 748 > > > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Search for "HVM rootkits", if your system runs without a hypervisor and VMX/SVM is enabled in the BIOS then an attacker can gain control over that layer. But he''ll first need to gain control over the operating system (not so difficult) in order to execute a program with high privileges. In "VMX root operation" you have total control over the system (parallel to ring0, one year ago). VT-x is intended to provide another ring of security (priviliges), which lets hypervisors manage unmodified operating systems. Right now, if you are not running a hypervisor than it''s not secure to enable VT-x in the BIOS, if you do use some kind of hypervisor, then the threat is that an attacker will find a security hole in it and take control over that layer. Right now, there aren''t any known vulnerabilities in software the manage VMX. But I guess that the focus of malicious people is not exactly at hypervisors. When LaGrande (for instance) will be a part of any computer, then it will be "benefitial" to search for vulnerabilities in this layer. In summary, there is a risk when no hypervisor occupies the VMX layer and it is enabled in the BIOS. The only use of this layer by a malicious program is for properly hiding itself from removal tools. Any way, here are some insights: * If operating systems were secure enough and properly programmed then VMX was not needed in this regard (to provide security). * The implementation of VMX is here to take the control of the machine from a certain operating system, treating an OS just like a "process". * Its useful for servers that runs virtual machines, this is trivial use of a hypervisors. David. On 1/12/07, Praveen Kushwaha <praveen.kushwaha@nechclst.in> wrote:> > > > Hi Sir, > > I have a question regarding the security of Xen. What are the > security threats in with Intel VT-x. > > > > > > Thanks, > > Praveen Kushwaha > > > > _____________________________________________________________________________________________ > > NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix Techno Park, > Noida | Tel: 120 436 6777 Extn 748 > > > > > > > _______________________________________________ > 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
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > David Pilger > Sent: 15 January 2007 12:19 > To: Praveen Kushwaha > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Regarding Xen security.... > > Search for "HVM rootkits", if your system runs without a hypervisor > and VMX/SVM is enabled in the BIOS then an attacker can gain control > over that layer. But he''ll first need to gain control over the > operating system (not so difficult) in order to execute a program with > high privileges. In "VMX root operation" you have total control over > the system (parallel to ring0, one year ago). > > VT-x is intended to provide another ring of security (priviliges), > which lets hypervisors manage unmodified operating systems. > > Right now, if you are not running a hypervisor than it''s not secure to > enable VT-x in the BIOS, if you do use some kind of hypervisor, then > the threat is that an attacker will find a security hole in it and > take control over that layer. Right now, there aren''t any known > vulnerabilities in software the manage VMX. But I guess that the focus > of malicious people is not exactly at hypervisors. When LaGrande (for > instance) will be a part of any computer, then it will be "benefitial" > to search for vulnerabilities in this layer. > > In summary, there is a risk when no hypervisor occupies the VMX layer > and it is enabled in the BIOS. The only use of this layer by a > malicious program is for properly hiding itself from removal tools.Although it''s perfectly possible to do this at present without VMX/SVM technology. For example VMWare uses this sort of technique to make their virtualization monitor. It''s a lot more work, but it''s still possible. The key, however, is that to use any of this, there are two conditions required: 1. Access to run at Ring 0 - and assuming that this is not so difficult is probably fair, but it also means that the system isn''t really secure anyways, because as soon as some arbitrary code can run in Ring 0, it''s able to do ANYTHING in the system that it likes [although it may be a little bit of hard work to actually go from a trivial exploit to actually gain full control over the system]. 2. That there isn''t some other use of the SVM/VMX feature in place already - as of current, neither of these techniques are nestable, so once some code has gained control of the SVM/VMX feature, anyone else attempting the same thing will fail in some respect. -- Mats> > Any way, here are some insights: > * If operating systems were secure enough and properly programmed then > VMX was not needed in this regard (to provide security). > * The implementation of VMX is here to take the control of the machine > from a certain operating system, treating an OS just like a "process". > * Its useful for servers that runs virtual machines, this is trivial > use of a hypervisors. > > David. > > > On 1/12/07, Praveen Kushwaha <praveen.kushwaha@nechclst.in> wrote: > > > > > > > > Hi Sir, > > > > I have a question regarding the security of > Xen. What are the > > security threats in with Intel VT-x. > > > > > > > > > > > > Thanks, > > > > Praveen Kushwaha > > > > > > > > > ______________________________________________________________ > _______________________________ > > > > NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix > Techno Park, > > Noida | Tel: 120 436 6777 Extn 748 > > > > > > > > > > > > > > _______________________________________________ > > 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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/15/07, Petersson, Mats <Mats.Petersson@amd.com> wrote:> The key, however, is that to use any of this, there are two conditions > required: > 1. Access to run at Ring 0 - and assuming that this is not so difficult > is probably fair, but it also means that the system isn''t really secure > anyways, because as soon as some arbitrary code can run in Ring 0, it''s > able to do ANYTHING in the system that it likes [although it may be a > little bit of hard work to actually go from a trivial exploit to > actually gain full control over the system]. > 2. That there isn''t some other use of the SVM/VMX feature in place > already - as of current, neither of these techniques are nestable, so > once some code has gained control of the SVM/VMX feature, anyone else > attempting the same thing will fail in some respect. >Yep. saying that VT-x is unsecure in some manner is exactly like saying that ring0 is not secure... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
David Pilger wrote:> Search for "HVM rootkits",The vast majority of this is, as Keith Adams put its, "quasi-illiterate gibberish." http://x86vmm.blogspot.com/2006/08/blue-pill-is-quasi-illiterate.html Having VT/SVM doesn''t really change anything wrt rootkits. Most of what is floating around is FUD. There''s nothing you can do today that you couldn''t do before VT/SVM. Regards, Anthony Liguori if your system runs without a hypervisor> and VMX/SVM is enabled in the BIOS then an attacker can gain control > over that layer. But he''ll first need to gain control over the > operating system (not so difficult) in order to execute a program with > high privileges. In "VMX root operation" you have total control over > the system (parallel to ring0, one year ago). > > VT-x is intended to provide another ring of security (priviliges), > which lets hypervisors manage unmodified operating systems. > > Right now, if you are not running a hypervisor than it''s not secure to > enable VT-x in the BIOS, if you do use some kind of hypervisor, then > the threat is that an attacker will find a security hole in it and > take control over that layer. Right now, there aren''t any known > vulnerabilities in software the manage VMX. But I guess that the focus > of malicious people is not exactly at hypervisors. When LaGrande (for > instance) will be a part of any computer, then it will be "benefitial" > to search for vulnerabilities in this layer. > > In summary, there is a risk when no hypervisor occupies the VMX layer > and it is enabled in the BIOS. The only use of this layer by a > malicious program is for properly hiding itself from removal tools. > > Any way, here are some insights: > * If operating systems were secure enough and properly programmed then > VMX was not needed in this regard (to provide security). > * The implementation of VMX is here to take the control of the machine > from a certain operating system, treating an OS just like a "process". > * Its useful for servers that runs virtual machines, this is trivial > use of a hypervisors. > > David. > > > On 1/12/07, Praveen Kushwaha <praveen.kushwaha@nechclst.in> wrote: >> >> >> >> Hi Sir, >> >> I have a question regarding the security of Xen. What are >> the >> security threats in with Intel VT-x. >> >> >> >> >> >> Thanks, >> >> Praveen Kushwaha >> >> >> >> _____________________________________________________________________________________________ >> >> >> NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix Techno Park, >> Noida | Tel: 120 436 6777 Extn 748 >> >> >> >> >> >> >> _______________________________________________ >> 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 1/15/07, Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:> David Pilger wrote: > > Search for "HVM rootkits", > > The vast majority of this is, as Keith Adams put its, "quasi-illiterate > gibberish." > > http://x86vmm.blogspot.com/2006/08/blue-pill-is-quasi-illiterate.html > > Having VT/SVM doesn''t really change anything wrt rootkits. Most of what > is floating around is FUD. There''s nothing you can do today that you > couldn''t do before VT/SVM. >This is true in some manner, it''s just that VT/SVM let a rootkit hide itself pretty well from the operating system that it is already attacking. But no doubt it''s FUD. At the other end though, Intel invests a lot of efforts in marketing VT as a synonym for security.> Regards, > > Anthony Liguori > > > if your system runs without a hypervisor > > and VMX/SVM is enabled in the BIOS then an attacker can gain control > > over that layer. But he''ll first need to gain control over the > > operating system (not so difficult) in order to execute a program with > > high privileges. In "VMX root operation" you have total control over > > the system (parallel to ring0, one year ago). > > > > VT-x is intended to provide another ring of security (priviliges), > > which lets hypervisors manage unmodified operating systems. > > > > Right now, if you are not running a hypervisor than it''s not secure to > > enable VT-x in the BIOS, if you do use some kind of hypervisor, then > > the threat is that an attacker will find a security hole in it and > > take control over that layer. Right now, there aren''t any known > > vulnerabilities in software the manage VMX. But I guess that the focus > > of malicious people is not exactly at hypervisors. When LaGrande (for > > instance) will be a part of any computer, then it will be "benefitial" > > to search for vulnerabilities in this layer. > > > > In summary, there is a risk when no hypervisor occupies the VMX layer > > and it is enabled in the BIOS. The only use of this layer by a > > malicious program is for properly hiding itself from removal tools. > > > > Any way, here are some insights: > > * If operating systems were secure enough and properly programmed then > > VMX was not needed in this regard (to provide security). > > * The implementation of VMX is here to take the control of the machine > > from a certain operating system, treating an OS just like a "process". > > * Its useful for servers that runs virtual machines, this is trivial > > use of a hypervisors. > > > > David. > > > > > > On 1/12/07, Praveen Kushwaha <praveen.kushwaha@nechclst.in> wrote: > >> > >> > >> > >> Hi Sir, > >> > >> I have a question regarding the security of Xen. What are > >> the > >> security threats in with Intel VT-x. > >> > >> > >> > >> > >> > >> Thanks, > >> > >> Praveen Kushwaha > >> > >> > >> > >> _____________________________________________________________________________________________ > >> > >> > >> NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix Techno Park, > >> Noida | Tel: 120 436 6777 Extn 748 > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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
> > The vast majority of this is, as Keith Adams put its, "quasi-illiterate > > gibberish." > > > > http://x86vmm.blogspot.com/2006/08/blue-pill-is-quasi-illiterate.html > > > > Having VT/SVM doesn''t really change anything wrt rootkits. Most of what > > is floating around is FUD. There''s nothing you can do today that you > > couldn''t do before VT/SVM. > > This is true in some manner, it''s just that VT/SVM let a rootkit hide > itself pretty well from the operating system that it is already > attacking. But no doubt it''s FUD. At the other end though, Intel > invests a lot of efforts in marketing VT as a synonym for security.I always thought the principle behind blue pill was quite sensible. It''s not demonstrating a fundamental flaw / bug in the hardware design (I''m not sure it was originally presented that way, although I''ve certainly seem it treated as if it did). I see it as just a (rather neat and clever) proof of concept to show that the VMX/SVM extensions add a new class of attack and a new stealth mechanism for rootkits; no more no less. A heads-up to the security community. And worth pointing out, since existing rootkit detection mechanisms may not be able to detect it once the VMX stealthing is enabled... I have a feeling that this research has both been reported to be much more, and much less than it really is. The important thing is that it doesn''t open a new loophole, but does provide a new tool for attackers (and for defenders!). 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
Mark Williamson wrote:>>> The vast majority of this is, as Keith Adams put its, "quasi-illiterate >>> gibberish." >>> >>> http://x86vmm.blogspot.com/2006/08/blue-pill-is-quasi-illiterate.html >>> >>> Having VT/SVM doesn''t really change anything wrt rootkits. Most of what >>> is floating around is FUD. There''s nothing you can do today that you >>> couldn''t do before VT/SVM. >> This is true in some manner, it''s just that VT/SVM let a rootkit hide >> itself pretty well from the operating system that it is already >> attacking. But no doubt it''s FUD. At the other end though, Intel >> invests a lot of efforts in marketing VT as a synonym for security. > > I always thought the principle behind blue pill was quite sensible. It''s not > demonstrating a fundamental flaw / bug in the hardware design (I''m not sure > it was originally presented that way, although I''ve certainly seem it treated > as if it did).I''m a bit bias on the subject but the author did announce her work with a paper claiming "100% undetectable malware". That simply isn''t true. Discussing the practicality of hiding malware is certainly an interesting and research worthy topic. However, IMHO, VT/SVM really doesn''t make it any easier than it was in the past. You could always hook the IDT. That is considerably easier than setting up a full VT/SVM environment. Regards, Anthony Liguori> I see it as just a (rather neat and clever) proof of concept to show that the > VMX/SVM extensions add a new class of attack and a new stealth mechanism for > rootkits; no more no less. A heads-up to the security community. And worth > pointing out, since existing rootkit detection mechanisms may not be able to > detect it once the VMX stealthing is enabled... > > I have a feeling that this research has both been reported to be much more, > and much less than it really is. The important thing is that it doesn''t open > a new loophole, but does provide a new tool for attackers (and for > defenders!). > > Cheers, > Mark >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
hi I have try to "xm block-attach " to hotplug a disk into a running paraVM and I want to kown whether the nic could be hotpluged into a running paraVM? if it could , how to do it? could you holp me Thanks in advance _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats
2007-Apr-24 09:03 UTC
RE: [Xen-devel] could netcard be hotplug into a running VM?
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of tgh > Sent: 24 April 2007 07:13 > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] could netcard be hotplug into a running VM? > > hi > I have try to "xm block-attach " to hotplug a disk into a > running paraVM > and I want to kown whether the nic could be hotpluged into > a running > paraVM? > if it could , how to do it?I think you''re looking for "xm network-attach". Next time you have a question like this, maybe you could try "xm help", as that''s where I got that info from. [I''m only guessing from the name of the command that it does what you want - I don''t have any PV guests on my machine at the mo'', so I can''t try it]. -- Mats> > could you holp me > Thanks in advance > > _______________________________________________ > 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
Thank you for reply and your direct Petersson, Mats 写道:> > > >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of tgh >> Sent: 24 April 2007 07:13 >> To: xen-devel@lists.xensource.com >> Subject: [Xen-devel] could netcard be hotplug into a running VM? >> >> hi >> I have try to "xm block-attach " to hotplug a disk into a >> running paraVM >> and I want to kown whether the nic could be hotpluged into >> a running >> paraVM? >> if it could , how to do it? >> > > I think you''re looking for "xm network-attach". > > Next time you have a question like this, maybe you could try "xm help", > as that''s where I got that info from. > > [I''m only guessing from the name of the command that it does what you > want - I don''t have any PV guests on my machine at the mo'', so I can''t > try it]. > > -- > Mats > >> could you holp me >> Thanks in advance >> >> _______________________________________________ >> 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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel