From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
qemu-arm <qemu-arm@nongnu.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash
Date: Tue, 8 Mar 2016 13:02:50 +0100 [thread overview]
Message-ID: <56DEBF6A.6070809@redhat.com> (raw)
In-Reply-To: <CAFEAcA8C2VzkD=87W5Jn7X523cFZLZL6onxjKDoOcZsCPMQxZw@mail.gmail.com>
On 08/03/2016 00:34, Peter Maydell wrote:
>> > I think that, if UEFI secure boot is in use, the UEFI environment
>> > variables should also be only accessible from TrustZone, because they
>> > store the key database. At least that's how it works on x86, where both
>> > pflash devices have the secure=on flag.
> If I understand the setup that is being used correctly, UEFI runs
> in Non-secure, so making the second flash device secure would mean
> it could not access it.
>
> Ard, do I have that right?
The part of UEFI that accesses variables can (optionally) be moved in
secure mode. If you don't do that, secure boot is not secure at all.
Accesses from non-secure mode do the appropriate marshaling/unmarshaling
to call into the secure driver.
Again---that's what it does on x86, but restricting variable access to
the trusted base is an important part of UEFI secure boot.
Paolo
next prev parent reply other threads:[~2016-03-08 12:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-12 14:45 [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash Peter Maydell
2016-02-12 14:45 ` [Qemu-devel] [PATCH 1/4] hw/arm/virt: Provide a secure-only RAM if booting in Secure mode Peter Maydell
2016-02-12 14:45 ` [Qemu-devel] [PATCH 2/4] loader: Add load_image_mr() to load ROM image to a MemoryRegion Peter Maydell
2016-03-03 16:46 ` Paolo Bonzini
2016-03-04 7:42 ` Michael S. Tsirkin
2016-02-12 14:46 ` [Qemu-devel] [PATCH 3/4] hw/arm/virt: Load bios image to MemoryRegion, not physaddr Peter Maydell
2016-02-12 14:46 ` [Qemu-devel] [PATCH 4/4] hw/arm/virt: Make first flash device Secure-only if booting secure Peter Maydell
2016-02-12 22:54 ` [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash Mark Cave-Ayland
2016-02-25 16:47 ` Peter Maydell
2016-03-07 15:20 ` Paolo Bonzini
2016-03-07 23:34 ` Peter Maydell
2016-03-08 12:02 ` Paolo Bonzini [this message]
2016-03-08 12:10 ` Ard Biesheuvel
2016-03-08 12:13 ` Ard Biesheuvel
2016-03-08 12:14 ` Paolo Bonzini
2016-03-08 12:16 ` Ard Biesheuvel
2016-03-08 12:41 ` Paolo Bonzini
2016-03-08 12:50 ` Ard Biesheuvel
2016-03-08 13:06 ` Paolo Bonzini
2016-03-08 13:46 ` Peter Maydell
2016-03-09 14:06 ` Laszlo Ersek
2016-03-09 14:07 ` Paolo Bonzini
2016-03-09 14:21 ` Laszlo Ersek
2016-03-08 13:49 ` Peter Maydell
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=56DEBF6A.6070809@redhat.com \
--to=pbonzini@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=armbru@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.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 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).