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: <20111012214013.GD28723@aftab>
Date:	Wed, 12 Oct 2011 23:40:13 +0200
From:	Borislav Petkov <bp@...64.org>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"H. Peter Anvin" <hpa@...or.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	Xen Devel <xen-devel@...ts.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/3] x86/microcode: support for microcode update in Xen
 dom0

On Wed, Oct 12, 2011 at 05:31:50PM -0400, H. Peter Anvin wrote:
> On 10/12/2011 01:40 PM, Konrad Rzeszutek Wilk wrote:
> > Why is it paramount to do it as early as possible? As in, even doing
> > it before Linux kernel is invoked is preferred than during initrd runtime?
> 
> It is paramount to do it as early as possible *because the CPU is 
> broken*.  That's why there is a microcode update at all.  It is 
> *supposed* to be installed by BIOS, but for whatever reason it wasn't 
> (including user doesn't want to update the BIOS), so the very fact that 
> this is done in the OS at all is a bit of a fail.

Oh, that's easy: you know how OEMs support a platform for a while and
then move on to something new and stop updating BIOSen, including ucode
images contained in them?

Well, in that case, the OS is the last possible place where we want to
be able to apply the ucode. And, we want to apply it as _early_ _as_
_possible_. Bootloader doesn't cut it as hpa says below, so next comes
SMP cores bootup code. That's it.

> Doing it in the bootloader is messy because bootloaders typically
> aren't SMP-aware (and really shouldn't need to be), which leaves the
> OS. On native hardware it should ideally be done as early in the
> processor bringup as possible.

Yep.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ