[RFC PATCH] binman: bintool: etype: Add support for ti-secure entry
Neha Malcom Francis
n-francis at ti.com
Tue Mar 14 04:38:47 CET 2023
Hi Simon
On 11/03/23 02:19, Simon Glass wrote:
> Hi,
>
> On Thu, 9 Mar 2023 at 21:35, Neha Malcom Francis <n-francis at ti.com> wrote:
>>
>> Hi Andrew, Simon
>>
>> On 01/03/23 22:41, Andrew Davis wrote:
>>> On 2/28/23 9:10 AM, Simon Glass wrote:
>>>> Hi Neha,
>>>>
>>>> On Tue, 28 Feb 2023 at 02:50, Neha Malcom Francis <n-francis at ti.com>
>>>> wrote:
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>> On 28/02/23 06:05, Simon Glass wrote:
>>>>>> Hi Neha,
>>>>>>
>>>>>> On Fri, 24 Feb 2023 at 05:03, Neha Malcom Francis <n-francis at ti.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> core-secdev-k3 is the TI security development package provided for K3
>>>>>>> platform devices. This tool helps sign bootloader images with the x509
>>>>>>> ceritificate header.
>>>>>>>
>>>>>>> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
>>>>>>> ---
>>>>>>> This patch depends on
>>>>>>> https://patchwork.ozlabs.org/project/uboot/patch/20230224115101.563729-1-n-francis@ti.com/
>>>>>>> and on ongoing development in
>>>>>>> https://git.ti.com/cgit/security-development-tools/core-secdev-k3
>>>>>>>
>>>>>>> tools/binman/btool/tisecuretool.py | 72 +++++++++++
>>>>>>> tools/binman/etype/ti_secure.py | 114
>>>>>>> ++++++++++++++++++
>>>>>>> tools/binman/ftest.py | 36 ++++++
>>>>>>> tools/binman/test/278_ti_secure_rom.dts | 11 ++
>>>>>>> tools/binman/test/279_ti_secure.dts | 11 ++
>>>>>>> .../binman/test/280_ti_secure_nofilename.dts | 10 ++
>>>>>>> tools/binman/test/281_ti_secure_combined.dts | 12 ++
>>>>>>> 7 files changed, 266 insertions(+)
>>>>>>> create mode 100644 tools/binman/btool/tisecuretool.py
>>>>>>> create mode 100644 tools/binman/etype/ti_secure.py
>>>>>>> create mode 100644 tools/binman/test/278_ti_secure_rom.dts
>>>>>>> create mode 100644 tools/binman/test/279_ti_secure.dts
>>>>>>> create mode 100644 tools/binman/test/280_ti_secure_nofilename.dts
>>>>>>> create mode 100644 tools/binman/test/281_ti_secure_combined.dts
>>>>>>
>>>>>> Now that I see what you are doing, this it not quite the right way.
>>>>>>
>>>>>> See this hack-up of how you can call the openssl thing. Basically you
>>>>>> should not have a shell script in the way, but instead make your
>>>>>> bintool do it.
>>>>>>
>>>>>> https://github.com/sjg20/u-boot/commit/03c0d74f81106570b18d8e4fe7a3355bfeb0d5da#r100378804
>>>>>>
>>>>>> I suppose we can have an openssl bintool that others build on top of?
>>>>>>
>>>>>> Regards,
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>
>>>>> That is possible, maybe ti-secure extends from x509_cert etype so as to
>>>>> support the TI specific certificate extensions. I'll start working on
>>>>> this.
>>>>>
>>>>> However the patches I've sent support external production flow where
>>>>> signing need not necessarily be carried out from U-Boot. An external
>>>>> repo that acts as what is core-secdev-k3 here, would be the repo
>>>>> responsible for signing.
>>>>>
>>>>> Could we find a way to combine both so as to support production flow
>>>>> mandating an external agency, as well as a completely within U-Boot flow
>>>>> using bintool? i.e. we modify ti-secure etype to be able to support both
>>>>> external git repo/executable script signing as well as default signing
>>>>> using openssl bintool.
>>>>
>>>> Yes that seems important.
>>>>
>>>> One option is to have binman emit some instructions on how to sign the
>>>> image, perhaps a simple data format similar to an fdtmap, with a basic
>>>> shell script plus whatever the etype provides. Then the signer can
>>>> follow the instructions or run the script.
>>>>
>>>> Another option is to run binman on the signer and have it do the
>>>> signing. Would that work?
>>>>
>>>
>>> I'd like to keep the dependencies needed on the signing server as
>>> minimal as possible. We do require the "u-boot-tools" package on
>>> the key servers if folks want to re-package signed FIT images, so
>>> if binman could be reasonably packaged in that package someday
>>> it could be an option.
>
> At present binman is packaged as binary-manager (with 'pip install').
> Is that good enough? We could add it to u-boot-tools, perhaps, but I
> have found that packing Python things together with non-Python things
> seems to be tricky. We gave up with libfdt and ended up using a
> separate package for pylibfdt.
>
>>>
>>> For now, if binman could generate the x509 file and leave it with the
>>> other boot artifacts then if one needs to re-sign with real keys they
>>> will only need to have openssl sign that cert and append to the image
>>> on the key server, that is simple enough document.
>
> I sent a patch to add x509 cert using the openssl tool[1]. If there is
> more needed, can you take a look or let me know what is missing?
>
I had looked at the patch and I think it should support custom
certificates as well. I think an x509 etype should be able to produce a
general certificate like what you have done, as well as have the
capability to add more extensions, change parameters etc. I am thinking
of a template and dict sort of method where you pass your custom
template as well as a dict/config file containing
parameter:parameter-valye pairs for the etype to fill in, does that
sound okay? Then in use cases like ours where there's more done we could
extend this etype and use that parse-and-replace mechanism for our
certificate.
>>>
>>> The more difficult part is in re-packaging these signed images.
>>> Our security tools already have a tool to disasemble a FIT image,
>>> sign the components, then re-assemble it[0]. This would work for
>>> u-boot.img and the kernel FIT images, but we would need something
>>> new for re-assembling boot3.bin and tispl.bin. The first boot files
>>> (boot3.bin) is also more complex that simple FIT images in that it
>>> has several variations in format and content based on device family
>>> and type.
>>>
>>> The ideal case would be we do not need to pull in the TI security tools
>>> package at all and we could drop this patch. The tools would then only be
>>> needed by folks wanting to sign their images using an external key
>>> server.
>
> Yes, that seems to be the bare minimum of what we should reach here.
> Any tools we need should be available in 'binman tool -l' and be
> fetchable / buildable with binman. It is such a pain for users if
> everyone does their own thing. It is even more difficult for people
> who develop U-Boot generally, since they just want to build and run.
> For example, in my lab I want to be able to build U-Boot in a generic
> way and have it boot on a board.
>
>>>
>>> If we could have binman learn how to generate/template x509 certs and
>>> have it sign them with openssl, plus add the TI dummy[1] and degenerate[2]
>>> keys to the u-boot source repo, then we would not need TI security
>>> tools any more here.
>
> OK, see the patch.
>
>>>
>>> This might be a longer term goal though, and I think we are already
>>> trying to do too much all at once as is. Perhaps we could take
>>> this current solution posted here with the intent to remove it in
>>> the near future. Thoughts?
>
> IMO the problem here is starting with shell scripts. They are OK for
> hacking but we are trying to use a data-driven image description,
> rather than having a lot of shell scripts.
>
> It took ages to remove the SPL_FIT_GENERATOR stuff
>
>>>
>>> Andrew
>>>
>>> [0]
>>> https://git.ti.com/cgit/security-development-tools/core-secdev-k3/tree/scripts/fit-image-secure.sh
>>> [1]
>>> https://git.ti.com/cgit/security-development-tools/core-secdev-k3/tree/keys/custMpk.pem
>>> [2]
>>> https://git.ti.com/cgit/security-development-tools/core-secdev-k3/tree/keys/ti-degenerate-key.pem
>>>
>>
>> I think leaving the boot artifacts while going with the current solution
>> would be a better option. As Andrew mentioned, the complexity mainly
>> comes with the way our tiboot3.bin is packaged. It seems cleaner for now
>> to go with this since this patch series is only a part in the larger
>> series of packaging all the bootloader images.
>>
>> I will take future action to eventually completely remove using TI
>> security tools. What do you think, Simon?
>
> I am not convinced. We still have SPL_FIT_GENERATOR after 5 years.
>
> Can we not just do this work now? I am happy to help on the binman
> side, but I have not heard back on the series I sent, so I am not sure
> what is missing.
>
> [..]
> Regards,
> Simon
>
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20230303000246.2640473-4-sjg@chromium.org/
--
Thanking You
Neha Malcom Francis
More information about the U-Boot
mailing list