From: Peter Maydell <peter.maydell@linaro.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
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 20:49:55 +0700 [thread overview]
Message-ID: <CAFEAcA8Pk_fBR_v8gg0-oX7nvJ88WRnr-d-uEMTdLfsWMNeESQ@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu-joM8MqtM=G_F7NLZEwpxLBMPeqimDwZv7yivTjYBFVQ@mail.gmail.com>
On 8 March 2016 at 19:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> The UEFI code is loaded into DRAM by the secure firmware, and
> relocated and executed from there.
Incidentally, since we're using the semihosting API to do this at
the moment, this makes the whole thing completely dependent on the
nonsecure guest not being badly behaved, because NS EL1 can happily
make its own semihosting calls which do interesting things like
read and write arbitrary host files.
Presumably one could in theory configure ATF to use something
more sensible (like having the various blobs it loads be
stuffed into the flash with it, or loaded off an emulated disk
or something). But the current use case is as a development
tool for the firmware and secure apps and so on, not something
intended to contain malicious code. Making the flash, ram, etc
secure-only is worthwhile because it exposes plausible bugs
in the guest code being developed.
thanks
-- PMM
prev parent reply other threads:[~2016-03-08 13:50 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
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 [this message]
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=CAFEAcA8Pk_fBR_v8gg0-oX7nvJ88WRnr-d-uEMTdLfsWMNeESQ@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=armbru@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--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).