From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web10.43935.1674650310256398163 for ; Wed, 25 Jan 2023 04:38:30 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=p7ktUG0o; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4925FB818C6 for ; Wed, 25 Jan 2023 12:38:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6211C433EF for ; Wed, 25 Jan 2023 12:38:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674650306; bh=Wo7jkz95jlskxfODNUPLxyJiVqqmG8Fj0DZZ8vsO7IY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=p7ktUG0oklrqRJJWn71Awxxw6gh6qzh1ZG3nUsLJ82kG7C2hscZIgXcBOkDVAutl0 TJRXXWesu9o9t0LyMPW5dU3BBa2hc4mhhVDL1EDrGA40P5WzRL0iq/x9xiwDalQFt9 ngjd9TOmcuiQ3L+m7l65ytBjIc80L+P7Sv22dv5fcFHq6d2LtL4d46j6LW4MhaiCxI fpwMtIEQ3kaEKACMJN74OwNnjTlC5BpCXbcjhGTm6JGuzTHxOPtuPuHc4lNCRPafEX 4X4Sjb4Xq3KaqYW3YaBNfZ7Dz/YqR6yAj5B19txZmd3nQxSdWQsiz6vwFxZZtZEhm4 CllfEJpvBciyQ== Received: by mail-lf1-f46.google.com with SMTP id d30so28679335lfv.8 for ; Wed, 25 Jan 2023 04:38:26 -0800 (PST) X-Gm-Message-State: AFqh2kqIGTpWQDq32IgBSNs+TCJlhtD8cYfYLK2pkLW0HkWvWsbVwXYh vuY22CPqq6ihPL4bUyS3F//XP0CW3HSMh0UjtbY= X-Google-Smtp-Source: AMrXdXt58RyrUEn58gsVOLNAqkdtVKcLSEYRj+lgvOSVcr24LAi5pA+c43EgLG8MClmK3NOKJJC+D9WLg+aweNzgF3c= X-Received: by 2002:ac2:4bd5:0:b0:4d5:76af:f890 with SMTP id o21-20020ac24bd5000000b004d576aff890mr1735130lfq.228.1674650304959; Wed, 25 Jan 2023 04:38:24 -0800 (PST) MIME-Version: 1.0 References: <20230124163417.584727-1-ardb@kernel.org> <20230125094112.3eatf2sbdjngwn7e@sirius.home.kraxel.org> In-Reply-To: <20230125094112.3eatf2sbdjngwn7e@sirius.home.kraxel.org> From: "Ard Biesheuvel" Date: Wed, 25 Jan 2023 13:38:13 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v2 0/6] ArmVirtPkg: Increase PlatformCI coverage To: devel@edk2.groups.io, kraxel@redhat.com Cc: Michael Kubacki , Jiewen Yao , Oliver Steffen Content-Type: text/plain; charset="UTF-8" On Wed, 25 Jan 2023 at 10:42, Gerd Hoffmann wrote: > > On Tue, Jan 24, 2023 at 05:34:11PM +0100, Ard Biesheuvel wrote: > > We recently experienced some build breakage in one of the ArmVirtPkg > > platforms that is not covered by PlatformCI, in the PrePi component > > which replaces the entire PEI stage. This component is now also being > > used in TDVF, and so any modifications to it may regress the existing > > users. > > > > So add build and boot tests of ArmVirtQemuKernel (which is a version of > > ArmVirtQemu which can be loaded as a loadable image instead of executing > > from [emulated] NOR flash), and a build test of ArmVirtKvmTool, which is > > also based on PrePi and runs under the kvmtool VMM. To further increase > > coverage, enable secure boot, TPM support and HTTP(s) boot support when > > building ArmVirtQemu for AARCH64. > > Acked-by: Gerd Hoffmann > Thanks. > As you mention secure boot: As far I know current state of affairs is > that nothing protects efi variable flash on ArmVirt, so secure boot > isn't actually secure because the OS can easily manipulate 'db' etc. > True. There is a way around this, though: we could emulate secure EL0 using KVM and a separate EL1 context that implements the Secure Partition interface that standalone MM supports. That way, we would be able to run the entire MM based variable runtime stack, similar to how SMM emulation is implemented (or so I am told) None of this has been implemented or prototyped, though, and nobody seems to want it badly enough to bother. > State of affairs on physical hardware (at least on Qualcomm SoCs) seems > to be that there is some service running in the Trusted Zone secure > world which manages (and controls access to) EFI variables. See > https://lore.kernel.org/lkml/eaa455ed-2dd2-a33f-6420-a75484eccc35@gmail.com/t/ > Yes. There are other efforts underway that are OP-TEE based, i.e., RPMB partition owned by the secure firmware, and a supplicant in Linux user space that marshalls requests between the Linux kernel and the secure firmware. And yes, this is a terrible design, and the qcom approach seems slightly better. On bare metal hardware, you can generally just use the standalone MM based driver stack. I implemented this for SynQuacer/Developerbox, when building its firmware with SECURE_BOOT_ENABLE from edk2-platforms. However, this approach only works if the secure world can have complete ownership of the storage. On QCOM devices or other eMMC/UFS based devices, there is only a single controller which must be owned by the Linux kernel, and so any access by the firmware needs to be routed via some component that performs the arbitration. In the OP-TEE case, this is the supplicant in user space. in the QCOM case, I imagine there may be some code in the magic hypervisor that takes care of this. > Do you happen to know whenever any of this is available as open source, > be it the secure world code or the EFI drivers talking to it? Is there > some kind of standard for this or does every vendor brew its own? > There is no standard for this, as far as I know, even though the problem was well understood 8+ years ago. As far as I know, the QCOM approach is specific to snapdragon EFI platforms, and similar hacks are needed in Windows for the EFI runtime stack to be swapped out and the special driver swapped into the consumers of the EFI variables. The secure world calling convention is standardized, though, and IIRC, there were some suggestions regarding reuse of the EFI variable emulation function IDs. But in general, it is very hard to get QCOM engineers to care about any of this - even if Lenovo are now invested in running Linux on the ARM ThinkPads, they still have to work around the buggy firmware that they get from QCOM and AMI, and getting it fixed appears to be very hard.