[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: Regarding Xen security....


  • To: "Anthony Liguori" <aliguori@xxxxxxxxxxxxxxxxxx>
  • From: "David Pilger" <pilger.david@xxxxxxxxx>
  • Date: Tue, 16 Jan 2007 09:56:31 +0200
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 15 Jan 2007 23:56:07 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Uu8lfMGVgntstiMaeOVD/9RPUM5dLlkv8wBoPZuPWsqV5nMuNErNPIuXhXgr79Me5oZoxzbaHWFMw3jm87SbqwAuZvt17Nodl2gawG7TBXx+Z27qNh2O/9Xtsgfr8za0Ndqj3/EFKUuL7bNkMBODGBOdL1oVvH2Xhfs6Q4+4NyA=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 1/15/07, Anthony Liguori <aliguori@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>>
>>
>>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.