Messages in this thread | | | Date | Tue, 2 Aug 2022 21:11:49 +0200 | Subject | Re: [PATCH 0/4] firmware: Add support for Qualcomm UEFI Secure Application | From | Maximilian Luz <> |
| |
On 8/2/22 16:02, Ard Biesheuvel wrote: > On Tue, 2 Aug 2022 at 15:22, Maximilian Luz <luzmaximilian@gmail.com> wrote:
[...]
>> I generally agree with the sentiment, however UEFI variables should IMHO be >> handled by the kernel. Moving handling of those to userspace breaks things like >> EFI-based pstore and efivarfs. The latter will in turn break some user-space >> tools (most notably efibootmgr used by e.g. GRUB and I think fwupdmgr which >> needs to set some capsule variables). Ideally, we would find a way to not break >> these, i.e. have them work out-of-the-box. >> > > Only capsule-on-disk requires SetVariable() at runtime, and I doubt > whether these platforms implement any of that. > >> A similar argumentation might apply to the TPM app. >> > > There is a difference, though - the TPM is modeled as a device and > runtime access to it is implemented as a device driver, which is only > accessed from user space.
Ah, thanks for that info! I wasn't sure about that last part.
But we'd still need _something_ in the kernel. All the common software using TPMs would expect the TPM to be present as /dev/tpmX. So, while it doesn't have to be a full secure-app driver, we'd need at least some way to manage a TPM device from user-space (unless we want to tell all software using TPMs to just support some non-standard thing instead).
For EFI variables, something similar might be possible (i.e. running efivar operations through a user-space driver), but that will break pstore in the times it's most usable (i.e. when no user-space exists or things are sufficiently broken that we can't run things through it any more).
And then (at least for me) there's the question whether that all seems sound: Sure, we can maintain some userspace-daemon outside the kernel, but if it is common enough (i.e. not a one-off used only by some single vendor and model) and can be easily implemented in the kernel, why not? Moving it to userspace makes things more complex. You'll need new userspace APIs (as mentioned above, if you don't want to force all existing software to adapt to some non-standard thing) and you need to tell users to install and set up some daemon(s) (making it yet more difficult to produce a single proper install media that works well on all the common AArch64 or WoA platforms). All the while you still need to maintain essentially the same piece of code (whether it is inside or outside of the kernel), so you don't really win anything there either.
Regards, Max
| |