linux-kernel - Re: [PATCH] x86/pci: make pci_mem

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: <20090418191425.GA19565@elte.hu>
Date:	Sat, 18 Apr 2009 21:14:25 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org, yannick.roehlly@...e.fr
Subject: Re: [PATCH] x86/pci: make pci_mem_start to be aligned only -v4

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Sat, 18 Apr 2009, Ingo Molnar wrote:
> > 
> > Am i missing something?
> 
> We also try to avoid random motherboard resources etc that aren't 
> reserved or documented by the BIOS. It's better to go into big 
> holes. It's also better to try to keep as close to the old 
> (tested) behavior.

Yeah - i'm not suggesting any change in behavior, nor am i 
suggesting any risky behavior. The current code seems to work quite 
well.

I'm just suggesting (maybe foolishly) that instead of having any 
gap-rounding logic at all, add artificial entries to the e820 map to 
'extend' and round up any odd ending entries.

I.e. explicitly manage all the 'hole' space to be nicely rounded and 
to be far away from any T-Seg or other sekrit motherboard resource 
danger area.

We'd do this after PCI static allocations (so we dont ever stomp on 
real, known resources) but before PCI dynamic allocations.

The e820 printout would look literally like this:

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)       0.639 MB RAM
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)     0.001 MB
                                                [ hole ]       0.250 MB
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)     0.125 MB
 BIOS-e820: 0000000000100000 - 000000003ed94000 (usable)    1004.5   MB RAM
 BIOS-e820: 000000003ed94000 - 000000003ee4e000 (ACPI NVS)     0.7   MB
 BIOS-e820: 000000003ee4e000 - 000000003fea2000 (usable)      16.3   MB RAM
 BIOS-e820: 000000003fea2000 - 000000003fee9000 (ACPI NVS)     0.3   MB
 BIOS-e820: 000000003fee9000 - 000000003feed000 (usable)       0.15  MB RAM
 BIOS-e820: 000000003feed000 - 000000003feff000 (ACPI data     0.07  MB
 BIOS-e820: 000000003feff000 - 000000003ff00000 (usable)       0.004 MB RAM
 BIOS-e820: 000000003ff00000 - 0000000040000000 (guard)        1.0   MB
                                               	[ hole ]    3072.0   MB

The '(guard)' entry at the end i added above.

This way we intentionally create a 'free physical address space' 
hole space that is the same as the rounding logic. No rounding 
needed anywhere - as all the remaining address space is well-rounded 
already. Plus we'd also _see_ all our rounding logic by looking at 
the '(guard)' entries.

Or maybe there's some aspect of gap-rounding that cannot be 
expressed in such a static way?

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