linux-kernel - Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU

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:	Wed, 19 Dec 2012 15:56:22 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jacob Shin <jacob.shin@....com>
CC:	Borislav Petkov <bp@...en8.de>, Yinghai Lu <yinghai@...nel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"Yu, Fenghua" <fenghua.yu@...el.com>,
	"mingo@...nel.org" <mingo@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Stefano Stabellini <Stefano.Stabellini@...citrix.com>
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.

	-hpa

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