linux-kernel - Re: [PATCH] x86: split e820 reserved entries record to late v2

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] [day] [month] [year] [list]

Date:	Thu, 28 Aug 2008 17:21:09 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Yinghai Lu <yhlu.kernel@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Witbrodt <dawitbro@...global.net>,
	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 v2

Ingo Molnar wrote:
> 
> Here we have the problem of overlap i outlined earlier: if there's a 
> partial overlap at this stage (as i think it can happen in the hpet case 
> on David's box), we wont insert the E820_RESERVED resource.
> 
> The hpet hang will be solved, because we dont reprogram the BAR, but we 
> now keep the formerly e820-reserved area as 'free' - which the PCI code 
> could allocate new resources into - which could cause other problems 
> (hangs, non-working devices, etc.) down the line.
> 
> Which most likely wont happen currently in practice (there's enough free 
> space elsewhere), but it's still a not truly 'free' area and it would be 
> nice to have a complete and correct picture, based on all sources of 
> information we have.
> 

This may be a rehash of things previously discussed in this thread; my 
email seems to be a bit flakey to the point that I don't know if I have 
gotten all the messages.

Either way, Ingo mentioned in a private messages four steps, basically 
summarizing the above email:

1 - first we allocate the absolute essentials (e820 RAM and a few low
     RAM specials)
2 - then we register all existing PCI resources - but do not reallocate
     any PCI resources that conflict with existing step #1 resources
3 - then we allocate e820 reserved entries (and whatever special non-PCI
     resources we might know about in general) - these are less trusted
     than any of the existing PCI resources but still it can hurt us
     badly if the PCI code allocates new resources on them.
4 - then the PCI code can run and allocate free resources to all the
     zero, not yet allocated BARs, and can reallocate any resources that
     might conflict with existing [step #1 or step #3] registered
     resources.

I agree that this is almost certainly what we should be doing; there is 
a difference between claiming resources already allocated and allocating 
resources to new address space, in which case we want to be as 
conservative as possible.

The key, of course, is that nothing goes in #1 unless we are bloody 
damned sure that if a BAR points there, that BAR is unconditionally 
broken and pointing into hyperspace.  Something claiming RAM or, say, 
the legacy KBC might fall in this area.

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