All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
	Laszlo Ersek <lersek@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode
Date: Thu, 9 Apr 2015 23:58:28 +1000	[thread overview]
Message-ID: <20150409135828.GO30629@toto> (raw)
In-Reply-To: <5526795F.1020802@redhat.com>

On Thu, Apr 09, 2015 at 03:06:39PM +0200, Paolo Bonzini wrote:
> 
> 
> On 09/04/2015 14:47, Peter Maydell wrote:
> > On 9 April 2015 at 13:20, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >> This is an example of usage of attributes in a device model.  It lets
> >> you block flash writes unless the CPU is in secure mode.  Enabling it
> >> currently requires a -readconfig file:
> >>
> >>         [global]
> >>         driver = "cfi.pflash01"
> >>         property = "secure"
> >>         value = "on"
> >>
> >> because the driver includes a "."; however, I plan to enable this through
> >> the command line for the final version of the patches.
> > 
> > Are real flash devices ever wired up like this?
> 
> On x86 machines it is almost exactly like this.  I'm implementing x86
> system management mode, and I'm reusing MEMTXATTRS_SECURE for it.
> 
> Recent x86 chipsets make this a run-time setting, rather than a static
> setting, but the idea is the same.  It is a run-time setting (chipset
> register) so that the firmware can do some initial detection of the
> flash outside system management mode.  Then it writes a 1 to the
> register, and finally it writes a 1 to a "lock" register so that the
> first register becomes read-only.
> 
> The above scheme was actually more complicated, and allowed a race that
> let you bypass the protection.  So, even more recent machines have some
> additional complication, whereby flash accesses are only allowed if
> _all_ processors are in system management mode.  Again, it is a run-time
> setting.
> 
> QEMU emulates a slightly older chipset, which is why I'm making it a
> static property.  The static property is also much harder to get wrong
> and insecure by mistake.

Hi Paulo,

How would this work with XIP off the romd region?
Without s/ns address spaces,  CPUs in NS state will be able to execute
and access data while in ROMD state won't they?

I may be missing something...

Cheers,
Edgar

  parent reply	other threads:[~2015-04-09 13:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-09 12:20 [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode Paolo Bonzini
2015-04-09 12:20 ` [Qemu-devel] [PATCH 1/3] pflash_cfi01: change big-endian property to BIT type Paolo Bonzini
2015-04-09 12:20 ` [Qemu-devel] [PATCH 2/3] pflash_cfi01: change to new-style MMIO accessors Paolo Bonzini
2015-04-09 12:20 ` [Qemu-devel] [PATCH 3/3] pflash_cfi01: add secure property Paolo Bonzini
2015-04-09 12:47 ` [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode Peter Maydell
2015-04-09 13:06   ` Paolo Bonzini
2015-04-09 13:12     ` Peter Maydell
2015-04-09 13:58     ` Edgar E. Iglesias [this message]
2015-04-09 14:43       ` Paolo Bonzini
2015-04-09 16:10         ` Laszlo Ersek
2015-04-09 16:27           ` Paolo Bonzini
2015-04-09 23:30             ` Edgar E. Iglesias
2015-04-10  9:54             ` 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=20150409135828.GO30629@toto \
    --to=edgar.iglesias@gmail.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=peter.maydell@linaro.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 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.