Comment 46 for bug 1700373
Revision history for this message
| Robie Basak (racb) wrote Re: intel-microcode is out of date, version 20170511 fixes errata on 6th and 7th generation platforms | #46 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
@Marat
10:58 <rbasak> xnox: thanks, that's very useful to know. What's the the difference between early initramfs and normal runtime from the kernel/hardware perspective? I didn't think there was any distinction? But there has been talk of Trusty not having early initramfs support. I don't follow why that's a thing.
10:59 <xnox> rbasak, early micocode loading means that microcode is appended to the initramfs as an extra cpio archive. The kernel looks at the initramfs, notices there is microcode appended, and then it loads the microcode before executing init of the initramfs.
10:59 <xnox> rbasak, meaning that microcode is loaded "early", before any userspace process is started.
11:00 <xnox> rbasak, this is relevant in the context of e.g. lock ellision where microcode update _removes CPU instructions_
11:00 <rbasak> Ah. That makes sense - thanks!
11:00 <xnox> and e.g. loaded shared libraries already did the checks if they can use something, continue to try to use them, and segfault.
> Does not sound very convincing.
For an SRU, the burden of "convincing" is reversed. Convince us that this issue *won't* regress users before we recommend an update to them, not the other way round.