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