On Fri, May 21, 2021 at 05:21:32PM +0100, Grant Likely wrote:

Hi everyone,

Here is the agenda for Monday's EBBR meeting. This week Ilias will present his proposed solution to to solve StMM RPMB writes at runtime so that SetVariable can be generically enabled.

Ilias, do you have any details that you can provide ahead of the meeting?

I think I came up with a better idea, than the one I already coded, but let's discuss that on Monday!

What would make sense is try and explain the problem, so people at least know what we are trying to solve.

Up to now most of the implementations for Arm, that support SetVariable at runtime, have a dedicated secure world flash. So adding the SetVariable functionality is relatively 'easy', since the OS has no way of accessing the flash. Specifically for EDK2, we have an application that's called StandAloneMM (StMM). That application is running on S-EL0 and is responsible for two things: - Perform the variable authentication/checking. - Provide the driver to access the hardware in order to read/write variables. So the driver is on an isolated secure world component, that is always preserved after ExitBootServices is called.

The problems appear when the storage is shared between the OS and the firmware. Part of the work in Linaro was enabling an eMMC device with an RPMB partition in U-Boot, that we use to store the sensitive EFI variables. We did that by running StMM as-is from EDK2 in OP-TEE. There's a detailed explanation here [1].

OP-TEE has no eMMC drivers to access the RPMB partition though. Instead, since the hardware lives on the non-secure world, we rely on the firmware and OS drivers to perform the reads/writes. When OP-TEE wants to access that storage, it sends a message to the OP-TEE supplicant, an application that's present in both Linux and U-Boot. The supplicant then wires up the calls in the proper eMMC driver to perform the actual access.

So in U-Boot, before ExitBootServices is called, you can read and write EFI variables. Once ExitBootServices is called though the U-Boot drivers and the supplicant disappear. What we currently do is copy the variables on EFI runtime memory. When linux wants to read the variables, U-Boot just reads that piece of memory, so GetVariable and GetNextVariable are working. However SetVariable isn't, since we don't have access to the hardware anymore. But SetVariable is an important piece of the puzzle we are trying to solve. We need to store EFI variables, in order to be able to change the BootOrder, perform CapsuleUpdates etc etc.

I'll try to prepare some slides with the available options we have for solving this.

[1] https://www.linaro.org/blog/protected-uefi-variables-with-u-boot/

Thanks /Ilias

Dial in details are below

g.

Agenda:

• StMM RPMB writes at runtime
• ESRT requirement review
• other business

---

Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Topic: EBBR Biweekly Time: 10 May 2021, 16:00-17:00 GMT Meeting ID: 920 8136 5511 Passcode: 490324 One tap mobile +14086380968,,92081365511#,,,,*490324# US (San Jose) +16465189805,,92081365511#,,,,*490324# US (New York)

Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 920 8136 5511 Passcode: 490324 Find your local number: https://armltd.zoom.us/u/abf0Umg7EM

Join by SIP 92081365511@zoomcrc.com

Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia Sydney) 103.122.167.55 (Australia Melbourne) 209.9.211.110 (Hong Kong SAR) 149.137.40.110 (Singapore) 64.211.144.160 (Brazil) 69.174.57.160 (Canada Toronto) 65.39.152.160 (Canada Vancouver) 207.226.132.110 (Japan Tokyo) 149.137.24.110 (Japan Osaka) Meeting ID: 920 8136 5511 Passcode: 490324

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture