All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Juergen Gross <jgross@suse.com>, Michal Marek <mmarek@suse.cz>,
	Jason Douglas <jdouglas@suse.com>,
	stefano.stabellini@eu.citrix.com, Takashi Iwai <tiwai@suse.de>,
	mcgrof@suse.com, "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Henrique de Moraes Holschuh <hmh@debian.org>,
	david.vrabel@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>
Subject: Re: [PATCH] misc/xenmicrocode: Upload /lib/firmware/<some blob> to the hypervisor
Date: Fri, 30 Jan 2015 00:29:15 +0000	[thread overview]
Message-ID: <54CAD05B.8040105@citrix.com> (raw)
In-Reply-To: <20150129201245.GD22967@konrad-lan.dumpdata.com>

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.

>> * 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.

~Andrew

  reply	other threads:[~2015-01-30  0:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-27 20:11 [PATCH] misc/xenmicrocode: Upload /lib/firmware/<some blob> to the hypervisor Luis R. Rodriguez
2015-01-27 21:25 ` Boris Ostrovsky
2015-01-27 21:54   ` Luis R. Rodriguez
2015-01-27 22:26 ` Andrew Cooper
2015-01-27 23:17   ` Borislav Petkov
2015-01-28  0:10     ` Andrew Cooper
2015-01-28  8:39       ` Borislav Petkov
2015-01-29  3:21         ` Luis R. Rodriguez
2015-01-29 19:15           ` Borislav Petkov
2015-01-30  1:13             ` Luis R. Rodriguez
2015-01-29 11:36         ` Henrique de Moraes Holschuh
2015-01-29 12:17           ` Borislav Petkov
2015-01-29 17:01             ` Henrique de Moraes Holschuh
2015-01-29 17:30               ` Borislav Petkov
2015-01-29 18:34                 ` Andrew Cooper
2015-01-29 20:12                   ` Konrad Rzeszutek Wilk
2015-01-30  0:29                     ` Andrew Cooper [this message]
2015-01-30 14:11                       ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54CAD05B.8040105@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@suse.de \
    --cc=david.vrabel@citrix.com \
    --cc=hmh@debian.org \
    --cc=jdouglas@suse.com \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=mcgrof@do-not-panic.com \
    --cc=mcgrof@suse.com \
    --cc=mmarek@suse.cz \
    --cc=ohering@suse.de \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tiwai@suse.de \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.