Re: [PATCH] microcode: Scan the multiboot payloads for cpio format microcode blob. (v3).

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 09/25/2013 01:03 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 25, 2013 at 12:36:01PM -0700, Jeremy Fitzhardinge wrote:
>> On 09/25/2013 05:57 AM, Konrad Rzeszutek Wilk wrote:
>>> The way to use this is by the 'ucode' parameter. It has now two meanings:
>>>   [<index>|initrd]
>>>
>>> Which CANNOT be used together. By default this auto scanning is turned off
>>> as Jan pointed out that: "Xen otoh has to be careful not to
>>> mis-interpret a blob passed to a non-Linux Dom0 as a CPIO. How
>>> good the guarding against this is in the code I'll have to check".
>>> [...]
>>> There is also the question whether the parameter should be 'cpio','initrd'
>>> or 'scan'. As in the future the extraction of the payload could be from
>>> a different format than the cpio (say a microcode blob with an magic
>>> string at the start). The author believes that at that time the logic
>>> to scan the mulitboot payloads can be expanded to also scan formats other
>>> than cpio format.
>> Why treat a microcode.bin and cpio differently? Aren't they both just
>> file formats that can be parsed to (possibly) extract microcode update
>> info? That being so, why change the ucode parameter? Wouldn't you just
> Unfortunatly no. The blobs are blobs that have no signature unless
> you are an microcode driver and know what to look for.

Right, but that's what we're talking about here isn't it?

> The cpio format provides a means of identifying (the name of the file
> in the archive matches a specific string) the microcode blob.

Yep.

>> set it to ucode=N, where N is the module index either a microcode.bin or
>> cpio or anything else multiboot module?
> That is an option too. It would mean re-organizing the code more as
> the existing 'index' ucode grabs the multiboot payload and does not
> allow the Linux kernel access to it. Would have to relax that somehow.
>
> Lastly with the cpio format the microcode blob can be in initframfs.cpio
> or in a seperate cpio archive (so two cpio archives along with Linux kernel).
>
> Besides that, from the GRUB perspective it makes it much easier to support
> as the grub tools can just add 'ucode=scan' and not worry about indexing
> in the right payload.
>
> Or that is me being lazy. I would rather have this thing be automatic and
> be on by default and scan all the images and pluck the data out. No
> dependency on anything at that point (which is what Linux does right now).

Something completely automatic would be ideal, I agree. I just went
through the process of setting up ucode with the microcode.bin blob, and
while its straightforward I suspect some update will break it
inadventently, so something that is more in line with what Linux itself
wants to do is good.

It just occurred to me; I haven't dug into the existing or new code to
see whether I'm really making things more complex.

    J


>
>>     J
>>
>>
>>> These patches are also available at:
>>>
>>>   git://xenbits.xen.org/people/konradwilk/xen.git microcode.v3
>>>
>>>  docs/misc/xen-command-line.markdown |  14 ++-
>>>  xen/arch/x86/microcode.c            | 177 ++++++++++++++++++++++++++++++++----
>>>  xen/common/Makefile                 |   2 +-
>>>  xen/common/earlycpio.c              | 151 ++++++++++++++++++++++++++++++
>>>  xen/include/xen/earlycpio.h         |  14 +++
>>>  5 files changed, 337 insertions(+), 21 deletions(-)
>>>
>>> Konrad Rzeszutek Wilk (2):
>>>       microcode: Scan the initramfs payload for microcode blob.
>>>       microcode: Check whether the microcode is correct.
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>>