lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130131200024.GB1757@redhat.com>
Date:	Thu, 31 Jan 2013 22:00:24 +0200
From:	Gleb Natapov <gleb@...hat.com>
To:	Don Zickus <dzickus@...hat.com>
Cc:	x86@...nel.org, LKML <linux-kernel@...r.kernel.org>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Prarit Bhargava <prarit@...hat.com>, alex.williamson@...hat.com
Subject: Re: [PATCH] x86, x2apic: Only WARN on broken BIOSes inside a virtual
 guest

On Thu, Jan 31, 2013 at 02:34:27PM -0500, Don Zickus wrote:
> On Thu, Jan 31, 2013 at 08:52:00PM +0200, Gleb Natapov wrote:
> > > http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
> > > 
> > > After talking with folks, the threat of irq injections on virtual guests
> > > made sense.  However, when discussing if this was possible on bare metal
> > > machines, we could not come up with a plausible scenario.
> > > 
> > The irq injections is something that a guest with assigned device does
> > to attack a hypervisor it runs on. Interrupt remapping protects host
> > from this attack. According to pdf above if x2apic is disabled in a
> > hypervisor interrupt remapping can be bypassed and leave host vulnerable
> > to guest attack. This means that situation is exactly opposite: warning
> > has sense on a bare metal, but not in a guest. I am not sure that there is
> > a hypervisor that emulates interrupt remapping device though and without
> > it the warning cannot be triggered in a guest.
> 
> Ah, it makes sense.  Not sure how I got it backwards then.  So my patch is
> pointless then?  I'll asked for it to be dropped.
Yes, it is backwards.

> 
> >From my previous discussions with folks, is that KVM was protected from
> this type of attack.  Is that still true?
> 
Copying Alex. He said that to use device assignment without interrupt
remapping customer needs to opt-in explicitly. Not sure what happens
with interrupt remapping but with x2apic disabled.

The problem is not limited to virtualization BTW. Any vfio user may
attack kernel without interrupt remapping so vfio has the same opt-in.
 
--
			Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ