Hi, not sure if this is a good place to ask, however I see that OPTEE developers are highly involved in this topic so I decided to ask. Short background - we've been working on an embedded system based on Layerscape 1028A SoC. On this platform we've been using TFA (bl2, el3 runtime services), OPTEE as BL32 and u-boot as BL33. In the previous, older platforms we usually stored u-boot's environment in let's say "traditional way", we just stored the env on some offset of the eMMC device, however I see that on this particular, new platform there are some better possibilities, like combining OPTEE, EDKII StandaloneMM and u-boot efivars implementation to store EFI variables in RPMB on eMMC which seems to be more secure, UEFI compliant way. The aspect I'm unsure of is - does it make sense to utilize these capabilities if we want to only use it to store some u-boot's writable env variables and not utilize features like UEFI SecureBoot (at least for now, it may change it in the future)?
I would be grateful for some advice.
Best regards Patryk
Hi Patryk
On Thu, 12 Dec 2024 at 13:37, Patryk pbiel7@gmail.com wrote:
Hi, not sure if this is a good place to ask, however I see that OPTEE developers are highly involved in this topic so I decided to ask.
It is. FWIW this is a project Jens and I mostly worked on.
Short background - we've been working on an embedded system based on Layerscape 1028A SoC. On this platform we've been using TFA (bl2, el3 runtime services), OPTEE as BL32 and u-boot as BL33. In the previous, older platforms we usually stored u-boot's environment in let's say "traditional way", we just stored the env on some offset of the eMMC device, however I see that on this particular, new platform there are some better possibilities, like combining OPTEE, EDKII StandaloneMM and u-boot efivars implementation to store EFI variables in RPMB on eMMC which seems to be more secure, UEFI compliant way. The aspect I'm unsure of is - does it make sense to utilize these capabilities if we want to only use it to store some u-boot's writable env variables and not utilize features like UEFI SecureBoot (at least for now, it may change it in the future)?
The RPMB support is only plugged in for EFI variables. You can find more information here [0] [1]
[0] https://www.linaro.org/blog/protected-uefi-variables-with-u-boot/ [1] https://www.linaro.org/blog/uefi-secureboot-in-u-boot/
Regards /Ilias
I would be grateful for some advice.
Best regards Patryk
Hi, Thanks Ilias
The RPMB support is only plugged in for EFI variables. You can find more information here [0] [1]
[0] https://www.linaro.org/blog/protected-uefi-variables-with-u-boot/ [1] https://www.linaro.org/blog/uefi-secureboot-in-u-boot/
I've read your really good articles and actually used them as a base for my research and experiments. I'm also aware that the RPMB currently works with EFI variables. My point is (maybe not clearly expressed before) - would it make sense from your perspective to use RPMB together with OPTEE also as a storage for non EFI variables? I've done some research and it seems not to be that hard, we already have optee_rpmb read/write u-boot shell commands that work in similar way, so we could just plug in the underlying mechanism to the u-boot's env subsystem. I thought about creating such an implementation (at least POC) that uses RPMB through OPTEE (similarly like in case of EFI but without StMM) to store non EFI, U-BOOT variables. I think it could be useful as it would provide more secure storage for u-boot env variables that could be used in non UEFI use cases. I'm asking because I might not see the whole picture, and my assumptions could be wrong. So, I thought I would ask someone more involved before diving in. The whole idea arose from the discussion in my team about storing u-boot writable env variables in some more secure way without having to use UEFI (at least for now). Will be grateful for some response.
Best regards Patryk
On Fri, 13 Dec 2024 at 14:41, Patryk pbiel7@gmail.com wrote:
Hi, Thanks Ilias
The RPMB support is only plugged in for EFI variables. You can find more information here [0] [1]
[0] https://www.linaro.org/blog/protected-uefi-variables-with-u-boot/ [1] https://www.linaro.org/blog/uefi-secureboot-in-u-boot/
I've read your really good articles and actually used them as a base for my research and experiments. I'm also aware that the RPMB currently works with EFI variables. My point is (maybe not clearly expressed before) - would it make sense from your perspective to use RPMB together with OPTEE also as a storage for non EFI variables? I've done some research and it seems not to be that hard, we already have optee_rpmb read/write u-boot shell commands that work in similar way, so we could just plug in the underlying mechanism to the u-boot's env subsystem. I thought about creating such an implementation (at least POC) that uses RPMB through OPTEE (similarly like in case of EFI but without StMM) to store non EFI, U-BOOT variables. I think it could be useful as it would provide more secure storage for u-boot env variables that could be used in non UEFI use cases. I'm asking because I might not see the whole picture, and my assumptions could be wrong. So, I thought I would ask someone more involved before diving in. The whole idea arose from the discussion in my team about storing u-boot writable env variables in some more secure way without having to use UEFI (at least for now). Will be grateful for some response.
It depends on the use case really. The usual practice right now to protect env variables is built-in variables and disable. So if a chain of trust verifies U-Boot you also implicitly verify the variables. Using the RPMB would be a good way to ensure no one tampered with env variables outside U-Boot, but how do you expect to update them? If you enable the command line that defeats the purpose as anyone can update them. So I guess you are thinking of verified scripts that changes those?
I think the u-boot ML is a better place for such a discussion
Thanks Ilias
Best regards Patryk
op-tee@lists.trustedfirmware.org
-
Ilias Apalodimas -
Patryk