On Tue, Jun 14, 2022 at 03:12:29PM +0200, Gerd Hoffmann wrote: > > I think we need an ARM expert to explain the rules about SecureBoot > > on aarch64. Given SMM doesn't exist outside x86, it may be fine to > > just enable secureboot unconditionally on aarch64 and have it be > > genuinely secure. I simply don't know enough in this respect. > > Unlikely. The firmware needs some way to store state (i.e. uefi > variables) somewhere where the guest OS can't tamper with it. > > On x86 SMM mode provides that. Flash can be configured to be writable > in SMM mode only, so the guest OS can't change things directly but has > to route all update requests through the firmware. > > The arm architecture has a concept called TrustZone which can as far I > know can provide simliar guarantees. Checking upstream edk2 git log > finds me this... > > commit 6b46d77243e02d23ce922803998e01277fe9f399 > Author: Supreeth Venkatesh <supreeth.venkatesh@xxxxxxx> > Date: Fri Jul 13 23:05:27 2018 +0800 > > StandaloneMmPkg/Core: Implementation of Standalone MM Core Module. > > Management Mode (MM) is a generic term used to describe a secure > execution environment provided by the CPU and related silicon that is > entered when the CPU detects a MMI. For x86 systems, this can be > implemented with System Management Mode (SMM). For ARM systems, this can > be implemented with TrustZone (TZ). > [ ... snip ... ] > > ... but not much beyond that. So I don't think edk2 has support > implemented, and I'm also not sure where we stand with qemu. > > I suspect it'll be quite a bit of work to get everything going. Thanks for the additional information, Gerd! It looks like the only sensible course of action is to keep the current checks in place, effectively preventing the use of secure boot on aarch64, until Someone™ implements TZ support across the stack. -- Andrea Bolognani / Red Hat / Virtualization
