On 01/30/19 15:33, Paolo Bonzini wrote:
> On 30/01/19 15:13, Markus Armbruster wrote:
>> -global driver=cfi.pflash01,property=secure,value=on
>>
>> Affects *all* such devices, but fortunately we have at most two, and
>> the one we don't want to affect happens to ignore the property value.
>
> Is this true? I think both need secure=on, at least on x86.
commit f71e42a5c98722d6faa5be84a34fbad90d27dc04
Author: Paolo Bonzini <pbonzini@xxxxxxxxxx>
Date: Wed Apr 8 14:09:43 2015 +0200
pflash_cfi01: add secure property
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@xxxxxxxxxx>
If you don't add "secure=on" to unit#0, then MMIO accesses will be
possible outside of SMM. From those, I'd hazard "MMIO reads" are
generally irrelevant. "MMIO writes" could succeed to the RAM image, but:
- they are never written back to the disk (due to readonly=on),
- the actual contents of unit#0 stops mattering as soon as the SEC phase
decompresses the PEIFV and DXEFV firmware volumes from it, to DRAM.
The SMM infrastructure is then constructed in SMRAM from DRAM. By the
time a 3rd party UEFI application or driver, or an OS, is reached, the
sensitive bits are all locked in SMRAM.
... But, I wonder if S3 resume would be under threat in this case. In
that case, SEC runs again (from pflash), and it re-decompresses
PEIFV/DXEFV from pflash to DRAM. If the in-memory image of pflash
doesn't revert to the (pristine, due to readonly=on) disk image at
platform reset, then I reckon there could be a problem; the SEC code and
the compressed FVs could have been tampered with in memory.
I guess it's best to apply secure=on to unit#0 as well, after all :)
Thanks!
Laszlo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
