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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>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.

Use the latest version of dracut with --something-microcode and it will attach 
the microcode blob to initramfs automatically.
>
>    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@xxxxxxxxxxxxx
>>>> http://lists.xen.org/xen-devel
>>>>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel