On 7/28/22 14:35, Ilias Apalodimas wrote:
Hi Maximilian
On Thu, 28 Jul 2022 at 13:48, Maximilian Luz <luzmaximilian@xxxxxxxxx> wrote:
On 7/28/22 08:03, Ilias Apalodimas wrote:
Hi all,
On Wed, 27 Jul 2022 at 16:24, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
On Wed, Jul 27, 2022 at 03:03:49PM +0200, Maximilian Luz wrote:
Is there really a good way around it?
Yes rely on the firmware preferably auto discover, if that is not an option,
how about query. It seem to be working in your case.
That's a good point. We have a similar situation with some Arm
devices and U-Boot. Let me try to explain a bit.
There's code plugged in in OP-TEE and U-Boot atm which allows you to
store EFI variables on an RPMB. This is a nice alternative if your
device doesn't have any other secure storage, however it presents
some challenges after ExitBootServices, similar to the ones you have
here.
The eMMC controller usually lives in the non-secure world. OP-TEE
can't access that, so it relies on a userspace supplicant to perform
the RPMB accesses. That supplicant is present in U-Boot and
Get/SetVariable works fine before ExitBootServices. Once Linux boots,
the 'U-Boot supplicant' goes away and we launch the linux equivalent
one from userspace. Since variable accessing is a runtime service and
it still has to go through the firmware we can't use those anymore
since U-Boot doesn't preserve the supplicant, the eMMC driver and the
OP-TEE portions needed in the runtime section(and even if it did we
would now have 2 drivers racing to access the same hardware). Instead
U-Boot copies the variables in runtime memory and
GetVariable/GetNextVariable still works, but SetVariable returns
EFI_UNSUPPORTED.
I've spent enough time looking at available solutions and although
this indeed breaks the EFI spec, something along the lines of
replacing the runtime services with ones that give you direct access
to the secure world, completely bypassing the firmware is imho our
least bad option.
This sounds very similar to what Qualcomm may be doing on some devices.
The TrEE interface allows for callbacks and there are indications that
one such callback-service is for RPMB. I believe that at least on some
platforms, Qualcomm also stores UEFI variables in RPMB and uses the same
uefisecapp interface in combination with RPMB listeners installed by the
kernel to access them.
I have an ancient branch somewhere that I can polish up and send an
RFC [1], but the way I enabled that was to install an empty config
table from the firmware. That empty table is basically an indication
to the kernel saying "Hey I can't store variables, can you do that for
me".
Is there any chance we can do something similar on that device (or
find a reasonable way of inferring that we need to replace some
services). That way we could at least have a common entry point to
the kernel and leave out the DT changes.
[1] https://git.linaro.org/people/ilias.apalodimas/net-next.git/log/?h=setvar_rt_optee_3
I would very much like to avoid the need for special bootloaders. The
devices we're talking about are WoA devices, meaning they _should_
ideally boot just fine with EFI and ACPI.
I've already responded to following email, but I'll repeat it here for
completeness. It's not a special bootloader. It's the opposite, it's
a generic UEFI compliant bootloader which takes advantage of the fact
EFI is extensible. We are doing something very similar in how we load
our initrd via the EFI_LOAD_FILE2 protocol. Whether Qualcomm can add
that to their bootloaders is a different topic though. But at some
point we need to draw a line than keep overloading the DT because a
vendor decided to go down it's own path.
But still, you're asking users to install an extra thing in the boot
chain. That's what I mean by "special". So the situation would then be
this: User needs a) GRUB (or something similar) for booting the kernel
(or dual-booting, ...), b) DTBLoader for loading the device-tree because
we don't support the ACPI Qualcomm provided, and c) your thing for EFI
variables and potentially other firmware fix-ups. b) and c) are both
things that "normal" users don't expect. IMHO we should try to get rid
of those "non-standard" things, not add more.
From an end-user perspective, it's annoying enough that we'll have to
stick with DTs for the time being due to the use of PEPs in ACPI. I
really don't want to add some special bootloader for fixups to that.
Also, this would just move the problem from kernel to bootloader.
But it *is* a bootloader problem. The bootloader is aware of the fact
that it can't provide runtime services for X reasons and that's
exactly why we are trying to set EFI_RT_PROPERTIES_TABLE correctly
from the firmware. All we are doing is install a config table to tell
the OS "I can't do that, can you find a way around it?".
Sure, but is making the Linux installation process more device
dependent and complicated really the best way to solve this?
Regards,
Max
