[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).
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |