This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH 0/2] x86/microcode: support for microcode update

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0
From: Borislav Petkov <bp@xxxxxxxxx>
Date: Tue, 1 Feb 2011 00:41:31 +0100
Cc: Xen Devel <Xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>
Delivery-date: Mon, 31 Jan 2011 15:42:33 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1296517295; bh=0umb/QYiG1k1TGVDqOzvaWk14RbRUM1uHQM0sJdpbcY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=TIQZqY8zTWTnwzUFr3GKI+O6XBrDIrNJFriCE6 8VRs062e/3EANKrzSljNvS2santEy7SZ6Td+aXb+mfZXD8O9zlHHjA3y4B/nxtnYNkb yLfsDx62n/lIF8Q70c3dWjozds390QYL3fikEMQgzfjKeLzRPifHSIDZPS0VRtryQw=
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1296517294; bh=0umb/QYiG1k1TGVDqOzvaWk14RbRUM1uHQM0sJdpbcY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=tGpkV/ttbP0R5r6AhgcOcANqMOxL3InZ+X+4zP ZQvlcJK11O39ZVWu9sp5gODKFGvgj3KNRveA44TxVdjErGgYjz3Q2S173iIHMuohSJR +OkW3dTwoSWEDKSoBMIWvLTYkOqA2jphBpRu3zd+dr5z8m4aT7S711Jgb2GJovu+UU=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D46FC9F.6090309@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Borislav Petkov <bp@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Xen Devel <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
References: <cover.1296259339.git.jeremy.fitzhardinge@xxxxxxxxxx> <20110130113356.GA27967@xxxxxxxxxxxx> <4D461FB9.5050807@xxxxxxxx> <20110131070241.GA22071@xxxxxxxxxxxx> <4D46FC9F.6090309@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Jan 31, 2011 at 10:17:03AM -0800, Jeremy Fitzhardinge wrote:
> On 01/30/2011 11:02 PM, Borislav Petkov wrote:
> >> Well, I was trying to avoid putting Xen-specific code into the existing
> >> Intel/AMD loaders.  That doesn't seem any cleaner.
> >>
> >> I could export "my firmware pathname" functions from them and have the
> >> Xen driver call those, rather than duplicating the pathname construction
> >> code.  Would that help address your concerns?
> > Well, I was thinking even more radically than that. How about
> >
> > 1. microcode_xen.c figures out which struct microcode_ops to use based
> > on the hw vendor;
> >
> > 2. overwrites the ->apply_microcode ptr with the hypercall wrapper
> >
> > 3. dom0 uses it to load the firmware image and do all checks to it
> That could be made to work, but I don't really see it as being an
> improvement.

WTF? How is

* almost no code duplication
* not adding Xen-specific checks to generic arch code
* relying on already tested codepaths

not an improvement?

> The whole "overwriting bits of other people's ops structures" thing
> seems like a pretty bad idea for long term maintainability.

I don't think that's an issue: you either load microcode_xen in dom0
(x)or the respective vendor driver on baremetal.

> > 4. eventually, the hypervisor gets to apply the _verified_ microcode
> > image (no more checks needed) using the vendor-specific application
> > method.
> >
> > This way there's almost no code duplication, you'll be reusing the
> > vendor-supplied code in baremetal which gets tested and updated
> > everytime it needs to and will save you a bunch of work everytime
> > there's change to it needed to replicate it into the hypervisor.
> In general Xen tries to avoid trusting its domains.  Admittedly, dom0 is
> special in that it is already somewhat trusted, but even dom0 is
> constrained by Xen.  For microcode, Xen just depends on it to provide a
> best-possible microcode file, then Xen+the CPU do the work of fully
> validating it and installing it.

Well, the CPU doesn't trust the microcode provided by the software
either. And why should it?

All I'm saying is, you should try as best as possible to avoid code
duplication and the need for replicating functionality to Xen, thus
doubling - even multiplying - the effort for coding/testing baremetal
and then Xen. Microcode is a perfect example since the vendors do all
their testing/verification on baremetal anyway and the rest should
benefit from that work.



Xen-devel mailing list