Re: How many patches are missing in upstream Linux?

[Atom2 <ariel.atom2@web2web.at>]

I made some progress and there's good and bad news - see further below:

Am 11.03.14 21:33, schrieb Konrad Rzeszutek Wilk:
> On Tue, Mar 11, 2014 at 07:35:55PM +0100, Atom2 wrote:
>>
>>
>> Am 11.03.14 18:53, schrieb Konrad Rzeszutek Wilk:
>>> On Tue, Mar 11, 2014 at 06:38:52PM +0100, Atom2 wrote:
>>>>
>>>>
>>>> Am 10.03.14 21:55, schrieb Jeremy Fitzhardinge:
>>>> [snip]
>>>>>> The maintainer is being <insert your own opinion here>:
>>>>>>   - runtime microcode. What I had been told was to use the 'early
>>>>>>     microcode' mechanism - which is now implemented and Xen can also scan
>>>>>>     the initramfs to extract the microcode payload and apply it.
>>>>>
>>>>> I've never got that to work, but ucode=-1 with a microcode.dat multiboot
>>>>> modules works pretty well.
>>>>>
>>>>>>     But it misses the important part of server longevity in that the
>>>>>>     host might be running for years and the microcode might need to be
>>>>>>     updated during that time. bpetkov wasn't too thrilled about the
>>>>>>     runtime microcode and I hadn't come back to this yet to figure out
>>>>>>     what are his exact technical misgivings.
>>>>>
>>>>> I think, in the end, he (and Ingo) were advocating just doing a full
>>>>> emulation of the Intel/AMD update mechanism in the set/getmsr PV
>>>>> callbacks. Which is doable but... well, not pretty. Maybe a new attempt
>>>>> with get a new reception.
>>>>
>>>> I can add my experience from the perspective of a user trying to get
>>>> early microcode loading to work with my system:
>>>>
>>>> First of all I can confirm that it sort of works - but as Jeremy has
>>>> pointed out, there seem to be issues with including it into the
>>>> initramfs. After many unsuccessful tries I also only got it to work
>>>> when I used a separate entry in multiboot (grub2) which referred to
>>>> the blob for uploading the payload to the CPU.
>>>>
>>>> As soon as I had the microcode integrated into the initramfs as
>>>> described at
>>>> http://lists.xen.org/archives/html/xen-devel/2013-09/msg02902.html
>>>> the system would no longer boot with a message stating that it could
>>>> not find the root filesystem - I assume that was at the time when
>>>> the initramfs was about to be unpacked and loaded (if I recall
>>>> correctly there were no messages from the initramfs on screen).
>>>> Therefore I couldn't verify whether the microcode was actually
>>>> lodaded before that.
>>>
>>> Hm, that would imply that Linux couldn't skip past the 'non-gzip'
>>> payload of the initramfs. But it does work for me so I am wondering
>>> what I am doing differently.
>>>
>>> Could you send an email with your .config and perhaps your serial log
>>> if you still have it?
>> .config on its way to your email address; if you require the serial
>> log I would need to set that up and that would probably take a bit
>> of time.
>
> I think I do need that.
> I took a peek at it and tweaked my kernel to have similar
> options - that is disable the CONFIG_MICROCODE_EARLY in the kernel.
> Have similar initramfs.
Looking at the output of the serial console there are a few interesting 
message lines in there as follows:

[5.104573] Unpacking initramfs...
[5.104578] Initramfs unpacking failed: incorrect cpio method used; use 
-H newc option
[5.105969] Freeing initrd memory: 3716k (ffff880001e00000 - 
ffff8800021a1000)
>
> And this is what I boot with:
> [konrad@build-external tst031]$ cpio -it -F initramfs.cpio.gz
> .
> kernel
> kernel/x86
> kernel/x86/microcode
> kernel/x86/microcode/GenuineIntel.bin
> kernel/x86/microcode/AuthenticAMD.bin
> 1037 blocks
There was an error in my last try and the command above which worked at 
your end has actually always worked at my end as well. When it (rightly 
failed) in my last try I had mistakenly prepended the binary blob file 
and not the cpio archive containing the GenuineIntel.bin file (see my 
command further below) - but that was not the inherent problem to the 
failed boot attempts.
> [konrad@build-external tst031]$ file initramfs.cpio.gz
> initramfs.cpio.gz: ASCII cpio archive (SVR4 with no CRC)
Now there's a difference with my file:

# file /boot/initrd-3.11.7-hardened-r1-ucode.gz
/boot/initrd-3.11.7-hardened-r1-ucode.gz: ASCII cpio archive (pre-SVR4 
or odc)

I had created my file with cpio -oc (which is also what you suggested in 
the mail I linked above) and according to my memory and the man 
documents on the net (e.g. http://linux.die.net/man/1/cpio; the online 
man page only refers to info which I personally don't like) -c is 
equivalent to -H newc ... so what the heck is going on

But then I thought there's no harm in giving -H newc a try instead of -c 
and suddenly the file format changed to "SRV with no CRC". On further 
investigation I found out (through the behated info pages) that -c no 
longer is equivalent to -H newc but rather indicates "use the old 
portable format" whereas -H newc refers to the "new (SRV4) portable 
format". So there has been a change in the meaning of the -c option 
somewhen.

Now with the new portable format booting works from the modified initrd 
and the kernel obviously knows how to skip the start of the file with 
the uncompressed cpio archive. So far so good - and that's the good news.

Now to the bad news: The update of the microcode does not work if I use 
ucode=scan - and that's regardless of whether I include just the small 
10k file for my CPU into the GenuineIntel.bin file or the complete 
microcode for all Inter CPUs. The microcode of my CPU stays at 0x28 
whereas with ucode=-1 and a separate binary microcode blob (in non-cpio 
format) it gets updated to 0x29.

I don't think that it is linked to CONFIG_MICROCODE_EARLY not being set 
because as far as I understand linux would not be involved in the update 
as this is done by xen. Or am I wrong here?
>
> And Linux has no problems booting with it. Neither does
> Xen + Linux with 'ucode=scan' or without that option.
>
> Xen sees it:
> (XEN)  Init. ramdisk: ffffffff823f9000->ffffffff87858606
> Linux sees it:
> [    0.000000] RAMDISK: [mem 0x023f9000-0x07858fff]
> then unpacks it:
> [   13.261414] Unpacking initramfs...
> [   15.735168] Freeing initrd memory: 86400K (ffff8800023f9000 - ffff880007859000)
>
> so not sure what to make out of it.
>
> Is the ramdisk of yours a special filesystem? (Can you have squash/etc
> filesystems on ramdisks?)
>>>
>>>
>>>>
>>>> My feeling at that time was that the unpacking of the initramfs had
>>>> failed and it was probably more a linux issue rather than a XEN
>>>> issue - albeit the concatenated file which per the link above should
>>>> be created by
>>>>
>>>> "cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img"
>>>>
>>>> does not resemble a valid cpio archive any longer (you also can't
>>>> work with it on the command line - e.g. list its content). I assume
>>>> that though the kernel expects a valid cpio format file and
>>>> therefore is unable to unpack and subsequently fails.
>>>
>>> It should skip the bits that it does not understand.
>> Also on the CLI? I did another test right now:
>>
>> cat /boot/microcode.bin /boot/initrd-3.11.7-hardened-r1.gz >
>> /tmp/initrd-3.11.7-hardened-r1.gz
This was where my error referred to earlier came from - I prepended the 
microcode file and not a cpio archive.
>>
>> Now the initrd is prepended by the microcode. But when I do
>>
>> zcat /tmp/initrd-3.11.7-hardened-r1.gz | cpio -itv
>>
>> I get errors output from both gzip and cpio as follows:
>>
>> gzip: /tmp/initrd-3.11.7-hardened-r1.gz: not in gzip format
>> cpio: premature end of archive
>>
>> And to me that makes sense - how would gzip know how to deal with a
>> compressed image file prepended by an uncompressed part without
>> knowing the internal structure (i.e. at least its length). And cpio
>> is not able to unpack because it doesn't get valid input from gzip
>> through the pipe.
>>
>> Unless you say that the initrd can't be compressed - that would on
>> the face of it probably make sense, but even then a test with cpio
>> failed with errors.
>
> What about itself without the 'z' in? So cat /tmp/init.. | cpio -itv?
> You should see some files.
>
>>>>
>>>> But in any case, with the additional file in multiboot it works
>>>> flawlessly. The only catch is that the file distributed by Intel
>>>> (the microcode.dat which is a text file) has to be converted inot a
>>>> binary file (I also stripped it down to only contain the parts
>>>> necessary for my CPU, but I don't know whether that's strictly
>>>> necessary). And it must _NOT_ be a cpio archive in that case.
>>>
>>> You should be able to do 'cat /lib/firmware/intel_ucode/* > /boot/microcode.blob'
>>> and that would do it too.
>> I was not aware of that and had a hard time finding a solution.
>> Initially I thought the microcode.dat from Intel's website could be
>> used as is.
>>>
>>>>
>>>> Searching google there are a few tools available to convert the
>>>> Intel distributed microcode.dat to binary format and reduce it to
>>>> only the parts required for a specific CPU.
>>>>
>>>> Regards Atom2
>> I actually downloaded the source of a tool called iucode_tool-1.0.1
>> (don't ask me from where) and compiled it. There are two advantages
>> to that approach:
>> Firstly you can build from the Intel website's microcode.dat and you
>> don't have to wait until your distro (in my case gentoo which are
>> usually anyways pretty quick) makes the latest code available
>> through their regular distribution system.
>> Secondly iucode_tool  also provides an option to only extract the
>> code required for a specific processor (defaults to the one in the
>> PC) and thus makes the file much smaller (in my case it's only
>> 10,240 bytes as opposed to 576,512 bytes compared to the cat
>> /lib/firmware/... above).
>
> Right.
>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>>