Re: [U-Boot] [RFC] efi_loader: EFI variables
On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
Hello Alex, hello Takahiro,
this morning I met Daniel Thompson of Linaro. He thinks it would be quite valuable if U-Boot would at least offer read access to EFI variables at runtime.
I think what it takes is only a RAM buffer that we put between our current storage backend (i.e. synchronization with U-Boot variables) and the API implementation.
We will need such a buffer anyway for non-permanent variables once we have a SPI flash storage.
I think slowly we need to take a critical design decision: Do we want to be in the business of managing runtime UEFI variables?
I don't have a fully cohesive answer to that yet. My gut feeling tells me, that runtime variables would be much better off if they lived in TrustZone. That way we don't have to play relocation tricks, and devices that give you persistency are owned by the secure world anyway, so there is no weird intersection between OS and RTS.
So maybe the path forward would be to implement variable services in ATF (or OP-TEE rather I suppose) and just provide shim stubs to communicate with them from runtime services? That would keep all the variable logic platform agnostic, and we would not have to jump through weird hoops with DM.
Alex
On 2/12/19 10:49 AM, Alexander Graf wrote:
On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
Hello Alex, hello Takahiro,
this morning I met Daniel Thompson of Linaro. He thinks it would be quite valuable if U-Boot would at least offer read access to EFI variables at runtime.
I think what it takes is only a RAM buffer that we put between our current storage backend (i.e. synchronization with U-Boot variables) and the API implementation.
We will need such a buffer anyway for non-permanent variables once we have a SPI flash storage.
I think slowly we need to take a critical design decision: Do we want to be in the business of managing runtime UEFI variables?
I don't have a fully cohesive answer to that yet. My gut feeling tells me, that runtime variables would be much better off if they lived in TrustZone. That way we don't have to play relocation tricks, and devices that give you persistency are owned by the secure world anyway, so there is no weird intersection between OS and RTS.
So maybe the path forward would be to implement variable services in ATF (or OP-TEE rather I suppose) and just provide shim stubs to communicate with them from runtime services? That would keep all the variable logic platform agnostic, and we would not have to jump through weird hoops with DM.
U-Boot' major asset are the many boards supported by drivers. Does ATF or OP-TEE have drivers for SPI?
Or is your idea that U-Boot would provide a module that is set up as a trusted driver or trusted app, cf. https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-of...
Best regards
Heinrich
On 02/12/2019 12:34 PM, Heinrich Schuchardt wrote:
On 2/12/19 10:49 AM, Alexander Graf wrote:
On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
Hello Alex, hello Takahiro,
this morning I met Daniel Thompson of Linaro. He thinks it would be quite valuable if U-Boot would at least offer read access to EFI variables at runtime.
I think what it takes is only a RAM buffer that we put between our current storage backend (i.e. synchronization with U-Boot variables) and the API implementation.
We will need such a buffer anyway for non-permanent variables once we have a SPI flash storage.
I think slowly we need to take a critical design decision: Do we want to be in the business of managing runtime UEFI variables?
I don't have a fully cohesive answer to that yet. My gut feeling tells me, that runtime variables would be much better off if they lived in TrustZone. That way we don't have to play relocation tricks, and devices that give you persistency are owned by the secure world anyway, so there is no weird intersection between OS and RTS.
So maybe the path forward would be to implement variable services in ATF (or OP-TEE rather I suppose) and just provide shim stubs to communicate with them from runtime services? That would keep all the variable logic platform agnostic, and we would not have to jump through weird hoops with DM.
U-Boot' major asset are the many boards supported by drivers. Does ATF or OP-TEE have drivers for SPI?
Or is your idea that U-Boot would provide a module that is set up as a trusted driver or trusted app, cf. https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-of...
I think it's perfectly possible to build a special OP-TEE U-Boot target that can then reuse its drivers, similar to Simon's idea. But we should probably not try to target RTS with that, but only secure enclaves.
Alex
+ tee-dev ML
On Tue, 12 Feb 2019 at 17:36, Alexander Graf agraf@suse.de wrote:
On 02/12/2019 12:34 PM, Heinrich Schuchardt wrote:
On 2/12/19 10:49 AM, Alexander Graf wrote:
On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
Hello Alex, hello Takahiro,
this morning I met Daniel Thompson of Linaro. He thinks it would be quite valuable if U-Boot would at least offer read access to EFI variables at runtime.
I think what it takes is only a RAM buffer that we put between our current storage backend (i.e. synchronization with U-Boot variables) and the API implementation.
We will need such a buffer anyway for non-permanent variables once we have a SPI flash storage.
I think slowly we need to take a critical design decision: Do we want to be in the business of managing runtime UEFI variables?
I don't have a fully cohesive answer to that yet. My gut feeling tells me, that runtime variables would be much better off if they lived in TrustZone. That way we don't have to play relocation tricks, and devices that give you persistency are owned by the secure world anyway, so there is no weird intersection between OS and RTS.
So maybe the path forward would be to implement variable services in ATF (or OP-TEE rather I suppose) and just provide shim stubs to communicate with them from runtime services? That would keep all the variable logic platform agnostic, and we would not have to jump through weird hoops with DM.
U-Boot' major asset are the many boards supported by drivers. Does ATF or OP-TEE have drivers for SPI?
Or is your idea that U-Boot would provide a module that is set up as a trusted driver or trusted app, cf. https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-of...
I think it's perfectly possible to build a special OP-TEE U-Boot target that can then reuse its drivers, similar to Simon's idea. But we should probably not try to target RTS with that, but only secure enclaves.
One of OP-TEE design goals [1] being:
Small footprint - the TEE should remain small enough to reside in a reasonable amount of on-chip memory as found on Arm based systems.
I think this was one of main reason to have tee-supplicant infrastructure in normal world to reuse drivers and keep small footprint of OP-TEE.
So if we build a special OP-TEE u-boot target and link it with optee-os as part of secure enclave then I am not sure how it will align with above design goal.
[1] https://optee.readthedocs.io/general/about.html
-Sumit
Alex
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Tue, Feb 12, 2019 at 12:34:29PM +0100, Heinrich Schuchardt wrote:
On 2/12/19 10:49 AM, Alexander Graf wrote:
On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
Hello Alex, hello Takahiro,
this morning I met Daniel Thompson of Linaro. He thinks it would be quite valuable if U-Boot would at least offer read access to EFI variables at runtime.
I think what it takes is only a RAM buffer that we put between our current storage backend (i.e. synchronization with U-Boot variables) and the API implementation.
We will need such a buffer anyway for non-permanent variables once we have a SPI flash storage.
I think slowly we need to take a critical design decision: Do we want to be in the business of managing runtime UEFI variables?
I don't have a fully cohesive answer to that yet. My gut feeling tells me, that runtime variables would be much better off if they lived in TrustZone. That way we don't have to play relocation tricks, and devices that give you persistency are owned by the secure world anyway, so there is no weird intersection between OS and RTS.
So maybe the path forward would be to implement variable services in ATF (or OP-TEE rather I suppose) and just provide shim stubs to communicate with them from runtime services? That would keep all the variable logic platform agnostic, and we would not have to jump through weird hoops with DM.
U-Boot' major asset are the many boards supported by drivers. Does ATF or OP-TEE have drivers for SPI?
Some ports have SPI drivers and AFAIK it is only really there to facilitate smartcard communications. I'm not aware of any SPI flash storage hooked up to the driver.
Or is your idea that U-Boot would provide a module that is set up as a trusted driver or trusted app, cf. https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-of...
OP-TEE has two implementations of secure storage at present: REE (rich OS) filesystem and eMMC RPMB.
Things will get very circular when the secure storage is the REE filesystem because it is not available to OP-TEE until the REE has booted and started the supplicant. That means u-boot would have to provide a lot of supplicant infrastructure in order to read from the variable store.
Daniel.
On Tue, 12 Feb 2019 at 21:45, Daniel Thompson daniel.thompson@linaro.org wrote:
On Tue, Feb 12, 2019 at 12:34:29PM +0100, Heinrich Schuchardt wrote:
On 2/12/19 10:49 AM, Alexander Graf wrote:
On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
Hello Alex, hello Takahiro,
this morning I met Daniel Thompson of Linaro. He thinks it would be quite valuable if U-Boot would at least offer read access to EFI variables at runtime.
I think what it takes is only a RAM buffer that we put between our current storage backend (i.e. synchronization with U-Boot variables) and the API implementation.
We will need such a buffer anyway for non-permanent variables once we have a SPI flash storage.
I think slowly we need to take a critical design decision: Do we want to be in the business of managing runtime UEFI variables?
I don't have a fully cohesive answer to that yet. My gut feeling tells me, that runtime variables would be much better off if they lived in TrustZone. That way we don't have to play relocation tricks, and devices that give you persistency are owned by the secure world anyway, so there is no weird intersection between OS and RTS.
So maybe the path forward would be to implement variable services in ATF (or OP-TEE rather I suppose) and just provide shim stubs to communicate with them from runtime services? That would keep all the variable logic platform agnostic, and we would not have to jump through weird hoops with DM.
U-Boot' major asset are the many boards supported by drivers. Does ATF or OP-TEE have drivers for SPI?
Some ports have SPI drivers and AFAIK it is only really there to facilitate smartcard communications. I'm not aware of any SPI flash storage hooked up to the driver.
I think SPI flash driver in OP-TEE for variable storage should be doable.
Or is your idea that U-Boot would provide a module that is set up as a trusted driver or trusted app, cf. https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-of...
OP-TEE has two implementations of secure storage at present: REE (rich OS) filesystem and eMMC RPMB.
Things will get very circular when the secure storage is the REE filesystem because it is not available to OP-TEE until the REE has booted and started the supplicant. That means u-boot would have to provide a lot of supplicant infrastructure in order to read from the variable store.
AFAIK, u-boot does provide some supplicant infrastructure for eMMC RPMB storage here: drivers/tee/optee/supplicant.c drivers/tee/optee/rpmb.c
But if we want to use this infrastructure for variable storage then we need to make this as part of RTS.
-Sumit
Daniel. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
participants (4)
-
Alexander Graf -
Daniel Thompson -
Heinrich Schuchardt -
Sumit Garg