linux-kernel - Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS

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: <20100426162517.4ad308ff@virtuousgeek.org>
Date:	Mon, 26 Apr 2010 16:25:17 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Bjorn Helgaas <bjorn.helgaas@...com>,
	Andy Isaacson <adi@...apodia.org>,
	"R. Andrew Bailey" <bailey@...mai.com>,
	Yinghai <yinghai.lu@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, guenter.roeck@...csson.com,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Renninger <trenn@...e.de>, yaneti@...lera.com
Subject: Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below  
 BIOS_END

Sorry, sounds like we're talking about a few different things here:
  1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
  2) devices which sit in e820 ram or other space below 1M
  3) how to hand out space from the 0-1M region

Bjorn's patch fixes (3) so that regular PCI devices don't get space
there, which makes sense.

Some devices may be in the special region, but were pointed there by
the BIOS.  Generally this should be ok, so drivers requesting this
space should be allowed to get at it, but we should avoid putting
anything else there.

And below it sounds like you're talking about (1).  If so, then yes I
guess we need a solution there, which will allow drivers to bind to
these "reserved" devices, even though the BIOS has marked them as off
limits, at least as far as e820 goes.

So perhaps both (1) and (2) could be put into a new, special IO
resource space, or could use a new flag, since "busy" doesn't really
reflect what's going on there very well, as Bjorn pointed out.

Jesse

On Mon, 26 Apr 2010 16:02:57 -0700
"H. Peter Anvin" <hpa@...or.com> wrote:

> I don't think it's sufficient, actually.  We regularly see machines where devices point into e820_reserved memory above 1 MB - because it's a platform device or because firmware (e.g. smm) is touching the device.  I think Bjorn's fix is great for .34, but longer term I think we need to structure the code to actually handle reserved regions differently from occupied/forbidden regions.
> 
> "Jesse Barnes" <jbarnes@...tuousgeek.org> wrote:
> 
> >On Mon, 26 Apr 2010 14:44:50 -0700
> >"H. Peter Anvin" <hpa@...or.com> wrote:
> >
> >> >
> >> > Agreed.  The trickier part is handling any platform devices that
> >> > request_resource against that space.  But maybe we don't need to do
> >> > anything special; just making sure we avoid it in the PCI "BIOS" code
> >> > as Bjorn did may be sufficient.
> >> >
> >> 
> >> Why is that hard?  If a platform device does a request_resource against
> >> that space, it's a request for specific address space and it should be
> >> granted.
> >
> >I was thinking if we made it a special resource type we'd have to
> >change any platform drivers to use it; i.e. it wouldn't be
> >IORESOURCE_MEM or IORESOURCE_IO but IORESOURCE_DRAGONS.  That way it
> >wouldn't be part of the normal resource space.
> >
> >But that's definitely overkill.  I think Bjorn's fix is sufficient.
> >
> >-- 
> >Jesse Barnes, Intel Open Source Technology Center
> 


-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/