From: "Michael S. Tsirkin" <mst@redhat.com>
To: Richard Relph <richard.relph@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>,
qemu-devel@nongnu.org, libvir-list@redhat.com, "Lendacky,
Thomas" <Thomas.Lendacky@amd.com>
Subject: Re: [Qemu-devel] libvirt/QEMU/SEV interaction
Date: Sat, 30 Sep 2017 00:16:55 +0300 [thread overview]
Message-ID: <20170930000900-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <05b3c915-d7c1-2d73-1579-68d5f3bcc3d7@amd.com>
On Fri, Sep 29, 2017 at 02:48:45PM -0500, Richard Relph wrote:
> On 9/29/17 2:34 PM, Michael S. Tsirkin wrote:
> > On Wed, Sep 27, 2017 at 02:06:10PM -0500, Richard Relph wrote:
> > > Whether the "BIOS" is a "static shim" as Michael suggests, or a full BIOS,
> > > or even a BIOS+kernel+initrd is really not too significant. What is
> > > significant is that the GO has a basis for trusting all code that is
> > > imported in to their VM by the CP. And that NONE of the code provided by the
> > > CP is "unknown" and unauditable by the GO. If the CP has a way to inject
> > > code unknown to the GO in to the guest VM, the trust model is broken and
> > > both GO and CP suffer the consequences.
> >
> > Absolutely.
> >
> > > When the CP needs to update the BIOS image, they will have to inform the GO
> > > and allow the GO to establish trust in the CP's new BIOS image somehow.
> >
> > This GO update on every BIOS change is imho is not a workable model. You
> > want something like checking the BIOS signature instead. And since
> > hardware is all hash based, you need the shim to do it in software.
>
> A BIOS "signed" by the CP doesn't meet the security requirement. It is code
> that is "unknown" to the GO.
There is a misunderstanding here.
BIOS would not be signed by a CP. It would be signed by a trusted
software vendor e.g. by Red Hat.
> The (legitimate) CP does NOT want to be in that position of trust. If they
> are, then some government somewhere is going to insist that they sign a BIOS
> that allows the government to spy on the GO's VMs, and steal secrets from
> it. Or some hacker admin will do it "for fun".
>
> How often do large public CPs really change their BIOSes? My sense is that
> large public CPs prefer stability over "latest and greatest".
CPs just do dnf update. Software vendors change BIOSes.
And we do change them. Look at number of revisions for seabios in e.g.
Fedora. More importantly we might need to change them quickly e.g.
because of a security issue. Adding the need to coordinate with all GOs
is not going to work. Neither can QEMU support booting old BIOS
versions on new machine types indefinitely.
> And, perhaps more importantly, if a CP are able to sell a "more secure" VM,
> one that justifies a higher price per vCPU hour, wouldn't that warrant some
> changes in the "insecure" model being used today?
>
> Richard
Absolutely. CPs have no business signing images. But it is just not
really feasible for software vendors to distribute hashes.
--
MST
next prev parent reply other threads:[~2017-09-29 21:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 11:57 [Qemu-devel] libvirt/QEMU/SEV interaction Brijesh Singh
2017-09-08 13:15 ` Daniel P. Berrange
2017-09-08 13:45 ` Relph, Richard
2017-09-08 14:52 ` Daniel P. Berrange
2017-09-08 15:48 ` Brijesh Singh
2017-09-08 15:51 ` Daniel P. Berrange
2017-09-08 16:10 ` Brijesh Singh
2017-09-08 16:11 ` Laszlo Ersek
2017-10-18 4:21 ` Michael S. Tsirkin
2017-10-18 19:18 ` Dr. David Alan Gilbert
2017-10-19 1:35 ` Michael S. Tsirkin
2017-10-20 14:26 ` Richard Relph
2017-09-18 9:43 ` [Qemu-devel] [libvirt] " Erik Skultety
2017-09-18 9:47 ` Daniel P. Berrange
2017-09-18 12:41 ` Richard Relph
2017-09-18 13:51 ` Erik Skultety
2017-09-26 14:36 ` [Qemu-devel] " Michael S. Tsirkin
2017-09-27 11:06 ` Dr. David Alan Gilbert
2017-09-27 13:39 ` Brijesh Singh
2017-09-27 16:12 ` Michael S. Tsirkin
2017-09-27 19:06 ` Richard Relph
2017-09-29 19:34 ` Michael S. Tsirkin
2017-09-29 19:48 ` Richard Relph
2017-09-29 20:07 ` Richard Relph
2017-09-29 21:35 ` Michael S. Tsirkin
2017-10-01 2:54 ` Michael S. Tsirkin
2017-10-01 2:59 ` Michael S. Tsirkin
2017-09-29 21:16 ` Michael S. Tsirkin [this message]
2017-09-29 22:15 ` Laszlo Ersek
2017-10-02 9:15 ` Daniel P. Berrange
2017-10-02 9:11 ` Daniel P. Berrange
2017-09-29 21:58 ` Laszlo Ersek
2017-10-01 0:09 ` Brijesh Singh
2017-10-01 9:17 ` Laszlo Ersek
2017-10-01 9:56 ` Laszlo Ersek
2017-10-03 16:03 ` Brijesh Singh
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=20170930000900-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=Thomas.Lendacky@amd.com \
--cc=brijesh.singh@amd.com \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.relph@amd.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).