dtboverlay to U-Boot runtime dtb
Heinrich Schuchardt
xypron.glpk at gmx.de
Mon Jul 4 15:56:51 CEST 2022
On 7/4/22 15:39, Tom Rini wrote:
> On Mon, Jul 04, 2022 at 03:27:26PM +0200, Heinrich Schuchardt wrote:
>> On 7/4/22 14:51, Peter Robinson wrote:
>>> Hi Peng,
>>>
>>>> I did a test to do overlay for U-Boot runtime dtb, but after overlay
>>>> finish, U-Boot DM driver not work properly because the of_node
>>>> pointer is changed in a device.
>>>>
>>>> So I am thinking whether this is valid to overlay to runtime U-Boot
>>>> dtb or not. The reason I try this is that I wanna overlay the EFI capsule
>>>> signature to U-Boot dtb, then capsule update with authentication
>>>> could work, otherwise I need integrate the signature in dts and
>>>> rebuild the image. I understand current U-Boot not support
>>>> overlay U-Boot runtime dtb, just thinking whether this is valid or
>>>> should we support it.
>>
>> Applying overlays to the control device-tree is not supported. Allowing
>> console access on a system where you plan to apply authenticated
>> capsules seems unwise from a security viewpoint. So we should not
>> support your scenario.
>
> Note that Peng didn't say "apply an overlay from the console". I had
> assumed the desire was to see about doing all of this automatically as
> part of processing the update/etc.
>
> I thought we had something similar already, so that we could start with
> a "generic" device tree, figure out we're on board X, grab that device
> tree (as we're a FIT image and had N dtbs), and then switch to that.
> But right now I only spot the logic for selecting that dtb in SPL and
> telling full U-Boot to use that tree.
>
His question was about avoiding rebuilding the image. So he wants to
apply an overlay at run-time not at build time to change the key used to
check capsule signatures. This should not be allowed.
Best regards
Heinrich
More information about the U-Boot
mailing list