From: Laszlo Ersek <lersek@redhat.com>
To: Richard Relph <richard.relph@amd.com>,
Brijesh Singh <brijesh.singh@amd.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
libvir-list@redhat.com, "Lendacky,
Thomas" <Thomas.Lendacky@amd.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] libvirt/QEMU/SEV interaction
Date: Fri, 29 Sep 2017 23:58:23 +0200 [thread overview]
Message-ID: <11d514ce-5752-d1a9-852c-9f091d2791e2@redhat.com> (raw)
In-Reply-To: <927fedc3-a2c8-d37c-930e-11cecb7b0149@amd.com>
Side topic; sorry if it has been mentioned elsewhere:
On 09/27/17 21:06, 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.
The expansion ROMs (containing UEFI drivers) of emulated PCI devices,
and the same of assigned physical PCI devices, constitute another
channel through which code enters the guest from the outside (i.e., from
the Cloud Provider). The ROM BARs from which the guest firmware reads
the UEFI binaries are not guest RAM, they are MMIO. (For execution, the
drivers are copied into encrypted guest RAM.)
If the guest has Secure Boot enabled, then the oproms are verified[*]
(and not launched if verification fails), but this is slightly different
from what I understand under audit-by-GO. It means the GO wouldn't get a
measurement of the oproms for one-by-one clearing, when about to
green-light a guest startup. Instead the GO would ensure that Secure
Boot be enabled with the right certificates (and/or executable hashes)
enrolled off the bat, and then implicitly trust all oprom drivers
accepted by those certs / hashes. It's another layer of indirection.
This is likely nothing new qualitatively, but "the devil is in the
details", so I thought it was worth raising.
[*] For edk2 / OvmfPkg specifics, I'll mention
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
The SecurityPkg default is 0x04 ("Deny execution when there is security
violation"). However, OVMF sets it to 0x00 ("Always trust the image").
Please see the following commit for the reasons:
https://github.com/tianocore/edk2/commit/1fea9ddb4e3fd
Brijesh, for SEV guests, we likely want to flip this PCD to 0x04, in the
AmdSevInitialize() function, in "OvmfPkg/PlatformPei/AmdSev.c". For that
we'll also have to change the PCD from fixed-at-build to dynamic, but
that in turn will require a change to "SecurityPkg.dec" itself
(currently it only allows fixed-at-build or patchable, not dynamic). Do
you want me to file a BZ in the TianoCore tracker for this, and assign
it to you? If you don't have time for writing the patch, I'm glad to do
it too, but then the review could be slower; both other OvmfPkg
co-maintainers are busy with other things.)
Thanks!
Laszlo
next prev parent reply other threads:[~2017-09-29 21:58 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
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 [this message]
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=11d514ce-5752-d1a9-852c-9f091d2791e2@redhat.com \
--to=lersek@redhat.com \
--cc=Thomas.Lendacky@amd.com \
--cc=brijesh.singh@amd.com \
--cc=libvir-list@redhat.com \
--cc=mst@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).