linux-kernel - Re: [PATCH 0/3] x86/microcode: support for microcode update in Xen dom0

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Oct 2011 12:18:22 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Borislav Petkov <bp@...64.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 10/12/2011 11:18 AM, H. Peter Anvin wrote:
> On 10/12/2011 03:16 AM, Borislav Petkov wrote:
>> Why would a xen microcode solution would even be contingent on how
>> upstream Linux solves it (and when)?
>>
> Agreed... especially since Xen is "special" when it comes to booting anyway.

"Special" only in the sense that you need a new line in grub.

But doing boot-time microcode is a lot more "special" since it would
require distros to move the microcode files to /boot.  That would either
mean having two sets of microcode packages, or also changing the way
that Linux does its microcode loading (if only by changing the paths,
but I have no idea what that implies since its all tied up with the rest
of the firmware loading stuff).

The whole thrust of the Xen upstreaming work has been to minimize the
amount of arbitrary "specialness" so that its as easy as possibly for
people and distros to deploy and use Xen.

With respect to microcode loading, this patch means that users and
distros just don't need to worry about microcode any more.  It packages
and operates exactly like it would for native Linux, which is exactly
how we like it.

While doing the whole boot time multiboot thing may offer some small
hypothetical technical advantages, it has the significant cost of just
complicating the whole deployment and use story.

If there were a general shift to "this is how we're going to do
microcode in the future", then Xen will happily go along for the ride. 
But for right now, this patch seems like the pragmatic solution.

I think the real question is where there's something objectionable about
the patch itself?

Thanks,
    J
--
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/