All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Don Zickus <dzickus@redhat.com>
Cc: x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Prarit Bhargava <prarit@redhat.com>
Subject: Re: [PATCH] x86, x2apic: Only WARN on broken BIOSes inside a virtual guest
Date: Thu, 31 Jan 2013 20:52:00 +0200	[thread overview]
Message-ID: <20130131185200.GA1757@redhat.com> (raw)
In-Reply-To: <1359650435-73586-1-git-send-email-dzickus@redhat.com>

On Thu, Jan 31, 2013 at 11:40:35AM -0500, Don Zickus wrote:
> In commit "41750d3 x86, x2apic: Enable the bios request for x2apic optout"
> it was explained how OEMs are trying to opt out of using x2apics.
> 
> That commit moved code around and screamed with a WARN if the BIOS
> opted out of x2apic mode.  Fair enough.
> 
> This code hit our RHEL distro and OEMs started complaining that the
> WARN is scaring their customers and asked we tone it down to a
> pr_warn().
> 
> Before we did that, we thought we should change it upstream too.
> Upstream complained that WARN was necessary due to a serious
> security threat, namely irq injections.  Hard to argue that.
> 
> This left us between a rock and a hard place.  We toned down the
> WARN in RHEL to keep our customers happy.  But this leaves us with
> a perpetual patch in RHEL and possibly covering up a security threat.
> 
> I poked around to understand the nature of the security threat and why
> OEMs would want to leave themselves vulnerable.  The only security
> threat I could find was this whitepaper talking about Xen and irq
> injections:
> 
> 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.

--
			Gleb.

  reply	other threads:[~2013-01-31 18:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-31 16:40 [PATCH] x86, x2apic: Only WARN on broken BIOSes inside a virtual guest Don Zickus
2013-01-31 18:52 ` Gleb Natapov [this message]
2013-01-31 19:34   ` Don Zickus
2013-01-31 20:00     ` Gleb Natapov
2013-01-31 20:52       ` Alex Williamson
2013-02-01 22:00         ` Andy Lutomirski
2013-02-01 22:57           ` [PATCH] intel_irq_remapping: Clean up x2apic optout security warning mess Andy Lutomirski
2013-02-03 19:29             ` [tip:x86/apic] x86/intel/irq_remapping: Clean up x2apic opt-out " tip-bot for Andy Lutomirski
2013-02-04 18:20             ` [PATCH] intel_irq_remapping: Clean up x2apic optout " Don Zickus
2013-02-04 19:04             ` Alex Williamson
2013-02-04 19:19               ` Andy Lutomirski
2013-02-04 19:39                 ` Alex Williamson
2013-02-04 19:47                   ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130131185200.GA1757@redhat.com \
    --to=gleb@redhat.com \
    --cc=dzickus@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prarit@redhat.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.