[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: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode |
Date: |
Thu, 09 Apr 2015 15:06:39 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
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.
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
>
- [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode, Paolo Bonzini, 2015/04/09
- [Qemu-devel] [PATCH 1/3] pflash_cfi01: change big-endian property to BIT type, Paolo Bonzini, 2015/04/09
- [Qemu-devel] [PATCH 3/3] pflash_cfi01: add secure property, Paolo Bonzini, 2015/04/09
- [Qemu-devel] [PATCH 2/3] pflash_cfi01: change to new-style MMIO accessors, Paolo Bonzini, 2015/04/09
- Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode, Peter Maydell, 2015/04/09
- Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode,
Paolo Bonzini <=
- Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode, Peter Maydell, 2015/04/09
- Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode, Edgar E. Iglesias, 2015/04/09
- Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode, Paolo Bonzini, 2015/04/09
- Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode, Laszlo Ersek, 2015/04/09
- Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode, Paolo Bonzini, 2015/04/09
- Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode, Edgar E. Iglesias, 2015/04/09
- Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode, Peter Maydell, 2015/04/10