Message-ID: <4D475099.1080004@goop.org>
Date:	Mon, 31 Jan 2011 16:15:21 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>,
	Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xen Devel <Xen-devel@...ts.xensource.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
Subject: Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen
 dom0

On 01/31/2011 03:41 PM, Borislav Petkov wrote:
> 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?

My understanding of what you're proposing is:

   1. the normal CPU-specific microcode driver starts up
   2. an if (xen) test overrides the apply_microcode to call a
      Xen-specific function
   3. the driver requests the firmware, loads and verifies it as normal
   4. the microcode is applied via the Xen apply_microcode function

With (2) needing a Xen-specific change to both the Intel and AMD drivers.

If not, what are you proposing in detail?

Are you instead thinking:

    * Xen-specific microcode driver starts up
    * It calls either the intel or amd request_microcode_fw as needed
    * apply the the loaded data via hypercall

?

But all this is flawed because the microcode_intel/amd.c drivers assume
they can see all the CPUs present in the system, and load suitable
microcode for each specific one.  But a kernel in a Xen domain only has
virtual CPUs - not physical ones - and has no idea how to get
appropriate microcode data for all the physical CPUs in the system.

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

Right.  There's nothing really for the driver to do (kernel or Xen). 
The Intel driver does a bunch of checksum checking, which is presumably
useful for detecting a corrupted firmware update early, and splits out
the chunks specific to the current cpus.  The AMD driver does no
checking per-se, but also looks for processor-specific microcode update
chunks.

In the Xen case, since a domain is not necessarily seeing all the
details of the underlying physical cpus, it makes most sense for
usermode to just pass in the whole microcode file and let Xen do all the
checking/filtering based on complete knowledge of the system.

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

CPU vendors test Xen, and Intel is particularly interested in getting
this microcode driver upstream.  The amount of duplicated code is
trivial, and the basic structure of the microcode updates doesn't seem
set to change.  Since Xen has to have all sorts of other CPU-specific
code which at least somewhat overlaps with what's in the kernel a bit
more doesn't matter.

(It's interesting that nobody seems to have been interested enough in
Via to have ever implemented a microcode driver for it - perhaps they
only ever do it from BIOS.)

    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/

Powered by blists - more mailing lists