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]

Message-ID: <50C76F9E.4080001@zytor.com>
Date:	Tue, 11 Dec 2012 09:38:38 -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 09:15 AM, Yinghai Lu wrote:
>
> No, that is not right place. initrd could be loaded anywhere like way
> high by bootloader.
>

Only *after* your changes... the current protocol doesn't allow that.

Anyway, we need to deal with it, see below.

> to make code simple, we should have following sequence in setup_arch
>
> early_ioremap_init()
> early_update_microcode()...
> early_cpu_init()
>
> early_update_microcode could use early_ioremap to access initrd ramdisk area.

We need there to be as little machinery as possible, *especially* 
machinery involving paging, before the microcode gets loaded.  I would 
prefer if we could load the microcode before enabling paging at all, but 
that would mean running it in 32-bit mode which really isn't practical, 
so we have to deal with scaffolding here.

We really should cycle the paging off after this happens, but that 
really isn't possible until the trampoline gets set up later, since we 
may not have any other place to stand in low memory.

This complexity is the cost of allowing the kernel to load above the 4G 
mark.

Now, to be solution-focused...

I quite frankly don't see anything in early_remap_init() which can't be 
done at compile time.  All it does is set up some data structures which 
could just as well be statically generated, and then it would be 
available from the very beginning and thus usable for this purpose. Xen 
might need extra song & dance, but that can be done in Xen-specific code.

The Xen-induced (and since then expanded by others) 32-bit braindamage 
of having __FIXADDR_TOP be a variable is a huge problem, obviously, but 
it doesn't affect 64 bits which is what we're dealing with here.  There 
*is* a way to fix it on 32 bits without breaking Xen, which is to move 
the fixmap to the beginning of kernel virtual space instead of the end 
-- this boundary is known at compile time.

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