Re: [PATCH] misc/xenmicrocode: Upload /lib/firmware/<some blob> to the hypervisor

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Jan 30, 2015 at 12:29:15AM +0000, Andrew Cooper wrote:
> On 29/01/2015 20:12, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 29, 2015 at 06:34:23PM +0000, Andrew Cooper wrote:
> >> <snip>
> >> Getting this conversation back on topic.
> >>
> >> The current state of play in Xen is this:
> >>
> >> * Boot time microcode loading exists (by scanning uncompressed cpio
> >> multiboot modules) and should be safe to use.
> > Please note that it does require passing in 'ucode=scan' on the Xen
> > command line and does not do it automatically. It would be nice
> > if that was automatic..
> 
> If there is an efficent way for Xen to identify compressed or non-cpio
> boot modules and skip them (I have not inspected the code sufficiently
> to know), it is perhaps the kind of option we should consider enabling
> by default.

It scans only for cpio archive and then searches for a specific string
- and if it finds that then it will slurp the binary up and use that
as an candidate for microcode patching.

In that sense anything that is not not-cpio is skipped (compressed, binary,
non-cpio, etc).
> 
> >> * The facility for runtime microcode loading exists (via privileged
> >> hypercall), but is unsafe to use at present, especially if virtual
> >> machines are running.  There are several steps which can be taken to
> >> make it safer to use.
> >>
> >>
> >> There is a plausible usecase for runtime microcode loading for people
> >> who wish to take that risk, and as such, xenmicrocode is useful utility
> >> to have, but it should probably not be available by default until we
> >> believe the hypervisor side of the interface avoids the known potholes.
> > Aren't these issues the same if we had an runtime microcode
> > implementation (I am referring to the xen-microcode driver that
> > Jeremy wrote once and some distros have in their kernel). The loading
> > of microcode is done the same was as baremetal via 'rescan' interface.
> 
> Correct.  Any use of the hypercall mechanism is currently susceptible to
> the potholes identified previously in this thread, and therefore unsafe
> for use in practice.  This includes the classic-xen kernel driver, and
> this new userspace utility.  Having the dom0 kernel issue the hypercall
> as a result of its own boot time microcode patching has fewer potholes
> to trip over, than later when domUs have been booted.

I am surprised you haven't volunteered to put it on your 'free-time' todo
list to fix this :-) <chuckles>
> 
> ~Andrew