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

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

[Paolo Bonzini]

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.

In the meanwhile, a review of the approach and of the actual memattrs bit
would be great.

Paolo

Paolo Bonzini (3):
  pflash_cfi01: change big-endian property to BIT type
  pflash_cfi01: change to new-style MMIO accessors
  pflash_cfi01: add secure property

 hw/block/pflash_cfi01.c | 115 ++++++++++++------------------------------------
 1 file changed, 28 insertions(+), 87 deletions(-)

-- 
2.3.5

[Qemu-devel] [PATCH 1/3] pflash_cfi01: change big-endian property to BIT type

[Paolo Bonzini]

Make this consistent with the secure property, added in the next patches.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 hw/block/pflash_cfi01.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index d282695..7507a15 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -64,6 +64,8 @@ do {                                                        \
 #define TYPE_CFI_PFLASH01 "cfi.pflash01"
 #define CFI_PFLASH01(obj) OBJECT_CHECK(pflash_t, (obj), TYPE_CFI_PFLASH01)
 
+#define PFLASH_BE		0
+
 struct pflash_t {
     /*< private >*/
     SysBusDevice parent_obj;
@@ -75,7 +77,7 @@ struct pflash_t {
     uint8_t bank_width;
     uint8_t device_width; /* If 0, device width not specified. */
     uint8_t max_device_width;  /* max device width in bytes */
-    uint8_t be;
+    uint32_t features;
     uint8_t wcycle; /* if 0, the flash is read normally */
     int ro;
     uint8_t cmd;
@@ -773,7 +775,8 @@ static void pflash_cfi01_realize(DeviceState *dev, Error **errp)
 
     memory_region_init_rom_device(
         &pfl->mem, OBJECT(dev),
-        pfl->be ? &pflash_cfi01_ops_be : &pflash_cfi01_ops_le, pfl,
+        pfl->features & (1 << PFLASH_BE) ? &pflash_cfi01_ops_be : &pflash_cfi01_ops_le,
+        pfl,
         pfl->name, total_len, &local_err);
     if (local_err) {
         error_propagate(errp, local_err);
@@ -925,7 +928,7 @@ static Property pflash_cfi01_properties[] = {
     DEFINE_PROP_UINT8("width", struct pflash_t, bank_width, 0),
     DEFINE_PROP_UINT8("device-width", struct pflash_t, device_width, 0),
     DEFINE_PROP_UINT8("max-device-width", struct pflash_t, max_device_width, 0),
-    DEFINE_PROP_UINT8("big-endian", struct pflash_t, be, 0),
+    DEFINE_PROP_BIT("big-endian", struct pflash_t, features, PFLASH_BE, 0),
     DEFINE_PROP_UINT16("id0", struct pflash_t, ident0, 0),
     DEFINE_PROP_UINT16("id1", struct pflash_t, ident1, 0),
     DEFINE_PROP_UINT16("id2", struct pflash_t, ident2, 0),
@@ -975,7 +978,7 @@ pflash_t *pflash_cfi01_register(hwaddr base,
     qdev_prop_set_uint32(dev, "num-blocks", nb_blocs);
     qdev_prop_set_uint64(dev, "sector-length", sector_len);
     qdev_prop_set_uint8(dev, "width", bank_width);
-    qdev_prop_set_uint8(dev, "big-endian", !!be);
+    qdev_prop_set_bit(dev, "big-endian", !!be);
     qdev_prop_set_uint16(dev, "id0", id0);
     qdev_prop_set_uint16(dev, "id1", id1);
     qdev_prop_set_uint16(dev, "id2", id2);
-- 
2.3.5

[Qemu-devel] [PATCH 2/3] pflash_cfi01: change to new-style MMIO accessors

[Paolo Bonzini]

This is a required step to implement read_with_attrs and write_with_attrs.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 hw/block/pflash_cfi01.c | 96 ++++++-------------------------------------------
 1 file changed, 10 insertions(+), 86 deletions(-)

diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index 7507a15..0b3667a 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -650,101 +650,25 @@ static void pflash_write(pflash_t *pfl, hwaddr offset,
 }
 
 
-static uint32_t pflash_readb_be(void *opaque, hwaddr addr)
-{
-    return pflash_read(opaque, addr, 1, 1);
-}
-
-static uint32_t pflash_readb_le(void *opaque, hwaddr addr)
-{
-    return pflash_read(opaque, addr, 1, 0);
-}
-
-static uint32_t pflash_readw_be(void *opaque, hwaddr addr)
+static uint64_t pflash_mem_read(void *opaque, hwaddr addr, unsigned len)
 {
     pflash_t *pfl = opaque;
+    bool be = !!(pfl->features & (1 << PFLASH_BE));
 
-    return pflash_read(pfl, addr, 2, 1);
+    return pflash_read(pfl, addr, len, be);
 }
 
-static uint32_t pflash_readw_le(void *opaque, hwaddr addr)
+static void pflash_mem_write(void *opaque, hwaddr addr, uint64_t value, unsigned len)
 {
     pflash_t *pfl = opaque;
+    bool be = !!(pfl->features & (1 << PFLASH_BE));
 
-    return pflash_read(pfl, addr, 2, 0);
+    pflash_write(pfl, addr, value, len, be);
 }
 
-static uint32_t pflash_readl_be(void *opaque, hwaddr addr)
-{
-    pflash_t *pfl = opaque;
-
-    return pflash_read(pfl, addr, 4, 1);
-}
-
-static uint32_t pflash_readl_le(void *opaque, hwaddr addr)
-{
-    pflash_t *pfl = opaque;
-
-    return pflash_read(pfl, addr, 4, 0);
-}
-
-static void pflash_writeb_be(void *opaque, hwaddr addr,
-                             uint32_t value)
-{
-    pflash_write(opaque, addr, value, 1, 1);
-}
-
-static void pflash_writeb_le(void *opaque, hwaddr addr,
-                             uint32_t value)
-{
-    pflash_write(opaque, addr, value, 1, 0);
-}
-
-static void pflash_writew_be(void *opaque, hwaddr addr,
-                             uint32_t value)
-{
-    pflash_t *pfl = opaque;
-
-    pflash_write(pfl, addr, value, 2, 1);
-}
-
-static void pflash_writew_le(void *opaque, hwaddr addr,
-                             uint32_t value)
-{
-    pflash_t *pfl = opaque;
-
-    pflash_write(pfl, addr, value, 2, 0);
-}
-
-static void pflash_writel_be(void *opaque, hwaddr addr,
-                             uint32_t value)
-{
-    pflash_t *pfl = opaque;
-
-    pflash_write(pfl, addr, value, 4, 1);
-}
-
-static void pflash_writel_le(void *opaque, hwaddr addr,
-                             uint32_t value)
-{
-    pflash_t *pfl = opaque;
-
-    pflash_write(pfl, addr, value, 4, 0);
-}
-
-static const MemoryRegionOps pflash_cfi01_ops_be = {
-    .old_mmio = {
-        .read = { pflash_readb_be, pflash_readw_be, pflash_readl_be, },
-        .write = { pflash_writeb_be, pflash_writew_be, pflash_writel_be, },
-    },
-    .endianness = DEVICE_NATIVE_ENDIAN,
-};
-
-static const MemoryRegionOps pflash_cfi01_ops_le = {
-    .old_mmio = {
-        .read = { pflash_readb_le, pflash_readw_le, pflash_readl_le, },
-        .write = { pflash_writeb_le, pflash_writew_le, pflash_writel_le, },
-    },
+static const MemoryRegionOps pflash_cfi01_ops = {
+    .read = pflash_mem_read,
+    .write = pflash_mem_write,
     .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
@@ -775,7 +699,7 @@ static void pflash_cfi01_realize(DeviceState *dev, Error **errp)
 
     memory_region_init_rom_device(
         &pfl->mem, OBJECT(dev),
-        pfl->features & (1 << PFLASH_BE) ? &pflash_cfi01_ops_be : &pflash_cfi01_ops_le,
+        &pflash_cfi01_ops,
         pfl,
         pfl->name, total_len, &local_err);
     if (local_err) {
-- 
2.3.5

[Qemu-devel] [PATCH 3/3] pflash_cfi01: add secure property

[Paolo Bonzini]

When this property is set, MMIO accesses are only allowed with the
MEMTXATTRS_SECURE attribute.  This is used for secure access to UEFI
variables stored in flash.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 hw/block/pflash_cfi01.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index 0b3667a..df3b0b0 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -65,6 +65,7 @@ do {                                                        \
 #define CFI_PFLASH01(obj) OBJECT_CHECK(pflash_t, (obj), TYPE_CFI_PFLASH01)
 
 #define PFLASH_BE		0
+#define PFLASH_SECURE		1
 
 struct pflash_t {
     /*< private >*/
@@ -650,25 +651,37 @@ static void pflash_write(pflash_t *pfl, hwaddr offset,
 }
 
 
-static uint64_t pflash_mem_read(void *opaque, hwaddr addr, unsigned len)
+static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr, uint64_t *value,
+                                              unsigned len, MemTxAttrs attrs)
 {
     pflash_t *pfl = opaque;
     bool be = !!(pfl->features & (1 << PFLASH_BE));
 
-    return pflash_read(pfl, addr, len, be);
+    if ((pfl->features & (1 << PFLASH_SECURE)) && !(attrs & MEMTXATTRS_SECURE)) {
+        return MEMTX_ERROR;
+    }
+
+    *value = pflash_read(opaque, addr, len, be);
+    return MEMTX_OK;
 }
 
-static void pflash_mem_write(void *opaque, hwaddr addr, uint64_t value, unsigned len)
+static MemTxResult pflash_mem_write_with_attrs(void *opaque, hwaddr addr, uint64_t value,
+                                               unsigned len, MemTxAttrs attrs)
 {
     pflash_t *pfl = opaque;
     bool be = !!(pfl->features & (1 << PFLASH_BE));
 
-    pflash_write(pfl, addr, value, len, be);
+    if ((pfl->features & (1 << PFLASH_SECURE)) && !(attrs & MEMTXATTRS_SECURE)) {
+        return MEMTX_ERROR;
+    }
+
+    pflash_write(opaque, addr, value, len, be);
+    return MEMTX_OK;
 }
 
 static const MemoryRegionOps pflash_cfi01_ops = {
-    .read = pflash_mem_read,
-    .write = pflash_mem_write,
+    .read_with_attrs = pflash_mem_read_with_attrs,
+    .write_with_attrs = pflash_mem_write_with_attrs,
     .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
@@ -853,6 +866,7 @@ static Property pflash_cfi01_properties[] = {
     DEFINE_PROP_UINT8("device-width", struct pflash_t, device_width, 0),
     DEFINE_PROP_UINT8("max-device-width", struct pflash_t, max_device_width, 0),
     DEFINE_PROP_BIT("big-endian", struct pflash_t, features, PFLASH_BE, 0),
+    DEFINE_PROP_BIT("secure", struct pflash_t, features, PFLASH_SECURE, 0),
     DEFINE_PROP_UINT16("id0", struct pflash_t, ident0, 0),
     DEFINE_PROP_UINT16("id1", struct pflash_t, ident1, 0),
     DEFINE_PROP_UINT16("id2", struct pflash_t, ident2, 0),
-- 
2.3.5

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

[Peter Maydell]

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?
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

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

[Paolo Bonzini]

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
> 

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

[Peter Maydell]

On 9 April 2015 at 14:06, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 09/04/2015 14:47, Peter Maydell wrote:
>> 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.

Cool -- useful to have a non-ARM use of some of this, helps
to keep the design of the common-code parts honest.

-- PMM

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

[Edgar E. Iglesias]

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

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

[Paolo Bonzini]

On 09/04/2015 15:58, Edgar E. Iglesias wrote:
> 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?

Good point!  In fact, even with S/NS address spaces, the ROMD state is
global across all CPUs, so if one CPU does a secure write all other CPUs
would fail to access the ROM in non-secure mode.  Even if I modified
pflash_mem_read to return ROM contents, it would fail to execute.

This works for UEFI because the reset vector is the only executable code
in the flash.  The actual firmware volumes are compressed.

> I may be missing something...

You may also be missing (I didn't say it) that this is for x86 not ARM. :->

Paolo

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

[Laszlo Ersek]

On 04/09/15 16:43, Paolo Bonzini wrote:
> 
> 
> On 09/04/2015 15:58, Edgar E. Iglesias wrote:
>> 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?
> 
> Good point!  In fact, even with S/NS address spaces, the ROMD state is
> global across all CPUs, so if one CPU does a secure write all other CPUs
> would fail to access the ROM in non-secure mode.  Even if I modified
> pflash_mem_read to return ROM contents, it would fail to execute.
> 
> This works for UEFI because the reset vector is the only executable code
> in the flash.  The actual firmware volumes are compressed.

In OVMF, the reset vector and the SEC phase code run from (read-only)
flash. SEC decompresses everything else to RAM. Also, SEC does not
access read-write flash (the varstore) at all.

The above is a specialty of OVMF. In ArmVirtualizationQemu (aka AAVMF),
two further module types run from flash, after SEC: PEI_CORE, and some
PEIMs (ie. the PEI phase comes into the picture). During PEI, read-only
access to the varstore should be supported.

... I'm providing the above as "standalone facts", neither as
confirmation nor as disproof for what you wrote. I don't know enough to
combine these edk2 bits with what you wrote myself, but my hope is that
*you* can maybe combine them, if I point them out. :)

>> I may be missing something...
> 
> You may also be missing (I didn't say it) that this is for x86 not ARM. :->

Right; as long as we're focusing on OVMF "only", then everything after
SEC runs from RAM.

Thanks!
Laszlo

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

[Paolo Bonzini]

On 09/04/2015 18:10, Laszlo Ersek wrote:
> In OVMF, the reset vector and the SEC phase code run from (read-only)
> flash. SEC decompresses everything else to RAM. Also, SEC does not
> access read-write flash (the varstore) at all.
> 
> The above is a specialty of OVMF. In ArmVirtualizationQemu (aka AAVMF),
> two further module types run from flash, after SEC: PEI_CORE, and some
> PEIMs (ie. the PEI phase comes into the picture). During PEI, read-only
> access to the varstore should be supported.

Read-only access should always be fine (though with a tweak to these
patches, and slower---because it exits to QEMU---if another CPU is
looking at the flash in MMIO mode).  The problem is execution.

But on x86 flash should never be accessed by multiple CPUs at the same
time, unless all of them know that the flash is in ROM mode.

As I understand it, on ARM secure (EL3) and non-secure (EL<3) modes have
effectively different address spaces.  Therefore, one EL3 CPU could put
the flash in MMIO mode for programming, while another EL1 CPU could be
reading from the flash in ROM mode.  In QEMU, this could be implemented
with two memory regions and per-CPU address spaces.  These patches
should not get in the way, but they would not be useful.

Thanks,

Paolo

> ... I'm providing the above as "standalone facts", neither as
> confirmation nor as disproof for what you wrote. I don't know enough to
> combine these edk2 bits with what you wrote myself, but my hope is that
> *you* can maybe combine them, if I point them out. :)

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

[Edgar E. Iglesias]

On Thu, Apr 09, 2015 at 06:27:42PM +0200, Paolo Bonzini wrote:
> 
> 
> On 09/04/2015 18:10, Laszlo Ersek wrote:
> > In OVMF, the reset vector and the SEC phase code run from (read-only)
> > flash. SEC decompresses everything else to RAM. Also, SEC does not
> > access read-write flash (the varstore) at all.
> > 
> > The above is a specialty of OVMF. In ArmVirtualizationQemu (aka AAVMF),
> > two further module types run from flash, after SEC: PEI_CORE, and some
> > PEIMs (ie. the PEI phase comes into the picture). During PEI, read-only
> > access to the varstore should be supported.
> 
> Read-only access should always be fine (though with a tweak to these
> patches, and slower---because it exits to QEMU---if another CPU is
> looking at the flash in MMIO mode).  The problem is execution.
> 
> But on x86 flash should never be accessed by multiple CPUs at the same
> time, unless all of them know that the flash is in ROM mode.
> 
> As I understand it, on ARM secure (EL3) and non-secure (EL<3) modes have
> effectively different address spaces.  Therefore, one EL3 CPU could put
> the flash in MMIO mode for programming, while another EL1 CPU could be
> reading from the flash in ROM mode.  In QEMU, this could be implemented
> with two memory regions and per-CPU address spaces.  These patches
> should not get in the way, but they would not be useful.

Right, that matches my understanding.

Thanks,
Edgar

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

[Peter Maydell]

On 9 April 2015 at 17:27, Paolo Bonzini <pbonzini@redhat.com> wrote:
> As I understand it, on ARM secure (EL3) and non-secure (EL<3) modes have
> effectively different address spaces.  Therefore, one EL3 CPU could put
> the flash in MMIO mode for programming, while another EL1 CPU could be
> reading from the flash in ROM mode.

Well, not really -- you'd put the flash into the Secure address
space only. Then the CPU at EL3 could access it, but the CPU
at EL1 can never do so. For reading or writing UEFI variables
(or flashing a new UEFI firmware image) the EL1 OS must make a
monitor call (hypercall) up to EL3 to request that action.

-- PMM