qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it


From: Edgar E. Iglesias
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
User-agent: Mutt/1.5.21 (2010-09-15)

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 <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]