On 09/04/2015 14:47, Peter Maydell wrote: > On 9 April 2015 at 13:20, Paolo Bonzini <pbonz...@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 >
