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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 Apr 2010 17:05:47 -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

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

> > 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
> 
> Properly done, these aren't separate cases at all.
> 
> The E820 interface as specified doesn't reserve the address space below 1
> MB, because it is legacy space -- which is another way of saying "everyone
> already knows to reserve it."  The Right Thing[TM] to do is simply to
> modify the data output by E820 to reserve all non-memory space below 1 MB;
> this can (and should) be done in platform-specific initialization code to
> allow overrides.
> 
> Once that is done, both your (2) and (3) cases are nothing but special
> subcases of (1).  That's what I would like to see as the right solution,
> but it is clearly too late to do that in .34.
> 
> Bjorn's solution is very attractive for .34 since it is so simple, but
> it's not a complete solution.

Glad we agree.  As I said (and echoing Bjorn), I think it would be best
to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
We want and need to do allocations from the special region, so we
should mark it as such.

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