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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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.

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

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

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