Hello, I'm Unacid Man.
I work at Pengutonix in the kind of team and I also work on our bootloader
barbox, which we've heard a presentation before.
I give a very quick lightning talk of 10 minutes about the new feature.
We've implemented for factory data.
We use system images for the barbox kind of system.
And they are identical across all units.
We only have one update image.
That sometimes they arise as a need for unit specific data.
So for a single instance of a barge that might be things like serial numbers,
make addresses.
The specific hardware configuration on the unit are version and calibration data.
And they also should be part of a secure bootchain.
And we had to come up with a solution of how we still do this unique specific data.
So we came up with a barbox, TLV, tag link value format.
It's supposed to be parts only once in the bootloader.
And then it's passed on to the kernels.
I will get to a signage, which is part that I implemented in the end of the talk.
And we also wanted this format to be extensible to any fields,
or any bits of information that parts would need.
So those were the requirements for the design.
What we came up with is a format that looks like this.
And that it's core test list of tag length value fields.
So the tag is just two bytes identifier of the field.
The length is the length of the value.
And the value can be any data as we can see here.
It can be string or it can be binary data that is interpreted in an arbitrary way.
We have some defaults, but for extensibility, as I said earlier,
it's not designed strictly by the format which fields are available.
And therefore we have a magic, which is specific to the TLV interpretation to the board,
or to at least the single file that's on our board.
And it defines the interpretation of the values of a TLV.
Then we have to standard file format things like the length.
We have the length of a signature, what we see here is an unsigned TLV.
And then we have a checksum.
As it's a custom format, when generating those files,
we don't only need the data that is to be stored.
We also need the description of what fields are in this specific type of TLV.
What is the interpretation of each tag for this magic number?
And so here is an example schema and an example data.
One way we offer how they are generated in production,
this patent script that you have generated, that consumes HTML files.
And if it supports a bunch of formats already,
but it's easily extensible for other binary interpretations.
And then on the barbox site, it's defined in the device tree where TLV can be found
on a partition.
And there we see the binary of the file.
And for the interpretation, the TLV decoder is interpreted as a driver
and is matched with the compatible on the driver bus.
So to define such a decoder, it needs a compatible string.
And then it needs a list of methods that correspond to the interpretation of the single fields.
So that's the tag.
Then functions that is called on each field and the name of the field.
And the handleis is the name of the functions.
They consume the information.
They might do something with it.
But also they put the string representation in it as a fix up on the device tree.
And in that way, it's passed back to the kernel.
So in summary of the format, it's a key value format.
And it's custom by having a definition of text to formats by the metrics.
And after handling them, the serial presentation is passed on to the kernel.
Now we can get on to signature.
Not mandatory, it is enabled by setting a name of a signature hearing in the decoder's track.
And the key rings are the public keys are built into the verb of binary.
And they are selected in menu config.
We're an arbitrary number of RSA and ECDSA keys can be added to a hearing.
And for easy integration in a build system, environment variables can also be specified in this Kconfix symbol,
which will be expanded either.
Single keys can be expanded or the whole.
The hearing specification can be extended.
So at this point, we have signed TLV files somewhere in our EPROM or something like this.
They cannot be manipulated, but they are valid across all builds of barbox.
So as they contain unit specific data, there may be a need to prevent interchange of those TLV files across units.
So that TLV is not only valid for the barbox, but also only valid on single unit.
And it's otherwise rejected.
And this is solved in a very simple manner.
So we bind to some already authenticated value, which should be in silicon on the SOC.
It could be a SOC ID or a Mac address.
And we just add a handler.
Here is an example for the SOC ID.
And all we need to do is compare the SOC ID in silicon to the SOC ID provided in the TLV.
And if they don't match, we abort and this abarge parsing of the complete TLV file to ensure that it's only valid for.
The unit that matches this SOC ID or Mac address.
Let concludes my presentation.
Thank you.