[PATCH 4/4] kbuild: arm: Fix duplicate builds of dtbs

[Jan Kiszka]

On 18.05.20 18:26, Andrew F. Davis wrote:
> On 5/8/20 11:54 AM, Jan Kiszka wrote:
>> On 08.05.20 17:40, Andrew F. Davis wrote:
>>> On 5/4/20 8:38 AM, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka at siemens.com>
>>>>
>>>> Build the secured board dtbs (.dtb_HS) as part of the regular dtb build
>>>> on CONFIG_TI_SECURE_DEVICE targets. This avoids rebuilding them,
>>>> possibly overwriting artifacts that are in use, as it is done so far.
>>>>
>>>> In the same run, fix needless rebuilding of the secured spl dtb.
>>>>
>>>> Fixes: 508369672ca3 ("arm: mach-k3: Add secure device build support")
>>>> CC: Andrew F. Davis <afd at ti.com>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
>>>> ---
>>>>    arch/arm/dts/Makefile             |  6 ++++--
>>>>    arch/arm/mach-k3/config_secure.mk | 19 ++++++++++++++-----
>>>>    2 files changed, 18 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>>>> index 2c123bd6da..b68e9c0726 100644
>>>> --- a/arch/arm/dts/Makefile
>>>> +++ b/arch/arm/dts/Makefile
>>>> @@ -1,5 +1,7 @@
>>>>    # SPDX-License-Identifier: GPL-2.0+
>>>>
>>>> +include $(srctree)/arch/arm/mach-k3/config_secure.mk
>>>> +
>>>
>>>
>>> This is hacky, we should not in the top level dts makefile have a
>>> dependency on a specific platform configuration file.
>>>
>>> What about mach-omap/config_secure.mk, etc..
>>
>> They don't need those special signing the k3 need. If they did, they
>> could be included here as well.
>>
>
>
> I did everything the same in that file, so I don't see why it wouldn't
> need the same treatment. But my point is that this will keep growing,
> the fixes should be local to the mk files or everyone who does something
> similar will need to add here.
>

The problem is that dtbs are built in a separate make session. If you
want to address specific dtbs in a rule, you must do that in that
session, not outside like you did. That applies to signing for TI K3,
just like it would for bringing in public keys as discussed below.

I think you mentioned offlist that eliminating this nesting would help,
but I do not yet see if that can be easily done.

>
>>>
>>> The negative of building dtbs twice for HS is very minor compared to the
>>> extra complexity this patch adds. It will be much more difficult to
>>> clean this up later.
>>
>> Overwriting a build artifacts that were already completed and may just
>> be in use while doing so is broken. This must be fixed.
>>
>
>
> Absolutely agree it needs fixed, just not sure this just doesn't add to
> the makefile complexity in the wrong way.
>

As I said, I'm open for other approaches that resolve this.

>
>> As I wrote, I will add support for injecting public keys into the dtbs,
>> and that also revealed this issue.
>>
>
>
> If I understand right, you are adding the keys into the dtb then signing
> them? Why not add them to the dts first, then nothing would need to
> change with multiple builds of the dtbs.

You sign the chain from right to left, while loading is left to right:
the right-side image is signed while injecting the necessary keys/certs
into the left-side image that loads it. And then that is signed as well,
in the end often with a hardware-specific mechanism (unfortunately).

But dtbs are hardware-specific, keys are deployment-specific. That's why
they are injected into existing dtbs, rather than asking the user to
patch them into dts files in the source tree. Just today I ran into
another piece of code that models this signing and key injection outside
of U-Boot, with a lot of knowledge about the particular target. It would
be way nicer to solve that generically.

Jan