linux-kernel - Re: [PATCH v2] irq: add quirk for broken interrupt remapping on 55XX chipsets

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]

Date:	Thu, 4 Apr 2013 16:02:09 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Don Dutile <ddutile@...hat.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Prarit Bhargava <prarit@...hat.com>,
	Don Zickus <dzickus@...hat.com>,
	Jiang Liu <jiang.liu@...wei.com>,
	Asit Mallick <asit.k.mallick@...el.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"open list:INTEL IOMMU (VT-d)" <iommu@...ts.linux-foundation.org>,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH v2] irq: add quirk for broken interrupt remapping on 55XX
 chipsets

On Thu, Apr 04, 2013 at 12:41:27PM -0600, Bjorn Helgaas wrote:
> On Thu, Apr 4, 2013 at 11:51 AM, Neil Horman <nhorman@...driver.com> wrote:
> 
> > Oh, you want the bug report that I'm fixing this against?  Sure, I can do that.
> > I thought you wanted me to include a url in the WARN_TAINT, with which user
> > could report occurances of this bug.  Yeah, the bug that this is reported in is:
> > https://bugzilla.redhat.com/show_bug.cgi?id=887006
> >
> > Its standing in for about a dozen or so variants of this issue we've seen
> 
> Exactly -- I'm just hoping for something in the changelog.  BTW, this
> particular bugzilla is not public.
> 
Ok, that I can do, I'll get the bz fixed up to be public in a bit.


> > Regardless, theres also the security issue to consider here - namely that
> > disabling irq remapping opens up users of virt to a possible security bug
> > (potential irq injection).  Some users may wish to live with the remapping
> > error, given that error typically leads to devices that need to be
> > restarted/reset to start working again, rather than live with the security hole.
> > I rather like the warning, that gives users a choice, but I'll spin up a version
> > that just disables it if you would rather.
> 
> I don't believe users will want to make a choice like that or even be
> sophisticated enough to do it, at least not based on something in
> dmesg.  I'm pretty sure I'm not  :)
> 
> The only supportable thing I can imagine doing would be:
> 
>   - Disable interrupt remapping if this chipset defect is present, so
> devices work reliably (they don't need whatever restart/reset you
> referred to above).
>   - Disable virt functionality when interrupt remapping is disabled to
> avoid the security problem (I don't know the details of this.)
>   - Add a command-line option to enable interrupt remapping (I think
> "intremap=on" is currently parsed too early, but maybe this could be
> reworked so the option could override the quirk disable).
>   - Add release notes saying "boot with 'intremap=on' if you want the
> virt functionality and can accept unreliable devices."
> 
> That way the default behavior is safe and reliable (though perhaps
> lacking some functionality), and you have told the user a way to get
> safe and unreliable operation if he's willing to accept that.  At
> least, that's what I think I would want if I were in RH's shoes.
> 
Theres a long argument behind this, and I'm with you.  At the least I don't see
a problem with disabling it upstream, at least not a policy-oriented reason.
That said, having looked back at my notes, I do now recall a technical
impediment behind disabling interrupt remapping.  If we were to do this in an
early quirk, we would need to determine the status of the interrupt remapping
capability flag in the iommu in question.  Looking at the interrupt remapping
code, it appears that the capability flag isn't directly contained in the pci
config space, but rather in a memory mapped address range who's base address is
parsed out of an acpi table.  Since we check the irq_remapping_enabled flag in
the current quirk (which is set after the early quirks run), to do this in an
early quirk, we would need to somehow parse that base address register out of
the available acpi tables ourselves, and I'm not at all sure how to do that.  Do
you know if theres some available parsing mechanism that early in boot?  If so,
I can probably make this happen.

Neil

> Bjorn
> 
--
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/