[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] microcode: Scan the multiboot payloads for cpio format microcode blob. (v3).
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@xxxxxxxxxxxxx > > http://lists.xen.org/xen-devel > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |