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. > > 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?". Regards /Ilias > > If you have any suggestions for another way of detecting this, please > feel free to share. I, unfortunately, don't. > > Regards, > Max
