efi: MMC proxy support for the UEFI varstore

================================================================================
NOTE: this is a work in progress, and not fully functional yet. In particular, the actual MMC host protocol methods are stubbed out at the moment, and need to be wired up to the Linux device drivers.
================================================================================

On mobile and embedded systems, there is usually only a single MMC device for non-volatile storage, which sits behind a controller that is owned by the OS at runtime. This makes it difficult to host the UEFI variable store on MMC as well, since the UEFI runtime services routines expect ownership of the underlying device as well.

This series proposes an approach to work around this. It implements the UEFI MMC host protocol in the kernel, in a way that makes it possible to expose it to the firmware. At the same time, the firmware needs be set up for this, i.e., it needs to expose its MMC host protocol pointer via a UEFI configuration table, so that the kernel can override it if it decides to expose this functionality to the firmware.

Note that these patches are based on patches in the EFI tree that are queued for v4.9, which replace the runtime wrappers spinlock with a semaphore. This allows us to sleep in the firmware callbacks.

Prerequisites for using these patches:

* qemu-system-aarch64 built from this branch:
https://git.linaro.org/people/ard.biesheuvel/qemu.git/shortlog/refs/heads/mach-virt-pl181
which adds a PL181 SD/MMC controller to the mach-virt model, and exposes it via the device tree. It also sets the 'linux,uefi-varstore' property on this node.

* UEFI firmware built from this branch:
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/mmc-proxy

Build using the following command
build -a AARCH64 -t GCC5 -p ArmVirtPkg/ArmVirtQemuMmcVars.dsc

  Run using 
  qemu-system-aarch64 \
    -M virt -cpu cortex-a57 -m 2048 \
    -device virtio-blk-device,drive=boot \
    -drive if=none,id=boot,file=fat:<path-of-Image>,format=raw \
    -kernel <edk2-dir>/Build/ArmVirtQemuMmcVars-AARCH64/DEBUG_GCC5/FV/QEMU_EFI.fd \
    -sd <edk2-dir>/build/edk2/Build/ArmVirtQemuMmcVars-AARCH64/DEBUG_GCC5/FV/QEMU_VARS.fd \
    -nographic $@

This will give you an UEFI environment which keeps its UEFI variables in the emulated MMC volume, and exposes its MMC host protocol in a way that allows these patches to hook into it.

Patches #1 and #2 implement the arch specific hooks to preserve/restore the NEON registers that the firmware may expect to be preserved across function calls.

Patch #3 implements the plumbing to call back into the kernel from the firmware.

Please comment on whether this approach seems feasible, and in particular, how on earth I should wire this up to the actual MMC code.

Thanks,
Ard.

Ard Biesheuvel (3):
efi/arm64: add SIMD stash/unstash operations efi/arm: add SIMD stash/unstash operations
efi: implement MMC proxy support for the UEFI variable store

 arch/arm/include/asm/efi.h       |  11 +
 arch/arm64/include/asm/efi.h     |  33 +++
 drivers/firmware/efi/Kconfig     |   9 +
 drivers/firmware/efi/Makefile    |   1 +
 drivers/firmware/efi/arm-init.c  |   2 +
 drivers/firmware/efi/mmc-proxy.c | 222 ++++++++++++++++++++
 include/linux/efi.h              |   1 +
 7 files changed, 279 insertions(+)
 create mode 100644 drivers/firmware/efi/mmc-proxy.c

Signature · 1 line

2.7.4

Hi Ard,

Quoted 12 lines · Ard Biesheuvel

================================================================================
NOTE: this is a work in progress, and not fully functional yet. In particular, the actual MMC host protocol methods are stubbed out at the moment, and need to be wired up to the Linux device drivers.
================================================================================

On mobile and embedded systems, there is usually only a single MMC device for non-volatile storage, which sits behind a controller that is owned by the OS at runtime. This makes it difficult to host the UEFI variable store on MMC as well, since the UEFI runtime services routines expect ownership of the underlying device as well.

Quoted 6 lines

This series proposes an approach to work around this. It implements the UEFI MMC host protocol in the kernel, in a way that makes it possible to expose it to the firmware. At the same time, the firmware needs be set up for this, i.e., it needs to expose its MMC host protocol pointer via a UEFI configuration table, so that the kernel can override it if it decides to expose this functionality to the firmware.

At a high level, and assuming a number of details from previous discussions, I think the general approach of having the kernel mediate access to the MMC makes sense.

However, I don't think that this series has enough detail for critical review, even at the interface level. e.g. there is no mention of how this caters for replay attacks and so on (which the current spec sidesteps). I'm under the impression that there are mechanisms which have been discussed for this, and I hope this is simply an oversight.

I also think that this needs to go via the USWG (and to the UEFI spec), before we can consider using it. I say this because:

* This is critical to correct operation of variable storage as required for the standard boot flow. This is a major change to the way variable storage works today, with a number of (security) implications.

* There are others in this space trying to use the same class of hardware, e.g. FreeBSD. We don't want a Linux-specific interface, nor do we want a proliferation of interfaces for this purpose.

I have a few other general concerns:

* Identification of the relevant MMC device(s).

Patch 3 suggests a devicetree property. I don't think that the 'linux,' prefix makes sense, and it's not clear what we would do with ACPI.

Does the MMC device not have some identifier we can query, so that we can match this up without requiring additional info in ACPI/DT?

* Lifetime guarantees

When is it valid for EFI to call the MMC proxy? Can other services (e.g. ACPI) call this?

How do we handle kexec/kdump? e.g. how do we teardown the interface before branching to a new kernel, how do we safely tear down a crashed kernel's interface, what can we call before doing so?

How do we handle suspend/resume? e.g. is it necessary to re-register upon resume?

Quoted 4 lines · Mark Rutland

On Thu, Sep 22, 2016 at 12:30:03PM +0100, Ard Biesheuvel wrote:

I also think that this needs to go via the USWG (and to the UEFI spec), before we can consider using it.

The primary issue there is that the variable protocols are architectural DXE protocols defined in the PI spec, not the UEFI spec (and the MMC host protocol I am using here is not in any spec afaik), and so implementing this in a UEFI compliant way is not currently possible. Exposing a UEFI protocol like block I/O is not sufficient, since the variable protocols are depended upon earlier in the boot sequence (in UEFI implementations based on PI).

So yes, this needs to be discussed (and it will be, but not out in the open, unfortunately.) However, it is unclear whether it is feasible to address this at the UEFI level, or whether we will need to go beyond and define something based on the PI spec directly. (/me looks at Charles)

Quoted 7 lines

I have a few other general concerns:

* Lifetime guarantees

When is it valid for EFI to call the MMC proxy? Can other services (e.g. ACPI) call this?

Quoted 6 lines

How do we handle kexec/kdump? e.g. how do we teardown the interface before branching to a new kernel, how do we safely tear down a crashed kernel's interface, what can we call before doing so?

How do we handle suspend/resume? e.g. is it necessary to re-register upon resume?

All good questions, and exactly the kind of feedback I am seeking.

Tearing down the interface could be as simple as clearing the pointer, but some synchronization is probably in order to make sure that no calls are in progress.

But to clarify the purpose of this series: are there any concerns regarding exposing callbacks to the firmware in general, and for MMC access in particular, from the Linux side?

Quoted 6 lines · Ard Biesheuvel

This series proposes an approach to work around this. It implements the UEFI MMC host protocol in the kernel, in a way that makes it possible to expose it to the firmware. At the same time, the firmware needs be set up for this, i.e., it needs to expose its MMC host protocol pointer via a UEFI configuration table, so that the kernel can override it if it decides to expose this functionality to the firmware.

At a high level, and assuming a number of details from previous discussions, I think the general approach of having the kernel mediate access to the MMC makes sense.

I have a few other general concerns:

================================================================================
NOTE: this is a work in progress, and not fully functional yet. In particular, the actual MMC host protocol methods are stubbed out at the moment, and need to be wired up to the Linux device drivers.
================================================================================

On mobile and embedded systems, there is usually only a single MMC device for non-volatile storage, which sits behind a controller that is owned by the OS at runtime. This makes it difficult to host the UEFI variable store on MMC as well, since the UEFI runtime services routines expect ownership of the underlying device as well.

This series proposes an approach to work around this. It implements the UEFI MMC host protocol in the kernel, in a way that makes it possible to expose it to the firmware. At the same time, the firmware needs be set up for this, i.e., it needs to expose its MMC host protocol pointer via a UEFI configuration table, so that the kernel can override it if it decides to expose this functionality to the firmware.

Note that these patches are based on patches in the EFI tree that are queued for v4.9, which replace the runtime wrappers spinlock with a semaphore. This allows us to sleep in the firmware callbacks.

Quoted 19 lines · Ard Biesheuvel

================================================================================
NOTE: this is a work in progress, and not fully functional yet. In particular, the actual MMC host protocol methods are stubbed out at the moment, and need to be wired up to the Linux device drivers.
================================================================================

On mobile and embedded systems, there is usually only a single MMC device for non-volatile storage, which sits behind a controller that is owned by the OS at runtime. This makes it difficult to host the UEFI variable store on MMC as well, since the UEFI runtime services routines expect ownership of the underlying device as well.

This series proposes an approach to work around this. It implements the UEFI MMC host protocol in the kernel, in a way that makes it possible to expose it to the firmware. At the same time, the firmware needs be set up for this, i.e., it needs to expose its MMC host protocol pointer via a UEFI configuration table, so that the kernel can override it if it decides to expose this functionality to the firmware.

Quoted 3 lines

Note that these patches are based on patches in the EFI tree that are queued for v4.9, which replace the runtime wrappers spinlock with a semaphore. This allows us to sleep in the firmware callbacks.

Would it be possible to implement the UEFI varstore more generally on top of the Linux pstore interface and then have a pstore backend on top of MMC? That could give us very similar behavior, but also a bit more flexibility. It would be a bit confusing to have the 'dmesg' pstore target on top of UEFI varstore which in turn is on top of pstore on MMC, but I think that's ok as long as we prevent recursion.