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]

Date:	Thu, 25 Jul 2013 15:42:25 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
CC:	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

So the bootloader is just as likely to step on things... what happens when/if it does?

Ingo Molnar <mingo@...nel.org> wrote:
>
>* Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
>
>> Patch 2/2 has the description, but suffice it to say I'm 
>> not really pleased with this, though it does solve a 
>> problem we have.  On some machines, we get MMIO space 
>> allocated on top of this hidden memory, which can cause 
>> problems.  I'm not sure if there are similar problems for 
>> other hunks of the address space; if so it's possible 
>> this could be made more general (though the bits for 
>> looking up the address of this region are definitely 
>> Intel graphics specific).
>
>It looks pretty hardware specific. Discovering it the hard 
>way and marking it e820 reserved in an early quirk is what 
>the firmware should have done to begin with - and I doubt 
>the kernel could do anything significantly cleaner.
>
>How does Windows manage to not crash? By luckily never 
>allocating PCI resources on top of the RAM? Or does it have 
>a quirk?
>
>> Chris has some patches on top to add a new E820 type so 
>> we can look up the region later, which removes some 
>> redundant code in the i915 driver at least.
>> 
>> Any comments?  I assume no one likes this, but maybe it's 
>> just another early quirk we'll have to live with...
>
>No strong feelings against it - my only suggestion would be 
>to make this more visible - right now it's added as e820 
>reserved which hides amongst other areas already marked 
>reserved - would a low-key printk() of the range added make 
>it more apparent that a kernel quirk activated here?
>
>Just so that people know that it came from the kernel, not 
>the firmware.
>
>But in any case:
>
>Acked-by: Ingo Molnar <mingo@...nel.org>
>
>Thanks,
>
>	Ingo

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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/