WEBVTT 00:00.000 --> 00:14.000 This is the CRA, yes, we are full of excitement, I would say. 00:14.000 --> 00:15.000 Of course. 00:15.000 --> 00:18.000 All right, we're going to get continue. 00:18.000 --> 00:26.000 Thanks very much for coming, and we're continuing with our program of our show, which is CRA in practice, 00:26.000 --> 00:29.000 the next app is Martha Rabgiska. 00:29.000 --> 00:36.000 We'll talk about the CRA compliance and embedded systems, a practical look from the Yachtau project models. 00:36.000 --> 00:37.000 Please. 00:43.000 --> 00:48.000 So how many embedded developers are there in this room? 00:49.000 --> 00:52.000 Oh, damn it. 00:52.000 --> 00:57.000 Okay, so how many embedded product users are there? 00:57.000 --> 01:03.000 Yeah, so it means that this talk applies to all of you, basically. 01:03.000 --> 01:09.000 So if you do not know me, my name is Martha, and I talk a lot about security, 01:09.000 --> 01:14.000 when I do not talk about open source, basically. 01:14.000 --> 01:21.000 And those recent months, I'm doing a lot of work on the CRA, including the standardization, 01:21.000 --> 01:28.000 and including Ellie compliance for CRA. 01:28.000 --> 01:34.000 And this talk is about my personal opinion. 01:34.000 --> 01:39.000 There's no official statement of the Yachtau project and so on and so on. 01:39.000 --> 01:42.000 Yeah, so. 01:42.000 --> 01:45.000 But first, what is your project? 01:45.000 --> 01:51.000 Yachtau project is really not, but not only distribution creation framework, 01:51.000 --> 01:56.000 mostly from embedded, but you're not obliged to use it and embedded. 01:56.000 --> 02:01.000 And the advantage is that it's very easy to be extended by hardware vendors, 02:01.000 --> 02:03.000 and that's what they are doing. 02:03.000 --> 02:07.000 And it's the fact that the standard of building the distribution, 02:07.000 --> 02:13.000 with open source licenses in a foundation project, the standard. 02:13.000 --> 02:21.000 It is out there everywhere in starting from automotive to home appliances. 02:21.000 --> 02:30.000 And basically, you are very likely to own at least one Yachtau project device at home. 02:30.000 --> 02:36.000 I'm just looking at this table and wondering how many of those things is. 02:37.000 --> 02:42.000 It's hard to see from outside, right? 02:42.000 --> 02:49.000 You need to look into some in this is when you open it. 02:49.000 --> 02:54.000 So not going to do it right now. 02:54.000 --> 03:02.000 All the Yachtau project sites, the Yachtau project itself, it is not a product itself. 03:02.000 --> 03:08.000 It's under the CRA, and doesn't have a manufacturer. 03:08.000 --> 03:15.000 So we could say that the Yachtau project site, we say, do not care that much, 03:15.000 --> 03:19.000 not many obligations, skip to next topic. 03:19.000 --> 03:26.000 But, uses of the Yachtau project, a project at typically manufacturers. 03:27.000 --> 03:33.000 The full full full manufacturers on this series, with the whole full compliance. 03:33.000 --> 03:40.000 And there are products that are using the Yachtau project that fall into the important 03:40.000 --> 03:42.000 or critical category. 03:42.000 --> 03:50.000 So, in addition to that, people who do work on the Yachtau project typically work 03:50.000 --> 03:52.000 for those manufacturers. 03:52.000 --> 04:01.000 So, when I do CRA talk for the Yachtau project, people usually have a full room, basically. 04:01.000 --> 04:04.000 Now, a little bit of basics about the Yachtau project. 04:04.000 --> 04:11.000 So, it's a distribution building and a basic term is a recipe. 04:11.000 --> 04:14.000 It's an instruction to build one software package. 04:14.000 --> 04:21.000 It puts the source code, puts how you are going to build it, how you are going to install it. 04:21.000 --> 04:26.000 And we have recipes, basically, to build the whole world. 04:26.000 --> 04:30.000 Recipes are grouped into something called layers. 04:30.000 --> 04:39.000 So, layers is a logical group of recipes, so you can have a layer for specific hardware. 04:39.000 --> 04:43.000 You may have layers for specific functionality. 04:43.000 --> 04:46.000 Let's say, for example, metaphorically. 04:46.000 --> 04:51.000 And now, for the embedded people, I am oversimplifying. 04:51.000 --> 04:55.000 For reason, because otherwise, I wouldn't fit it on the screen. 04:55.000 --> 05:03.000 So, a simple example of how people do use it in embedded. 05:03.000 --> 05:09.000 So, you have some official open embedded end of the project layers. 05:09.000 --> 05:17.000 You can configure them together to build the firmware you put on your device. 05:17.000 --> 05:19.000 Nice. 05:19.000 --> 05:25.000 But what happens in practice is that you, even though you want to add your own application, 05:25.000 --> 05:27.000 you want to change a few things. 05:27.000 --> 05:33.000 So, you create one layer where you add a new recipe for your application. 05:33.000 --> 05:39.000 And, but that package that is in the standard layer, that's good, 05:39.000 --> 05:43.000 but I need to enable one more option. 05:43.000 --> 05:46.000 So, you do a modification. 05:46.000 --> 05:51.000 There is a way to modify recipes that come from other layers in your own layer. 05:51.000 --> 05:58.000 And then, it's not, it's getting, the path is getting longer. 05:58.000 --> 06:05.000 So, getting more layers, because there are layers for your old product, 06:05.000 --> 06:10.000 but you are using a chip from vendor X, that vendor is providing. 06:10.000 --> 06:19.000 They only with their own fixes and add the, you end up with like 25 layers. 06:19.000 --> 06:27.000 And like 10 of them are modifying, or if you are like 10 of them are modifying the device recipes. 06:27.000 --> 06:38.000 And they are not just enabling some configuration options there, adding patches to the code. 06:38.000 --> 06:45.000 We start seeing dragon heads showing up, right? 06:45.000 --> 06:48.000 And so, how does it recipe look like? 06:48.000 --> 06:54.000 That is this one that's a real monster, and for demonstration purposes, 06:54.000 --> 07:00.000 it's a real recipe of the group, but look at that, so, but look at that, as you know, 07:00.000 --> 07:10.000 if it were a product, it's, on the important list of the series, but it's an unprecedented project. 07:10.000 --> 07:22.000 So, what we have here, we can notice that we have the download location, it's in the first thing in the SSURI. 07:22.000 --> 07:26.000 We also have CV products, so we change them. 07:26.000 --> 07:32.000 We notify what is the product name for vulnerability checking. 07:32.000 --> 07:40.000 And you can see a nice list of those CVs, something, those are patches for all those CVs. 07:40.000 --> 07:51.000 So, this is extreme example, but that's how recipes tend to end up after five years of maintenance. 07:51.000 --> 07:59.000 So, so, what that, it was, that's the yukta project already do for the SURI compliance. 07:59.000 --> 08:06.000 So, we have as one generation, and no matter how complex your layer configuration ends up, 08:06.000 --> 08:09.000 you can generate this as one for that. 08:09.000 --> 08:19.000 It's pretty much detailed build time, as one that can become gigantic if you're unable to manage it. 08:19.000 --> 08:33.000 It is in the current main branch, it's the SPDX3, you can switch to SPDX2, which SPDX2 is the current, 08:33.000 --> 08:37.000 as it does default, that's going to change in the next one. 08:37.000 --> 08:40.000 You have also all provenance information. 08:40.000 --> 08:43.000 As you have all download locations, 08:43.000 --> 08:51.000 normally you have you are tracing all places you download your software from, 08:51.000 --> 08:57.000 you know which patches have been applied, except for really crazy things that you can do, 08:57.000 --> 09:02.000 because crazy things we can always do, you know what you have got. 09:02.000 --> 09:11.000 We also now have non-vonabity checking, so that's also integrated working with any layers. 09:11.000 --> 09:15.000 Set up with annotations that we have seen in the recipe, 09:15.000 --> 09:20.000 and there are quite many security tools that are packaged. 09:20.000 --> 09:24.000 There are the recipes and layers for those things. 09:24.000 --> 09:34.000 Including security tools, even you can be the appliance with an interaction system if you wish. 09:34.000 --> 09:38.000 On the process site, what do we have? 09:38.000 --> 09:44.000 We have a long time support versions, support for security fixes, 09:44.000 --> 09:48.000 and the process of accepting or not, 09:48.000 --> 09:52.000 affix in the LTSries. 09:52.000 --> 09:58.000 So that's good with the four years LTS, 09:58.000 --> 10:05.000 not being enough for most embedded products, 10:05.000 --> 10:13.000 which is already one thing under discussion, 10:13.000 --> 10:19.000 but an open subject, then we have testing, 10:19.000 --> 10:25.000 and pretty interesting testing because on multiple architectures, 10:25.000 --> 10:33.000 and history shows that the testing is frequently showing issues in upstream, 10:33.000 --> 10:38.000 that the project has a lot of experience 10:38.000 --> 10:44.000 explained to many upstream maintainers that something broke on some. 10:44.000 --> 10:47.000 Specific configuration, 10:47.000 --> 10:52.000 with specific elliptic and specific specific, 10:52.000 --> 10:55.000 so that they fix it. 10:55.000 --> 11:01.000 We also have a vulnerability reporting and management processes, 11:01.000 --> 11:04.000 so there's a security team, 11:04.000 --> 11:13.000 and there are ways to manage security fixes by those tagging inside patches. 11:13.000 --> 11:18.000 So here probably we are doing way better than people 11:18.000 --> 11:21.000 by building their stuff from scratch. 11:21.000 --> 11:24.000 Those two think is of course not perfect, 11:24.000 --> 11:28.000 but it is working pretty good. 11:29.000 --> 11:33.000 For some cases of aesthetics we see my talk tomorrow, 11:33.000 --> 11:35.000 nine foot. 11:35.000 --> 11:38.000 Now about the challenges. 11:38.000 --> 11:41.000 So the first dragon, 11:41.000 --> 11:46.000 the first dragon we have already seen here, 11:46.000 --> 11:48.000 you have a recipe, 11:48.000 --> 11:53.000 that has been modified, that is the upstream, 11:53.000 --> 12:03.000 and then you have a vendor applying a patch to this code, 12:03.000 --> 12:06.000 that they wrote. 12:06.000 --> 12:11.000 And even a complicated case, they took a patch set 12:11.000 --> 12:13.000 from one of the vendors, 12:13.000 --> 12:16.000 and they applied that in addition. 12:16.000 --> 12:18.000 The question is then, 12:18.000 --> 12:25.000 how do you call that package A in this case? 12:25.000 --> 12:31.000 Is it A or is it something else? 12:31.000 --> 12:36.000 Taking to account that people are really creative, 12:36.000 --> 12:41.000 and those few patches that may be worth of two releases. 12:42.000 --> 12:46.000 So the current situation we have, 12:46.000 --> 12:49.000 is that if a package has a lot of patches, 12:49.000 --> 12:51.000 it is still called the same package. 12:51.000 --> 12:58.000 Even if it doesn't even look any more like the same one. 12:58.000 --> 13:00.000 And as a consequence, 13:00.000 --> 13:06.000 you need to tag all the security annotations by hand. 13:06.000 --> 13:09.000 What becomes a little bit complex, 13:09.000 --> 13:15.000 if you are, I wonder you have 100 patches over the so-3. 13:15.000 --> 13:24.000 Some people would say yes, upstream, that stuff. 13:24.000 --> 13:27.000 Yes, I would say try to upstream that stuff. 13:27.000 --> 13:34.000 The problem being frequently that people want to ship their device 13:34.000 --> 13:38.000 and their upstreaming is down the discussion. 13:38.000 --> 13:41.000 And it won't be in the ideas they want to have in the product. 13:41.000 --> 13:48.000 So there will be upstream but two project versions later. 13:48.000 --> 13:52.000 So that's one problem that there is. 13:52.000 --> 13:59.000 And honestly, the only solution I see to that stuff is to do an analysis 13:59.000 --> 14:04.000 of so-called trees and find out the number. 14:04.000 --> 14:09.000 And do the complete graph analysis and find out what we actually have. 14:09.000 --> 14:13.000 The second, the second subject, 14:13.000 --> 14:15.000 secured by default configuration. 14:15.000 --> 14:20.000 So the current policy is to minimize the changes from upstream. 14:20.000 --> 14:31.000 What I run into frequently is that I added a configuration and it turns out that the upstream project 14:31.000 --> 14:36.000 is actually unsafe by default. 14:36.000 --> 14:42.000 So what do you do then? 14:42.000 --> 14:51.000 Many cases, you just want to apply changes and to do that secure by default. 14:51.000 --> 14:58.000 This is complicated to do at scale for hundreds of packages. 14:58.000 --> 15:07.000 Then we have the fact that the October project is completely configurable. 15:07.000 --> 15:19.000 So with the same tree, you may be building a default and you may be building an appliance. 15:19.000 --> 15:26.000 So it's very hard to put to come with one set of standards. 15:26.000 --> 15:32.000 And one configuration for people to agree on. 15:32.000 --> 15:38.000 And then, historically, they are vendors shipping their own layers for the October project. 15:38.000 --> 15:41.000 They own hardening changes. 15:41.000 --> 15:45.000 That, of course, completely incompatible one another. 15:46.000 --> 15:49.000 Change number three. 15:49.000 --> 15:57.000 For many important and mandatory solutions under the series, 15:57.000 --> 16:00.000 like their systems. 16:00.000 --> 16:04.000 There's no default that is provided inside the app. 16:04.000 --> 16:11.000 The project, because outside there are multiple solutions that exist. 16:11.000 --> 16:16.000 So you have, as a vendor, you have multiple ways to integrate it. 16:16.000 --> 16:26.000 Oh, and it's on the manufacturers played to correctly and securely integrate their important components. 16:26.000 --> 16:34.000 And that makes writing a nice complete risk analysis really hard. 16:34.000 --> 16:40.000 Without asking, well, this is the second volume of the risk analysis. 16:41.000 --> 16:48.000 Then, in the embedded, we have vendors that are literally years behind upstream. 16:48.000 --> 16:51.000 And yes, it's not one year. 16:51.000 --> 17:04.000 It's like, and we have people who stack on vendors software that is years behind upstream. 17:05.000 --> 17:11.000 As a consequence, there's no ideas whatsoever to give them security updates, 17:11.000 --> 17:17.000 so they are backporting on not fixes. 17:17.000 --> 17:25.000 And so if the project makes an important change for the security functionality, 17:25.000 --> 17:33.000 it may turn out that it will ship on devices five years later, actually. 17:33.000 --> 17:37.000 If I, yes, I'm really nice at that. 17:37.000 --> 17:48.000 So it is slowly changing for, for this year, the vendors getting more and more close to upstream, 17:48.000 --> 17:53.000 but for the embedded world December 27 is basically tomorrow, 17:53.000 --> 17:57.000 because the devices are already being designed. 17:57.000 --> 18:02.000 So to wrap up, in the embedded, it's really uneven. 18:02.000 --> 18:05.000 I think that they're working well. 18:05.000 --> 18:10.000 I like basically the as-mom metadata. 18:10.000 --> 18:13.000 And it's really uneven from one vendor. 18:13.000 --> 18:16.000 One chip vendor, another example. 18:16.000 --> 18:23.000 And what requires work is that we have a years and years of fragmentation of security solutions, 18:23.000 --> 18:28.000 so many vendors have their own stuff, and do not want to show it away. 18:28.000 --> 18:32.000 Security default, it's a really complex problem to solve, 18:32.000 --> 18:38.000 because actually it's requiring not security default. 18:38.000 --> 18:44.000 And we have hardware diversity, a big example of that being secured, 18:44.000 --> 18:53.000 that on the most popular and the platform was a per-cheap specific solution 18:53.000 --> 18:57.000 until not long time ago. 18:57.000 --> 19:02.000 But we are advancing on the positive side. 19:02.000 --> 19:04.000 So, thank you. 19:04.000 --> 19:07.000 I guess we do not have time for questions, right? 19:07.000 --> 19:11.000 Actually, actually we do have time. 19:11.000 --> 19:14.000 We do have time for one question. 19:14.000 --> 19:18.000 Who's the great person ask one question? 19:18.000 --> 19:22.000 And the next speaker, can you make yourself visible to us? 19:22.000 --> 19:23.000 Thank you. 19:27.000 --> 19:42.000 Please sit down for a second. 19:42.000 --> 19:48.000 Thank you for that matter. 19:48.000 --> 19:53.000 I'll try to be quick. 19:53.000 --> 19:57.000 We manufacture OEM devices in the embedded space. 19:57.000 --> 20:02.000 I'm understanding that our customers would be the manufacturer under the CRA, 20:02.000 --> 20:08.000 and it's their responsibility for all of the software components that they receive within 20:08.000 --> 20:10.000 Yopto and elsewhere. 20:10.000 --> 20:13.000 And I'm trying to understand attestation. 20:13.000 --> 20:18.000 How do they ensure that each of the components is safe and review those? 20:18.000 --> 20:21.000 And when they're not, what do they do? 20:21.000 --> 20:23.000 How do they remove those components? 20:23.000 --> 20:27.000 Or what are the solutions that they will have to be compliant, 20:27.000 --> 20:30.000 given that that's their responsibility? 20:30.000 --> 20:33.000 So, the question, if I understood it correctly, 20:33.000 --> 20:38.000 was how do those embedded vendors that are using Yopto project? 20:38.000 --> 20:43.000 I showed that the components they use are secure. 20:43.000 --> 20:53.000 Do you want the Honest answer? 20:53.000 --> 20:58.000 The Honest answer is that they trust that they have been correctly integrating to the 20:59.000 --> 21:02.000 Honest answer? 21:02.000 --> 21:11.000 And, but as they, especially the bigger of them are getting scared by the 21:11.000 --> 21:22.000 final part of the CRA, they are starting into looking how to analyze that 21:22.000 --> 21:23.000 by of data. 21:23.000 --> 21:30.000 But embedded people know already for a long time ago that they do not have 21:30.000 --> 21:32.000 10 dependencies. 21:32.000 --> 21:37.000 They have more like a thousand. 21:37.000 --> 21:44.000 And analyzing thousand dependencies manually for secure configuration 21:44.000 --> 21:49.000 that's not one evening task we can say. 21:50.000 --> 21:51.000 That is true. 21:51.000 --> 21:52.000 It's all complicated. 21:52.000 --> 21:53.000 Thanks very much. 21:53.000 --> 21:54.000 My hand from applause.