linux-kernel - Re: Ugly patches for stolen reservation

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: <20130726202418.GD21415@gmail.com>
Date:	Fri, 26 Jul 2013 22:24:18 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, intel-gfx@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org, mingo@...e.hu, tglx@...utronix.de,
	torvalds@...ux-foundation.org
Subject: Re: Ugly patches for stolen reservation


* Jesse Barnes <jbarnes@...tuousgeek.org> wrote:

> On Thu, 25 Jul 2013 20:31:27 -0700
> "H. Peter Anvin" <hpa@...or.com> wrote:
> 
> > On 07/25/2013 07:14 PM, Jesse Barnes wrote:
> > > To clarify: it'll either be marked reserved or not listed at all in e820, which is why I did this early, before any other e820 stuff like the "RAM buffer" are allocated, and before we could use the iomem resource (or maybe we could even early per Linus? I'll check). 
> > > 
> > > Jesse
> > 
> > If it is marked reserved or not listed at all it is much less of an
> > issue.  Reserved is in fact the correct thing; not listed at all really
> > isn't very problematic in most cases.
> 
> Yeah the problems seem to fall into two categories:
>   1) mmio space is allocated in this range:
>      https://bugs.freedesktop.org/show_bug.cgi?id=66726
>   2) range gets partially allocated to the "RAM buffer"
>      https://bugs.freedesktop.org/show_bug.cgi?id=66844
> 
> Case (1) is the one that worries me.  I'm guessing it'll mainly be a
> problem on machines where MMIO space is limited or somehow structured
> such that PCI resources end up there when we allocate them.  Depending
> on what gets put there and the decode priority, behavior may be poor.
> 
> Case (2) isn't harmful, but ends up causing our driver to skip stolen
> memory initialization, because of the conflict.
> 
> Anyway I'll look at Linus's suggestion of reserving in the iomem
> resource really early and roll in Chris's stuff if that doesn't work
> out.

Am I being too pedantic in expecting that we still mark it 
e820-reserved?

This area really isnt an ordinary PCI resource such as a 
BAR or an MMIO region. It's truly system RAM (which cannot 
be moved/reallocated), used by graphics hardware, and the 
firmware should have marked it reserved.

(The end result should be the same in any case, so this is 
a detail.)

Thanks,

	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/