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