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: <a96459c7f3573eef81dd6d6c4e3dedd8.squirrel@www.zytor.com>
Date:	Mon, 26 Apr 2010 16:49:55 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Jesse Barnes" <jbarnes@...tuousgeek.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"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

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.

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