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: <48B70ABC.8010805@zytor.com>
Date:	Thu, 28 Aug 2008 13:29:48 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Yinghai Lu <yhlu.kernel@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: split e820 reserved entries record to late

Linus Torvalds wrote:
> 
> So e820 is fairly trustworthy, but we know that it will have various 
> random things marked as reserved because they are special in some way (but 
> we don't know _how_ they are special - they may well be real BAR's that 
> just have a fixed meaning to ACPI or whatever).
> 

My thinking is that if we run into a region which is reserved in e820 
but points to a real BAR, we would want to keep that BAR pinned, since a 
legitimate BIOS might use this mechanism to indicate that the device 
implemented by that BAR is used by SMM or ACPI.  If not, in most cases 
we will only have wasted some address space.  The sucky case, of course, 
would be an uninitialized BAR pointing into unusable address space which 
happens to be reserved in e820.  This seems very difficult to 
disambiguate from the above case through any algorithm that I can think of.

> Of course, I bet there will be cases where this causes problems. It feels 
> like we have _never_ worked around some PCI BAR allocation problem without 
> hitting another unexpected one..

I suspect that for any possible behaviour, there will be at least one 
system out there doing something broken for it :(

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ