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:	Wed, 19 Dec 2012 15:56:22 -0800
From:	"H. Peter Anvin" <>
To:	Jacob Shin <>
CC:	Borislav Petkov <>, Yinghai Lu <>,
	"H. Peter Anvin" <>,
	"Yu, Fenghua" <>,
	"" <>,
	"" <>,
	"" <>,
	Konrad Rzeszutek Wilk <>,
	Stefano Stabellini <>
Subject: Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update
 ucode on Intel's CPU

On 12/19/2012 03:21 PM, Jacob Shin wrote:
> On Thu, Dec 20, 2012 at 12:03:29AM +0100, Borislav Petkov wrote:
>> On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
>>> I can check but right, they might be used up. But even if we had slots
>>> available, the memory range that needs to be covered is in large
>>> enough address and aligned in such a way that you cannot cover it with
>>> variable range MTRRs.
>> Actually, if I'm not mistaken, you only need to cover the HT hole with
>> one MTRR - the rest remains WB. And in order the mask bits to work, we
>> could make it a little bigger - we waste some memory but that's nothing
>> in comparison to the MCE.
> Actually all memory hole above 4GB and under TOM2 needs to be marked
> as UC, if the kernel just blanket calls init_memory_mapping from 4GB
> to top of memory.
> Right we would be loosing memory, and I think depending on the
> alignment of the boundary and how many MTRRs you have avaiable to use,
> significant chunks of memory could be lost. I need to go refresh on
> how variable range MTRRs are programmed, it has been a while.

In this particular case an MTRR at 0xe000000000 would lose 896 MB of 
RAM, or just under 0.1% of the total.

If it is only the HT region that causes trouble and not the rest of the 
hole you could just plant an MTRR at 0xfc00000000 and not lose any 
memory at all.


H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists