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:	Tue, 11 Dec 2012 22:57:03 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Borislav Petkov <bp@...en8.de>,
	"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>,
	"hpa@...ux.intel.com" <hpa@...ux.intel.com>,
	"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/11/2012 04:27 PM, Yinghai Lu wrote:
> On Tue, Dec 11, 2012 at 3:57 PM, H. Peter Anvin <hpa@...or.com> wrote:
>> Well, we could invoke it on the bootloader page tables, but as you say
>> it may not be a good idea... depending on how much memory we may be
>> talking about.  One solution -- which I have to admit is starting to
>> sound really good -- is to set up a #PF handler which cycles through a
>> set of page tables and creates a "virtual identity map"... it does have
>> the advantage of making the entire physical address space available
>> without any additional funnies.
>
> so that #PF handler will work before
> arch/x86/kernel/setup.c::setup_arch/early_trap_init
>
> early_strap_intit will install another handler there for #PF
>
> for 64bit, moving early_ioremap_init ahead is very simple, like attach patch
>
> but for 32 bit looks like it is not that easy.
>

Here is an incomplete patch for illustration purposes only what I mean 
with an early-mapping #PF handler.  This creates a set of transient page 
tables on demand which allows us to access memory as if it was all 
mapped, but using only O(1) storage.  The replacement policy is trivial: 
if we run out, we start over from scratch.

The "identity page tables" used during the transition to high virtual 
addresses are kind of magic; there is a bunch of extra aliases created, 
but the way it is done guarantees that the range we actually cares about 
is mapped correctly.  The aliases don't matter and get scrubbed shortly 
thereafter anyway.

This should, obviously, be used on native only -- in particular Xen 
should instead rely on the initial page tables provided by the domain 
builder, which should map all physical memory.

Once the proper memory-map-aware page tables are built, we should turn 
this off by swapping to the newly built real init_level4_pgt instead.

	-hpa

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

View attachment "diff" of type "text/plain" (12706 bytes)