Re: [isar-cip-core][PATCH 3/8] Include optee into u-boot

[Jan Kiszka <jan.kiszka@siemens.com>]

On 07.11.22 17:57, Schultschik, Sven (DI PA DCP R&D 2) wrote:
>>>>>
>>>>
>>>> Right. When we switch this, we also need to switch the secure boot
>>>> setup procedure so that the result remains securely booted.
>>>>
>>>> Jan
>>> Do you want to do those adjustments within this patch series or do it
>>> separately?
>>
>> Well, if we leave out enabling CONFIG_EFI_MM_COMM_TEE from this series,
>> would that leave something testable / minimally useful behind? If not, we 
>> need
>> the transition to secure boot keys in RPMB already in this series.
>>
> 
> If we go fully on the optee rpmb solution only with the manual test patch 8/8
> 
> Else we would need to provide a
> - PK, KEK and db
> - a u-boot script which does on every boot such things
> fatload virtio 1:1 40000000 PK.auth
> setenv -e -nv -bs -rt -at -i 40000000:$filesize PK
> fatload virtio 1:1 40000000 KEK.auth
> setenv -e -nv -bs -rt -at -i 40000000:$filesize KEK
> fatload virtio 1:1 40000000 db.auth
> setenv -e -nv -bs -rt -at -i 40000000:$filesize db
> 
> Why?
> The secure UEFI environment is not persistent in the patched u-boot qemu 
> setting. The RPMB in u-boot is emulated as struct in memory.
> 

Ouch... We need a persistent and consistent (u-boot vs. kernel) RPMB to
actually test this with realistic scenarios, I suppose.

> Jan we could make a small talk if you want to discuss further steps.
> 

Can you summarize again here what options we have now? It seems we need
a proper RPMB emulation rather sooner than later.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux