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

[Paolo Bonzini <pbonzini@redhat.com>]

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.

Paolo

> I would expect boards which want to provide secure-mode
> only flash to do so by not giving any access at all to
> the device from the non-secure address space.
> 
> (Supporting multiple AddressSpaces for ARM CPUs is the
> next thing on my todo list; as well as partitioning the
> flash this would allow secure-mode-only RAM and UARTs,
> for instance.)
> 
> -- PMM
>