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 23:14:52 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
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 Tue, Dec 11, 2012 at 4:37 PM, H. Peter Anvin <hpa@...or.com> wrote:
> 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.
>>
>
> For 32 bits, we don't need it, because we can just run this part in
> linear mode.  It also doesn't help us on 32 bits since we are limited by
> virtual address space anyway.

please check draft version for early_memremap version for microcode...

1. make find_cpio take map/unmap function pointer, and use that to set
sliding window.
2. clean the end to size in some function to fix -1 offset
3. update_mc_saved to change back to __va for ap etc and after
initrd_relocation.

NOT EVEN COMPILING TEST.

should use this one on top of early_ioremap_head64.patch that i sent
it out this afternoon.

Thanks

Yinghai

Download attachment "fix_microcode.patch" of type "application/octet-stream" (11724 bytes)