The Yocto Project is a community-driven embedded Linux development framework that prioritizes mainline Linux kernel integration over vendor-specific solutions. Unlike traditional BSP (Board Support Package) approaches that rely on proprietary vendor kernels, Yocto encourages contributors to upstream their work to the mainline Linux kernel, enabling long-term maintainability, security updates, and community collaboration. The project accepts vendor code recipes as long as they help progress toward mainline support, and uses GitHub issues and pull requests for community communication rather than traditional mailing lists. Key practices include using the deploy class for artifact management, understanding task signatures for build consistency, and leveraging tools like Yocto Check Layer to ensure layer compatibility. This approach ensures that embedded systems can receive continuous security patches and benefit from the broader Linux ecosystem.
Yocto Project Workshop at Embedded Recipes 2026 - LivestreamAdded:
whatever that have like one SOC at the same time. We have multiple ones. So that's a challenge. Another big challenge is that there's no mailing list. There's just GitHub uh with issues and um pull requests. So that's one way to communicate. That was a bit surprising at the at the beginning for me. Um another difference too is that we're open to accepting recipes for for downstream software like decoder and and firmware. It's um it's like super different from meta rock chip for example. I tried to contribute one board. The first one got accepted because it was in the mainline kernel but uh they didn't accept my second patch because the board was in the mainline kernel but not supported by Linuxto. So they didn't want to have like yet another dependency like to meta mainline metal mainline from port. So they they're like super clean layer super well supported. Here we are more in another another mindset. We want to make things progress. We want to to reach greater adoption. So we we're fine if we accept like code like vendor code recipes for building vendor code as long as it helps us to to make progress in the mainline direction. Right? So it's good like for example to be be able to have a bootloader to boot your experimental kernel on. That's the the strategy. Some go some boards are getting unmaintained. So we need we need help from you guys. Also there's need for code consolidation like for example for the Uboot VB app and we have like lots of boards that have this very similar code. Uh I guess we can like find better solutions to have like to avoid code the application. So there's yeah there's a lot since we are like not super clean we need some people to consolidate and contribute to like cleaning up recipes. Um another thing is that I'm not I don't think it's used in production projects. maybe came your you correct me. Um uh because I see that LTS branches are not maintained yet but hopefully with right now it's an opportunity to start a new one that we will if we have enough resources and the resources are here could be here uh we could maybe maintain a stable branch.
Um, another thing, so that one thing I learned was like the sock family variable. It's nice like when you have multiple machines of the same type, it's good actually to define to of course to share your definitions between machines that everybody would do that of course like a common include like k1.inc.
No big no big deal. But here it's also nice to to know about the sock family variable because it acts as a machine identifier. So it's part of machine overrides. It also and it's also can be used in the comp compatible machine statement that says this recipe should be considered only for that for that machine or for that sock family. So that's great to have this because acts as a machine in the overrides you don't have like to have like multiple lines with this with different machines for the same the same type of overrides. So machine sub family is a nice one that I discovered while contributing to this to this layer.
Another thing I I learned was like the deploy class deploy class I thought it would automatically define the deploy task and at least in the list of tasks not define the contents maybe but like adding it it's not the case so deployed class is mainly for automatically copying files from deployed here in your recipe to that's that's like recipe specific to deploy the image which is like global that's where all the artifacts get published right um so uh one important thing is Please don't deploy to uh deploy the image otherwise it will slap you in the face because I mean sometimes things build fine and uh when you when somebody else build builds it it doesn't build or and it actually breaks the state cache if you directly deploy to deploy the image because I mean the state cache cannot track uh at least easily global artifacts. So here um the the recommendation is to have like a a deploy task that looks like this that deploys to deploy here. And if you inherit uh the the deploy class automatically that will be copied to um deploy the image and you have like the estate cache working fine. So if you have like bizarre things sometimes some some some artifacts that are missing it's because you're messing up with the the state cache in in some way.
So I I had like a few weird issues to investigate because I was doing things in the wrong way.
Um I also learned like a nice trick when uh I was contributing to K1. We didn't have MMC support initially neither in the boot in the main line boot and neither in the Linux kernel. So this is being addressed but at that time was useful to actually what I saw is that the first input loader like the vendor one the downstream one had support for MMC for so it was actually loading um the Uboot and and other artifacts in through the fit image in that fit image you had booti and you boot that's I was talking about thanks for being here so If you have this problem like you want to boot mainline you boot but mainland boot doesn't support MMC yet what you can do is actually put the Linux kernel in the shade image together with it DTB and if you have like no support for networking you could like for doing NFS booting you could even put an infra to boot to boot mainline mainline you boot and mainline Linux without having to load the kernel from you boot you load it from the upper stages so that's nice so now fortunately we We have a great contributor who's called EAP Rosa who working for Red Hat who really pain painstakingly uh implemented MMC support like tweaked the existing MMC driver to support SD card support uh in K1 boards. It's going to be available in 7.2. So it's really being merged as we speak.
So in case just just some reference if in case you have a board with like any kind of board like that you take the vendor image like the vendor Debian or whatever and you want to to put the to put the the main line kernel inside instead of using the vendor kernel which is crap what you can do is in case you have like a fit image to decapsulate it like remove the vendor the vendor code from it it's fairly easy you dump it to source code it format and then you edit the uh the file manually you replace the the the binary sections with like an in bin for for your the the binaries that you will make. They're super easy to make and then you can just copy the artifacts to your directory and run mk image again.
Um I'm doing that like all the time because it's very convenient to to start working off on a existing image even without having to rebuild it. So that's like for everyone. um on the YTO side if you want to to build from from this. I actually actually created a recipe um that's called boot bundle that just exact that does exactly this. So it's it's given a fit image source file.
You just deploy some artifacts that were built before like you boot like the kernel and you you you you run MK image on with those with the template and those artifacts and this creates a an image of your choice. Well, obviously this is really uh image dependent because I mean board dependent because it still hardcodes the addresses of the kernel and device trees, but you could make one for each SOC if you want. So don't hesitate to red to reuse it.
U also to create config fragments which is something you do all the time when you maintain a BSP layer, right? There's a super super nice trick to I mean I was creating them manually the hard way like okay which ones which settings I need and write them manually in a fight but I was sometimes opening menu config and figuring out which which ones I need.
But there's a there's a better way. You can run bitb minus c menu config and the recipe like kernel or uboot or software update or whatever.
uh you save the changes and you run bit bake minus cd defconig and this generates the the differences like the config file cfg file that you can put directly in your recipe. So that's super convenient and I'm grateful to navin ready uh for sharing this tip with me.
He was there at fdom.
Uh, a convenient cast feature with a K, of course, but it may have happened to you like when you're working on a on an experimental layer and you're using Casp. I love Casp. Um, you of course you want to to to use your experiment your your layer in development. Uh so you you would typically put the the path to your layer in the cast file like path to my layer.
But when you publish the changes to your layer uh well of course it you should be using the URL of the the layer in like in whatever repository is published that's annoying because you skip swapping between local version and public version. What you can do actually is what metaris 5 is doing that's great is just using using repos metaris 5 and um I don't know exactly the how the magic works but when you when you do is like cast build with the path to the to the layer where the the the yl file is automatically it picks it it picks up this this layer here so it knows it's the local one that's being used for versus like the yl file I guess. So super convenient. You don't have to to tweak the the the cast file for your board. I mean for the for the layer at least uh all the time and now we have opportunities to contribute. Um that's how I need a bit of help. So we have like lots of attractive boards, right? So the spacemate ones um like orange pie ones that I have. So, Orange Pie RV2, thanks R for letting me know about it last year. So, I I got mine. Last year it was cheaper.
Uh like I bought bought mine. It was 60 uh like 54 8 gigabytes. Now it's like €8 for 4 GB. That's frustrating. For this one, the Orange Pi R2S I like really like it because it has like two 2.5 GB Ethernet ports and be behind PCI. So, it's really great as a small switch like with four Ethernet ports. U yeah, I bought it. I bought mine for 32 euros for the two two gigabyte version and now it's like 65. So, u there's big five fire from the big uh big board foundation. It's uh actually very popular for space applications.
So, it's not supported by metaris 5 yet.
It has like you you need to use the microchip layers which are a bit a bit confusing, but I'm working on like bringing up bringing it into rental risk file so that we don't depend on on on the microchip layers anymore. So, it has an FPGA together with the the SOC. So, it's like quite attractive. There's Mango Pie. It's pink, right? That's why. Oh, yeah. Oh, yeah.
Of course. Oh, yeah. And I I didn't mention, but one of my slides was pink as well. like to get your attention.
>> I was putting you into the internet.
>> Good.
Uh so there's also the mil 5 do one I have and we are in the process of streaming it as well in the mail kernel.
It's nine nice because it's 9 and it's fun because you you actually uh either can boot it in ARM mode or in risk five mode. I mean you have like two different there's a risk 5 core and an arm core that share the same devices. You can either choose one or the other and it's both are supported in the mainline kernel which I mean there are patches that are that are being reviewed and accepted. And the next one that's on my way to my mailbox hopefully it's like this IP banana pie k3com 260 which is like the the first one of the first space K3 board. So that's the the the system I told you about with the RVA 23 profile. I'm really eager to get it, but it's like a bit um slow. It's bit It's out of stock. So, uh I is helping me to he knows the manufacturer, so he's helping me to to put my request at the top of the of the of the queue. Hope hopefully that will work. So, if you need some contacts in China, uh we have one now. So, that's nice. So, yeah, another thing you can do is learn about race. So this gentleman here is really you see he's smiling because he discovers this new architecture.
Uh what you can do is help with upstreaming. So I'm here I'm talking about the mainline kernel. I'm talking about the Linux kernel. U sorry and you boot I mean without mainline Linux uh things are not fun right there's no value in having a board that has no updates no security. So we the the the primary goal is and YTO is also here for that to help with that is to to be able to build and and and implement a kernel that main kernel that will support our hardware. So and um and another reason too is that Linux is the reference for the device resources that Uboot will use that other projects will use. So it's I mean Linux should be first and it will make YTO contributions of course much easier because then Linux YTO will pick them up if they are mainline and all those all the work we're doing on YTO will be usable thanks to having a mainline kernel. So to do that you can subscribe to the Linux race 5 mailing list and see what's going on. Use the B4 tool to help you managing your patches and your submissions. It's really really helpful uh compared to do doing the things manually.
And um from my experience, it's easier to uh to submit new code right after an RC1 of the Linux kernel because you don't have like to figure out like some code has already been pushed to maintain the repositories and you depend on those right after an RC1 is made. It's like everything is clean. You don't have like the maintainers haven't been starting filling up their their their pipes yet.
So that's the that's the best way the the way you have the clearest picture here. You you what people have is like RC1. this the common ground to everyone at the moment. For example, it's a bit more tricky because there some some B support has been offered but I mean that depends on the MMC series and on the DT series which are different trees. It's a bit more complicated. Of course, you could also contribute to the mainland bootloader uh like um supporting more in Uboot. So that's we can still work we can still do with the vendor kernel the vendor bootloader but it's not receiving any updates and like you could port MMC the MC driver from Linux to Uboot that would be a nice contribution a most welcome contribution uh other things that's worth supporting is of course open SBI which is the firmware and also supporting to DRM training obviously apparently um all the the risk five boards have like some DM training at the beginning on the the very first stage bootloaders um more than an arm it's more visible it seems so that that's where we need some contributions and some people have already started working on that on that uh more ways you can help of course you find new balls make them work not so not so complicated and we're really glad to help uh another thing you you can do uh is review contributions from others I mean sometimes I'm too focused on my own work but I'm always very glad when people review my submissions so of course it works when there's there are people reviewing your work. So it's good to take some time to review work from others and you will learn from that anyway. Uh you can build some some images and you will find ideas for making things better for sure because like seeing how the the build goes or whatever it gives you ideas just by doing um you could also create a new semiconductor semiconductor company to reduce the DRAM prices that would be much appreciated.
So where we needed help in the layer is like uh you could also use update and refactor existing recipes uh replace the vendor code the vendor code by like code that's that's building mainline instead.
You could also help with CI testing like Trevor Gambling from Bay Libé is is like developing some infrastructure to to to have like more systematic testing of our boards because sometimes before the some some boards broke and nobody realized until they they tried to build it. And also it would be nice if we could maintain an LTS branch with rhinos.
Uh another thing I I I would need some help with like we don't have much time but um it's like uh I was for for for spacem K1 we are generating an image with wick right so that's all the partitions but I didn't find any easy way to put like the bootstrap code at the very beginning of the image like the very first bites I mean even with wick it wants to be like some sector that's not very at the very beginning so um I tried many options none of them worked um of course I could write a wick plugin that does what the the code that's flashing the MBR on on x86 does like writing something at the very beginning but maybe hopefully there's an easier option than to create a plug-in for wick just for that very specific purpose so if there are any wick experts we can talk about that please please come sorry the time is limited for interacting right now but hopefully we'll have five minutes for questions so that's the checklist for adding support for a new board in metaris 5 or in any layer Don't forget to add your board to read.md.
I think that's a kind of requirement at least for us.
Uh and if you contribute to metaris 5, you don't really have so you have to go to submit a p request. You don't really have to run met your check layer because rci will do it for you. But you of course you can it's easier but you don't have to. So run patch test of course that will that will spot like some issues in your patches like um like forgetting to to add the upstream status if you have some patches in in your changes.
Yeah. So some use useful resources uh for for for this topic u I I made some presentations at first this year like how to add support for new boards in the Linux kernel. So that could help like if you want to know have more background to support new board. Um, also something more specific to RIT 5 was the orange pie uh risk five support and you also have once again the the free lectures I'm sharing on on my website.
So as a as a summary uh metaris 5 is a pure community project not driven by risk 5 not driven by rice which is part of the Linux foundation.
It's it's still a small community with lots of room for new I mean for new people, right?
Um so yeah, that would be nice. Your patches don't have to be perfect.
Let me help uh you help us, right? So as soon as as long as we're going in the right direction, right, we we can we want to get started and other contributors can that's an opportunity for other contributors to join in and help us simplify the code and make progress towards like having something clean and more uh mainline supported at the end.
Yeah. So that's it. Thanks for your attention. Um we maybe have five minutes for questions and discussions hopefully.
So maybe we could have like Cam, Drew, and Nishin uh say something. Cam, maybe you have something because you're the maintainer. So please, >> so yeah, I think for um mailing list you mentioned. So we do have a discussion forum on GitHub. So everybody is welcome. you can add discussion topics and you know we like to discuss it on GitHub um forum I like it that way because you know all the forums can be invoked at any time so >> so there's a forum >> there's a forum >> okay so >> is that like on uh this course >> I guess okay >> okay good to know there's a forum on but we also have a forum on this course uh from open embedded Yes, I have a maybe a comment from your slide 22. You are asking to to contribute to the Linux kernel for giving more support for boards. Why um volunteer needs to do it and not the silicon vendor that they are interested in selling their chips? Shouldn't we put pressure as a community that the chips should be upstreaming fair so anyone can use it instead of these companies relying on someone else's work unpaid to do it so yeah that's a good point I hope the ris the the SOC vendors see this obviously uh on the spacem side it's not that bad maybe you want to say something like do you get funding from spacem >> um I I would agree that in a in a ideally way that uh vendor s especially so vendor should uh uh contribute to open source directory but uh yeah realistic way there's a lot problem behind so they they either uh have no uh human um human resources even uh they have um tight budget many many many reasons so uh as my experience when I contribute to space meter at the first generation the K1 generation there's no funding or barely support from the from vendor and and since I since I work uh since my my employee kind of open so I can contribute even at my daily time. So yeah but uh but situation a little bit improved in case three way that vendor realized it's important it's important but they still have title resources I mean human resources and the budget but they they um funding funding me I'm currently work as a inter independent developer for space meter since improve improved a little bit but not still not reach the ideal way so space meter do give certain support yeah they they are willing to support you. Yeah, thank you.
>> So, things are getting better. Maybe you have a take on it, Drew.
>> I actually have a question. Um, for board vendors, is it preferred for them to add their boards to Meta Risk 5 or should they just have their own? Should they just do things on their own and not not add it?
Is it like a benefit to for Meta 5 for the board vendors to add it or would you rather them do their own thing?
>> Sci-fi is an example of it not going well.
>> So sci-fi's layer is not particularly useful at the moment because it's out of date and at least Meta Risk 5 the community folks are a lot more easily worked with I guess is the way to put it. Um, so although it's funny because to my great surprise, Meta Sci-Fi added a Rhinos branch even though they haven't added support for their newest boards in yet. Um, so I don't know what's going on there, but um because like the 550s, there's a dev branch that's been sitting there for a year, but they haven't merged as support whereas I mean I know who to complain to for rent five is for that kind of stuff.
So >> thanks Scott. What's your take on it?
>> Yeah, just like I think it's a good litmos test as well because we prefer upstream. So you can do a lot of stuff in downstream in your own layers and offer to people and kind of a lot of times you diverge. Many times you even don't notice but in upstream we make sure that you know people are bumping kernels if something doesn't work. So you know you get like that upstream uh support and and that um community. So we we do support like vendor code to begin with but then eventually you might have seen we have like Linux make line mainline recipe and we start as the support lands upstream we prefer to enable mainline kernel mainline you you know open SBI so I think uh it's better way for them to maintain and we now have a deprecated MD so if you don't update our BSP after a while we put it in deprecated because we can't support it anymore so Okay, thanks everyone. Um, I'm running out of time. Uh, but, uh, you know who we are and who how to reach us, right?
Thank you.
This is Chinese.
No.
I'm grateful.
Okay, >> to the back. We I cranked up the speakers a bit.
The problem. So, this is to all future people who will try to communicate with you. Microphones to do usually work pretty well as long as you're speaking into them. And when you're pointing at things with them, well, then it looks really funny, but nobody understands what you're saying. Okay. So once you're presenting, please try to use a microphone as intended. You can use it in ways after your presentation. Thank you.
This is an original building.
foreign 24.
It's >> okay.
I don't have a I have your signal.
I don't need >> Yeah.
>> Because I do have signal. Everything is here. Just the The resolution isn't using >> Hey, it's working. Uh, can you hear me?
>> Yes.
>> Okay, great. So, uh, luckily we got the technical program uh, problem fixed.
Thank you Yseph. Happy to be here with you and present give a talk about my new project metas pi secure. It's add-on layer on the top of metas pi um to provide a security baseline for a pie 45 and its derivatives.
No use it.
I don't know what you're doing.
>> Oh, yeah.
>> I think it just I use the mouse. It's better.
>> Sorry.
>> Okay. Uh, no problem. So, um, here's a G repository.
>> Yes, thank you. Um, there's a link for GitHub repository. It's uh under MIT license.
Um just few words about me before we start. Uh so my name is Aayubzaki. Um I have a consulting business embedetric that provide embedded Linux uh Yokto and embedded security services. I'm based in the near stutkat in southwest of Germany.
So just a quick disclaimer before we start. Um I have no insider information nor work with Raspberry Pi company and all information uh was gathered from official documentation, GitHub issues and sadly I have sacrificed some few devices burned um so um and I learned from it and how not to do that again and uh insist on this this layer is a security baseline and not a finish secure products.
So I propose the following agenda um bottom uh top approach. So I will start how to build um a root of the trust and extend the secure boot chains from uh to Linux and to user space. Um we talk about how to leverage the secure storage for encryption and few techniques for system hardening and I highlight also the AB uh trib boot approach native um update mechanism in Raspberry Pi and last but not least some point about Syria readiness and compliance.
So as you may know the Raspberry Pi is uh one of most popular um um SPCs out there but it's also used in wide range of um products actually through its uh compact models. So from autonomous vehicle to from automation industry point of sales smart home and so on. And since security is not anymore uh optional. So since the Pi 4B models um they started shipping some hardware security. Um so quite decent I would say and we can leverage this to build a secure platform.
So a security uh platform required a solid foundation. Um so solid foundation is to anchor a root of trust by leveraging secure boot. So how it works um on the Raspberry Pi. So we have uh it's similar to other uh SOC's. So we have a boot ROM code that um based on OTP um public key hashes if they are fused they will verify the next bootloader. They loaded on Raspberry Pi is loaded from SPI ROM and the bootloader for SPI boot ROM uh will load if secure boot enabled from FAT partition. Not all the artifacts as you may know but they are um contained in a boot image. So we have a kind of nested fat container inside the boot partition and beside it uh it will check a boot signature. So it's not attached and it contains should contains Arisa signature and from boot partition if the signature is verified uh it will start so GPU um firmware and also start Linux kernel and from Linux kernel attached with uh inits it will unlock the encrypted storage verify the next boot stage with the inverity for example and start the applications.
Um just to note that the Pi 4 is a little bit different just different but um how to sign it is quite similar.
So how to do secure boot signing or signing. So I leveraged the um the SD card image BB class from Metaraspi. I rework it a little bit and created air piccoo BB class. So basically um having a signing key. So right now it it supports only RSA 248 bit um keys actually and from the boot artifacts it's uh compact them all together in a boot image and assign um give a signature and um yeah it can be used with wick for example plug-in to to put it on the right partition.
uh beside the boot image also uh have to ship a secure um aprom binary it should be also signed um it's also be generated by BBclass and if the OTPs are not burned we can recover from a secure boot state to a non-secure boot state again so it just start again as you may use it as usual um to burn the OTPs there some variable that have be to be set. So I explicitly do not set them anywhere nor burn any OTPs in the in the layer. So so that not people get angry and lost because if you lost your keys then you cannot recover anymore your hardware.
So how it looks the boot configuration a prompt configuration. So to ship the um sec boot state uh we have to specify inside the amprom configuration silent boot variable we can enable or disable uh the bootart and we will see the partition walk uh setup is also important for auto updates um the the signatures has um yeah it's human readable uh so we have um the sha in hex format we have a time stamp in Unix format And there is a signature um hex also.
So from secure boot um so we have re verified the boot image uh we can start the kernel plus inits and from that we can uh verify the root file system using the inverity. I used different uh workflow as the one provided by meta security actually that ship the root hash inside the init.
I don't like it that much because it brings a dependency between the init build and root file system and for development for example you have to ship always both. So um I you use it the concept of use in Android phones. So it's called AVP. It's Android verified boot. So basically I attach the file system uh I attach the hash tree the inverted mercury tree to the file system and from it there's verified uh boot metadata. It can be signed using RSI or uh PQC signature also. And uh we ship I ship at the end a footer. So basically have a small utility that use the lip AVB and then check um at the end of the partition is a footer is located there.
If it's not then we start with um uh checking the file system um type and I support only um x4, x2, x3 and aeros and squash fs and based on the size of y system it will jump uh at the limit and start looking for a footer and then parse meta uh vb meta extract the root hash. Um in the VB meta I can pack also a root hash signature and I inject it via um system call to the kernel uh to keyl and I enforce also the kernel to verify uh the root hash signature. So I like to have u time if of check is time to use so we can avoid any toku um injection. Yeah that's it from day inverity. I have uh created a new uh project for that is metabb. It's basically working for is and platform independent and working in every almost every board you can use it.
So beyond the the root file system is is read only u there are data partition. So basically we have to find a way also to uh verify check um the integrity of those files. So we don't have sadly so much option in embedded Linux to do that. There's uh DM integrity but it's really have very bad performance.
Um I use for that IMA EVM. It's long time a Linux kernel sadly not that much used on embedded system but we can extend a little bit uh the integrity to uh data readrite partitions. So basically um I check all the binaries um exxs um the shared libraries I can check also the firmware I can also check the kernel model and policy itself of course um and this you can notice it's from all the file systems for example you have um um vulnerability or uh binary that not signed from tmpfs it will be uh stopped I tried with the the new dirty flags and uh those new um vulnerability looks kernel but if they are not signed they will not run actually from uh the read and write um data so we cannot sign it um using our private key there's also possibility to use an ashmech um symmetric keys and basically generate a hash from um secure storage we will check it later on and appraise on read u all the files that were modified. So basically can detect um offline manipulation. Of course, EMAVM has some limitation as it cannot detect um directory uh manipulation uh no roll back and uh file name also cannot be detected in file name change. So this is just I would say it's not secure boot extension per se but it's um runtime protection.
So from secure boot to secure storage we have to find a way to store our keys and secrets inside the box.
So um the Raspberry Pi from uh 4B they provide in the video core firmware a way to generate one single um electric curve key and we can we have a mailbox IP from Linux to basically provision a key sign with it or uh generate um make a derivation through ashmech. Um yeah I created a project um so basically it's small it's it's make this key as a small highm I can even use it in opensl and yeah I have a demo in the rasp in the in the layer to um showcase for example self-signed certificate based on this key and uh do a TLS connection actually.
So from secure um from from the signing keys also need some kind of encryption.
Uh as I uh before we can do ashmech derivation. Uh I created a new um trusted key in the kernel have a patch in the layer and this trusted key basically I can through the ashmech seal and and seal a key blob and I can generate a trusted key and use it for um file system encryption and also um so so I can use a master key kind of trusted key from it derive mini key as I want.
So basically I drive one for EMA for EVM actually and one for uh I use for the encrypt to encrypt the root file system.
So basically the root file system data partition um they are encrypted using device key. So basically if you um unplug the SD card put it in somewhere another Raspberry Pi will not be decrypted because it's bound to the socks.
Yeah. from secure boots uh secure storage a few techniques how we do uh system hardening like me Hercules does not skip the abs training but we don't need a six-pack for that um I have provided since you know that security work with it um for development is a little bit hard so you have a titan system you can't do much so I have created in raspberry pi uh metal layer two security profiles file for development where I enable uh serial port console uh GTA I have the EMA EVM SL Linux in permissive mode and I don't apply any uh security hardening on kernel user space and basically login per password and SS password for the production the the bootart is off Jitec OTP could be disabled but um as I said I don't burn any OTPs in the layer. So it's have a responsibility of integrator to do that. Um so EMA is enforced as a Linux not yet enforced because it depends on your application. Basically you have to uh tune Linux policy to make it work for you. And I apply a different kernel user space hardening. For SSH I use certificate authentification.
So basically um you can it's not so much wide used I've seen. So basically you can sign um clients certificates and put time limited for for example if you want to access device only few minutes 1 hour one day you can do that and then it's yeah um if you need remote access uh there is now in Rhino's new version of tail scale it has its own um SSH implementation so you can use it uh from the security profile There's things that are always on. I have a hardened FS tub. The invert is always on. So basically there's um bind mounts to the data partitions.
Kernel signing models is on firewalls and auditing.
Um so as I said before I applied a different hardening fragment for Linux kernel to uh have a memory safety kernel lockdown disable all debug unsafe feature like tracing kexec kvm div for busy box no login uh no server demons no click text clients and some um best practices for cctl runtime. time.
Um yeah, for USB I use uh USB guard demon. So basically it's um it's blocks all device. It allows only what you want to have on the system. Uh so you can define what kind of device should be plugged into your system to avoid um attacks like bad USB. So basically here you can specify the real devices or can specify a family of devices as well and everything else will be rejected.
Have also a basic uh fire rules. I just recently move it from IP tables because this was a little bit painful to have both IP 4 and IP6. So um and if table is quite handy. So basically the drop policy and have only loop back SSH with rate limiting um I ping DSCP and uh no forward policy. So basically if you want routing you should uh enable forwarding it's up to you and output only HTTPS DNS NTP and DCP to enter request.
So from hardening to EB update I just want to highlight it. So uh this Janus is not EI slop it exists actually. So it's got of transition transition from actual software to software with more feature and hopefully less bugs. Uh here's partition layout I use. So basically you have seven partition. There's a boot partition that contains um what it calls auto boot text is used it by the APROM framework to define which kind of booting device you want to have to start from. It contains also APROM update if you want to update the APROM and based on auto boot text it will start either system A or system B.
So basically you have boot a and root a in synchron from inits.
So um this is how it looks the autoboot.ext.
So basically we start from a system uh we specify that the boot partition is um the two and from there uh we set it we we update to partition B the redundant one and we start in a mode is called a try boot reboot with a parameter it's called uh zero try boot and the A prime firmware will uh start from what you have specified here for example here it will start from partition boot partition tree and I have uh I don't use any boot loader so basically boot loader is kernel inits it will check from device C which boot device is there and by the way the init fs um all implementation here it will work and depend there's no hard coding of the boot media so basically it boot from USB boot from info ma it boot from SD card it's the same nothing to modify Okay. And when the boot system the new system has reached um then you can confirm your um your running system.
So basically it will just change in auto boot text. You will swap the boot partitions if it fails. So basically if you have a hardware um um watchdog then it will just start from as normal as before. just a flag that lives only on this reboot process.
I don't have right now any update framework implemented. I have only a update script helper I wrote. So basically can it just for development purpose I plan to use one of the three um update frameworks. So basically we specify the boot image, the boot signature and the root file systems and I have a system uh DD demon that confirm after five minutes if the watchdog does not hit that the boots the the new system is okay and it can confirm it.
So last but not least CRA compliance there's some CRA readiness. So some building blocks from product security there's integrity implemented there's confidentiality there are no default credential and applying hardening to limit the attack surface and plan to have AB also updates and from varity handling I use especi branch rhinos right now supported and we can have also security monitoring I have audit logging is enabled. Basically, also we can upload the audit logs um to remote server. If you have a fleet, you can detect based on audit rules some um some attack on your system.
Yeah.
So the some conclusions um as I said these layers provide only building block for security still to have do the work remove the software that not needed um tune it tune s Linux adapt it to your requirements. I need the better documentation and look forward to upstream the kernel patch for the trusted airy foli and also I have a running auto update as an example. Yeah, that's it. Thank you very much.
>> Some question some question.
Did I get that right that you run u EVM on a DM encrypt encrypted partition?
>> Yes.
>> Okay.
>> So, just a comment, you should never use EVM on a plain text partition because it's it doesn't add any security.
>> Another question.
Can you merge pull request number five, please? Can you merge pull request number five, please?
>> Thank you. You're fast.
I have a question about those security profiles because usually when you compile the production ready firmware uh you send it to factor and in factor they told you okay but for production we need for example SSH enabled on the firmware just to do provisioning or any other factory stuff. Do you have some possibility to you know to produce the production firmware in the way that they can for example in factory do something like burning OTP after the production to disable all the you know uh not needed interfaces >> I think is up to you you can ship all in in production also not secure firmware and then do it >> then when you ship them not secure then yeah you do production you all the certificate >> then how to make the secure >> um it's it's production logistic actually I think we can talk about it I don't have solution for that it's uh customer and product specific I do have a solution uh Raspberry Pi I actually have some software for deployment in production.
>> Ah yes >> and you can use it to secure the device and uh we did some preliminary work on trying to feed a different image so that can be used.
>> Thank you for the hint. I talked with um Raspberry Pi staff engineer they also proposed that so um I need to provide a special format for a pi provisioner so it does not take weeks. to have some XML some really special format for that.
>> Okay, thank you for the hint.
>> Okay, thank you.
Yeah.
chance.
quite cheap.
>> You're doing Excuse me.
Let folks out of the room.
I feel like I need to try.
>> I know.
So sorry.
I don't think Oh my god.
There's another I hope they will This is so loud.
like my feet right here.
Oh, sitting right here. I'm going to embarrass that.
Yeah, I'm gonna embarrass.
Hold on a second.
They look a picture.
All right.
Thank you.
That's why he's missing people in questionific.
So the Q&A And I said, "Yes, I don't What did it do?
You know what?
Yes.
Now we're going to pick it out.
that email security.
Sorry.
No problem.
What we need is check on social.
I think I don't know.
Cherry So good. So you've just validated people want to see it for subversion. There is no validation.
because there's no way of solving that. The solution is 2026 but the solution to that is the poster question as to I have only private network execution.
So to be broken.
You could use But these sound Yeah.
Yeah.
No, I wasn't Yeah.
>> We have quite we have quite a few quite an arbitrary type of test. This is the thing. Yeah. But it's it's perceived to be perceived to be very strange.
All right.
Thank you guys.
Megan, >> after all >> I feel offended now.
>> First first that then you are a fortune cookie.
>> You are a fortune cookie.
Yeah, this is this is the >> right right.
Hello. Hello.
>> Hello. I hope everyone had a great and loud break. Going to try and take the volume down a little bit. Use my NPR voice the best that I can. Thank you for closing the door, Philip.
So, uh, for those that joined a lot of these sessions last year, um, you may have seen me ask some questions up here, um, sometimes the same question across multiple events. The reason we started doing this is because I observed over my five years of being advocacy chair that the community kept asking for uh more direct forum in providing feedback of all kinds, technical, community, um member related otherwise, but to connect that with outcomes that actually resulted from the feedback being provided, right? Um, nobody wants to just feel like they vented about something and then it didn't go anywhere. And I think for years that was the resulting feeling that had been pent up. So, um, if you haven't been in one of these sessions before, um, I start out with some easy questions. Hopefully should cause you little to no stress.
Um, but the stress level does ramp up a little bit with these questions. Um and the reason being is that we are collectively here to work through some of these issues to discuss them openly to um be kind with our opinions and um know that the feedback is actually being taken in by the TSC and by the working group. So um I wanted to spend some time quickly before I got into the questions today on the feedback that was provided last year and some of the changes that have happened since then. So let's dig in.
So this is the overview. Um the community feedback was frag fragmented.
The feeling that the feedback did not result in changes. Um and so we've held multiple versions of this session um at OE specific developer meetings, at YP specific meetings, and at YP OE meetings. So all of the feedback from last year has been shared with the TSC and with the working group. Um so you might have felt like, hey, it's been a year, I haven't heard anything. Um so much of this is um it it takes time, right? Um we don't want to make rash decisions. Um so so what has resulted so far? So you may have remembered this question last year. What are you using?
Generally over the course of all of our polls, we had 88% of people saying they're using systemd. So a lot of people said, why aren't we doing systemd by default? I don't have an opinion on this, so please don't come for me. Um, but the results basically helped facilitate and further the conversations with the TSC to make this possible. So, this outcome has now been realized.
Yeah. Woo.
All right. Technical project leadership.
My favorite topic. Um, obviously it's no surprise that RP is quite burnt out. Um, we've had a lot of concerns about the longevity of the technical project leadership. um preparing for the CRA ecosystem and community technical engagement and the solution is the one and only Paul MF and Barker. Can you stand up for folks that don't know who you are?
So Paul is special for many reasons, but he is only the second person to be formally hired by the project. We are not >> who's the who's >> ah well no but we only contract him part-time and he's a Linux Foundation employee so I'm not going to include Holstead although I love him very much and we wouldn't be here today without him. Um th this is a really really big deal um because not only has Paul been involved in the community for quite some time both in a technical and otherwise capacity but that he has so many amazing relationships within the community. Um he has the technical prowess that we needed. Um and honestly the reason we were able to hire him is because of new members that came on in the last year that helped increase our annual budget to be able to afford to have somebody on full-time. So, if you are at a company that joined Yakto Project in the last year, please raise your hand.
Okay. So, I know we've got the Ericson boys here. Um, anybody here from Hitachi?
>> Anybody here from Tremble?
Okay. Which company are you from?
>> Schneider Electric. Amazing. Yes. Thank you. Yes. And that was >> thanks also to Risk Five.
>> And thanks to Risk 5. Yes, definitely.
So, when you think what is my membership funding going towards? I know I feel that way with a lot of projects, not with Yakto project because we do a lot with a lean budget, but other projects I think you're not even covering the infrastructure for the projects within this foundation. What are my fees going towards? we have now I mean we always have but direct result that you can see physically sitting here um in all the amazing work that Paul's been doing and a lot of the resulting changes from the feedback that were given last year are only able to be implemented because we have Paul now so thank you all for joining Yakto project your membership fees are really strengthening the future of the project so this is one of my biggest gripes um there are a lot of unmaintained layers and recipes um in the session last year Trevor ran a report for me and pulled that there were over 200 recipes that were unmaintained in core. Okay. Um or you have to really dig into certain readme files to find the maintainers information. It may be old, it may be outdated, um etc. Um so this does not actually reach engineering managers or directors who have business influence to be able to provide finances or resources to be able to resolve this gap because they are not going to go to a readme file. So sorry, they probably don't know what that is. So work in progress. We have a proposal out with OTIFF right now um in Alpha Omega to conduct a security audit. This would include identifying unmaintained recipes. Um this is on hold a bit because Alpha Omega's formatting has changed. However, we're looking at a way to maybe be able to move forward with uh smaller versions of the proposal on our own first before Alpha Omega funding comes through. Um and and like I said, this includes identifying unmaintained layers. Um, so the ideal solution would be accessible maintainer information for every layer and recipe.
Seems like a basic thing, right? But that is our goal. And then a styled and continuously updated table of layers and recipes that the workg group can bring to the member meetings and show members and say, "Are you using any of these layers in your products that you make money off of? That's a pretty big risk.
Don't you want to give us some money or an engineer? That'd be pretty cool." So we aren't able to do that right now. I'm not pulling 200 readme files. No thank you. So don't come for me for this. It was just a piece of feedback. Uh many people said that they wanted Cass or another working upstream alternative that can be used in production. And now Bitb big setup is available.
Again I don't have opinions. This is just the facts. Developer workflow. One of the problems is that the community is unsure where to contribute or how to communicate what's coming in the project in the future to their employers and the community wants more input into technical decisions and needs. So again, Paul, so sorry you are the star of my presentation. Paul is working with the TSC to produce a road map. This is so exciting and not just a this is when releases are coming out, but more specifics around which features are going to be included, what work is being done there. Um, and we also have just announced a YP member survey to gauge technical priorities. So, we're going to present those results in August and then hopefully be able to share those later in the year with the full Yakto community. Um, but that's going to help kind of indicate to the TSC what the members really care about as far as technical priorities. So, ideal solution publicly available high level roadmap um contribution opportunities identified early and often. Not everyone can do a bug fix. Not everyone um is is writing full patches. But if there are opportunities for folks to look ahead in the road map and say in six months I will have resources available and they happen to meet this need then we can have a discussion about that.
So community engagement um our opportunity was to start some community hosted meetups run by local contributors and the outcome was several meetups were hosted including one by Annalena Mars um and uh Inov. So, thank you so much for doing that. Um, from what I hear, it was really well attended and we really hope to see many, many more of these all around the world. What we're going to do is set up a a form and a formal process for you to be able to submit that and manage these on your own. You can host them at your company's uh office, you can host them at a cafe, you can host them on the beach, whatever. Um, but we just want to give you a platform to be able to tell people about that and um be able to spread the good word of Yakto.
So feedback is a gift, but we can't and maybe won't fix it all yet. There's a lot of qualifiers on that statement. So last year, what were some things that were identified? Um, but maybe we weren't able to address immediately. I just want to point out what was identified does not go unnoticed. Just because we haven't been able to fix it yet doesn't mean we don't care. It doesn't mean that we don't think it's valuable. Um, but here are some of the things that came through. Maintainer gap, right? Um, this one's obvious. um better error messages and error source, better documentation for newcomers, improved repo documentation, I'm not going to talk about it, but developer workflow tooling, Pippi versions of internal tools, um just for fun, release series themes, right, were were coming due, and then more opportunities to get the community together. I think like 20 people put that they wanted to see hackathons. So, you'll see a question later about that. So, we'll see if this works, but this is the moment you've been waiting for. It's now quiz time.
So, please take out your phone and scan this QR code or you can do it on your laptop here at slido.com.
And um I'm going to give everyone for the first one minute to answer this question.
Hey, I mean some people are a little slow with the QR code and getting it in there. So, I don't want anyone to feel feel too rushed. I said we're starting low stress.
I don't work.
>> It doesn't work.
>> No, I don't work. I can't answer.
>> Oh. Oh, God. Yseph. Come on, man.
>> That needs to be on a shirt.
>> I would buy that shirt.
>> Also, um, just to incentivize your participation a little more. Number one, I can see the number of people who have signed on. So, there's 48 of you in there right now, which means there's 12 of you who aren't. Also, I have these really adorable, super amazing yaki keychains here. They have little rubber feet and they're adorable. And if you participate, you might just get one if that incentivizes you appropriately.
Oh, 55 now. That was good. That worked.
Okay.
All right. We're moving on.
Okay. Look at the stats of the people in this room. 10 plus years on the project.
Um, this is pretty incredible. Um, uh, okay. Yeah, we're moving slightly, but wow. Okay, so over over I mean almost a third of the people in this room have been working on the project for 10 plus years. Thank you for your commitment.
Honestly, we would not be here if um, you had decided this was just not for you. Um, and under a year for newcomers, this is really great to see too. This is one of the problem spaces that we've been trying to work on is how do we get more um more people interested in Yakto or open embedded or embedded Linux in general at a younger age. Um and so thank you for joining. If this is your first Yakto event, thank you for being here. We are super super happy to have you. Okay, we're getting a little harder. What percent of your work hours do you spend on YPOE? This is not personal time. I want to know about your quote unquote 40hour work week.
just in general on the project. Yep.
If that means you're working on your product involving Yakto, that's totally fine, too.
All right.
Okay. So, it looks like based on the percentages coming through, I get the vibe that a lot of people are spending personal time on the project. Is that accurate?
>> Yep.
>> I'm shocked. Wow. Um, okay. Wow. And then 75% or more at 22%. That's also awesome to see.
All right. How many hours per week do you spend of your personal time on YTO project and open embedded?
Let's see those unpaid hours, y'all.
>> Some of these questions are really hard to answer.
>> That's the point.
>> Okay.
>> Set complete.
Okay. All right. So, a little more than a third of you are saying you're spending under four hours of personal time on Yakto. I'm just curious for those that answered that they're working 75% of more of their work hours on YTO.
Are you the same person who also picked under four hours of personal time, meaning your work is compensating you for the majority of the hours you're working on the project?
>> Yeah, perfect. Love to see that. That is not the case for the majority of the industry. So really, really cool to see.
I myself fall into the more than 24 hours bucket. Um, as do I'm sure, yeah, many of us here in the room. All right.
What percentage of your time do you spend on general project maintenance for YTO and open embedded?
>> Up. Yes. Upstream maintenance.
>> No. I'm so sorry.
>> Oh, I love I love the question. Let's just keep it wholesome and do percent of overall time.
>> All of it. All of it. All of it.
>> Yeah, just vibes.
>> Why aren't we vibe coding maintenance?
That sounds good.
The reason for asking this question is because fewer and fewer companies are willing to spend resources on project maintenance. They want to spend the resources on building sexy features and you know updating their layers or their BSP specifically for their products. And while that's super helpful and why the project is here, if we don't actually maintain the project, none of that other stuff matters. So when you ask yourself the question of well how do I convince my company to allow me to spend time on maintenance or to find other people to spend time on maintenance? This is what you would point out.
Yeah, this is what I expected to see. Um about 51% of people saying they don't do maintenance and that's and that's pretty common, right? Um but it is a risk and for for your company um and the project, but definitely for companies that have projects based on or products based on the project. Okay. So, have you made technical contributions to Yaka project or open embedded?
Okay. Wow. Look at that.
Interesting. I wonder if there's a correlation between that and the level of experience of folks in the room. H one could one could hypothesize, right?
Are you or your company using any unmaintained layers or recipes? Please let me know.
Do you have someone to contact if it's not working?
Is there someone actively updating it >> there? If there's not someone designated as the maintainer.
>> Yes.
>> Con.
>> All right. So, we're finding the edge cases, and I love the question and energy, but I don't think we're going to have the time to address that here.
Bookmark that one. And yeah, let's dig in that later.
Whoa. Okay, cool. Um, you know, I'm not surprised by the results here, but I am delighted to know that you actually know which ones that they're using that are unmaintained. Um, this is super exciting. Um, yeah, for for the 20% I have no clue. Totally understand. Um, so now, um, just real quickly, can you type in which layers they're using that are unmaintained or which recipes are unmaintained? This is going to help us be able to prioritize when we bring things to the member priorities, right, of saying, look at what's being used by the community, right? and these are the ones that are highest priority for finding maintainers. So, um this is not a onetoone, right? But this is going to give us some insight into that. So, please add your add your layers or recipes in here if you happen to know which ones you're using that are unmaintained.
And Ysef, I'm going to probably go five minutes over. I'm probably going to go five minutes over.
>> Perfect. I'll go another five minutes over. It's fine. We have a long lunch break. Sorry, y'all. This is important.
Oh, sorry, Phillip.
>> He's not >> He's not here.
>> I will be complaining about >> All right, we've got a few people typing, so I'll give it another minute or two.
Just curious to see if we're all using the same unmaintained layers or recipes.
That's going to be interesting. Okay.
Oh, okay. Who's trolling now?
>> This is no trolling.
>> Amazing.
>> We will send to you. Thank you so much.
That's also acceptable. If you do not know or you need to do some investigation, um please please send them to me because this is actually going to be helpful data to make technical decisions.
Let's see.
>> Okay, >> one new response. Okay, Meta Java. Okay, >> okay. All right, I'm moving on just for the sake of time. You're going to love this one. Are you using AI in your embedded development currently? Yes, it rocks. Yes, and it's a company requirement. Yes, but for limited tasks.
And no, I don't. Or what is AI? This is what I'm going to start going with. I have no clue what it is. I don't want to learn it. I'm not interested.
just got a few more, y'all. So, bear with me. All right.
>> Okay.
>> Is anyone surprised by what they see here?
>> Yeah, I have valid.
>> Same. I think that what we heard from a couple folks in their presentations in the last two days at the main conference was that um typically speaking uh the tools are um maybe not as equipped to handle embedded Linux andor they're really good for maybe some entry- level stuff but the complexities it just can't quite understand. So um just kind of gauging this we did not ask this question last year but obviously many many more of us are um being required by our companies to use it. So good to good to see what the background is. So what is the biggest challenge you or your team are facing with YTO project OE and embedded development today? What's your biggest challenge?
Is it money? Is it time? Is it your sanity?
Is there a specific technical challenge?
Is it an ecosystem thing?
Okay, just another 20 seconds or so.
Okay.
Okay, I'm just going to kind of quickly read through these. Um, I usually like to leave time for comment, but if I do that, then Philip will literally run out of time completely. So, um, adoption in the company, learning curve internally, learning curve too steep. Yep. Flood of vulnerability reporting, complexity, uh, multiple YTO Distros for different hardware and products. Yeah, that's unfortunately what makes the tool so uh flexible across uh many verticals.
Getting time for upstream work, convincing management to use it. Um cyber security updates. Uh yeah, definitely that is a big one with the CRA. We're going to have to talk about that another time. Triaging CVEes, developer workflow, uh, backwards compatibility, team size, customers, very steep learning curve, complexity for clients again, build resources. Sure. Yeah.
Okay. Rust. Yeah. Uh, discussion space.
Okay. Whoever said that, come find me later. I want to I want to hear more about what that means. Okay. Well, let's just let's find the glass half full here. What's the biggest opportunity you see for the project?
Just another 15 seconds or so here.
I know you all just lay awake at night dreaming about proper project opportunities, what that big blue sky looks like for Yakto.
Okay, let's take a look. Keeping the world moving, pulling resources for CRA across companies. I love that. Whoever said that, come to our CRA meetings.
Heterogeneous builds, world domination.
I wonder who said that.
Um, adoption for Siri successful and trendy products. CRA make companies to work with more with YTO. Yep. Yep. No more release and forget. And that's what I keep hearing more commonly um across the area communities, particularly with embedded Linux, where we may have been able to stretch how long we've been using certain releases. Um there's there's we are going to I to quote Phil Rob from Ericson we need to completely revamp how we manage release cycles and and legislation may be the the the lever here but uh really it's best for everyone and if customers don't like it because it costs to upgrade then show them the fines that they'll receive for not properly complying with the CRA and they should be pretty motivated to compare that cost with the cost of actually upgrading.
Ooh, that's spicy. Get back to be a community project instead of a commercially controlled one. Whoever said that, um, don't, you don't have to identify yourself, but please come find me after. I want to hear more about that.
Free drinks. Yeah, definitely. Come to the brewery. Come to the brewery in Raleigh. Um, adoption to meet cyber security requirements. Yep, we're well on our way. um using Yakto to meet obligations in the CRA. Yes. Um what is CTF compliant?
>> Um whoever put this in, would you mind raising your hand and letting us know what CTF um compliant means?
>> Okay. Okay. No problem. I'm like, there's new acronyms every day, so I'm I'm quite frankly not surprised.
Okay, so I'm only asking this because the last time I did a hackathon was like 10 years ago. Um, but it seems like there is a definite desire for Yakto and open embedded specific hackathons.
Traditionally, we host developer meetings like this where we can come, some people present, some people shout at each other, some people kumbaya, and then we go get beers after. Um but if there's a need for a specific hackathon, I want to understand what you actually want to do there. What do you want to get out of it? What would you like to see there? Right? Um sometimes it's it's a gamified experience. Sometimes it's a specific problem set. Sometimes it's groups working on multiple problem sets.
I just want to understand a little bit more about what we would actually like to see for this specific type of hackathon.
I'm going to toggle to the next slide just so we can see them coming in. Okay.
How do we hack on people? If you know how, please let me know.
>> Oh, sure. Um, I guess I meant in your computer screen. Um, people is kind of implied, but thank you.
Oh, okay. Robots and drones. Okay.
Introduction for newcomers. Sure.
Um, so whoever said money, are you imagining like one of those things that used to be on a game show like that clear box you stood in and the wind blew and you had to try and catch as many dollars as fast as you could? That's what I'm picturing when I see money here. Um, an upstream intro. Okay.
>> Yeah. Yeah. Everyone went straight to logistics. I got that part handled. Um, but on a more technical level, if you could let me know what you're looking for, that would be superb. Um because typically when I hear hackathon I'm hearing active problems being solved with hands- on keyboard, not necessarily discussion. Not to say it can't be a part of it, but that's why I want to make sure I'm clear when people are requesting hackathons that we're all on the same page of what that actually means.
Supply chain hacking. Okay.
Work on unmaintained recipes. What a great idea. We could call it a bake off.
Excellent. Love it. Okay.
Um, okay. So, what I have here is an open Q&A. These are not going to be addressed right now. What we're going to do is kind of compile these throughout the duration of the day. So, any questions you have at all about anything big, small, um, whatever you'd like to share. This this Q&A should continuously work through the day. And then we're going to try and save some time at the end of the day to address some of them.
If we cannot get through all of them, um, which is probably more than likely, um, now we've got a repo of them and then we will follow up either with a phone call or, uh, a group call or, uh, an email to the list, um, to follow up on the the remaining questions.
So, if you plan on doing Q&A, please scan this QR code so that you have access to it.
And I believe that's it. Thank you so much for your time today. And, um, the door is always open, so please come find me. um complaints, uh compliments, and anything in between. Always welcome.
Thanks so much for your time today.
It's the signal.
Is this the microphone? Yes, it is.
Okay. So, we are a little bit behind time. Um, I do see that I have a coffee break after me. I'm going to propose that I run the full 30 minutes and if people want to sneak out quietly for a coffee then that's okay. But yeah, I do want to still have time to cover the presentation. So let's start that.
So hi, I'm going to talk to you about creating YXO project compatible layers.
Um there are a couple of links in these slides. So, I didn't see anywhere to upload them. If you want them, I'm going to leave that up there for 20 seconds.
Cool.
So, yes. Who am I? I think I've already been introduced. Um, so yeah, I now work full-time on the Octo project. Um, essentially I act as a leverage function for the project. So I help to coordinate activities and help projects scale effectively and I do still get chance to hack on a few things which is nice.
Um, I've previously talked about a very similar subject which I call friendly layers. Um, the 2022 talk that I did is still a great resource. Um, so I'm going to try not repeating information that you can go and find in slides and video format and is still very relevant.
What I am going to talk about today is I'm going to introduce the YTO project compatibility project. I'm going to talk about the YTO check layer tool and I'm gonna uh if we've got time at the end cover a couple of other best practices and bits of advice.
So what is the YTO project compatibility program? Um this is essentially allows YTO project member companies to adv advertise that they are that their products or layers or software is compatible with YTO project. Um it allows you to use this very shiny badge.
But from a technical standpoint, the criteria that we have for this compatibility program reduces the likelihood of issues with different layer combinations.
And the intention is less time wasted debugging issues.
So why should you care about this? Um, there are many layers available as I'm sure most of you know and this leads to a multitude of possible combinations to the degree that we're never going to be able to test every possible combination of different layers and make sure that they all work happily together.
Poorly designed layers can interfere with each other and this causes bugs.
And the idea is that by following best practice and passing the checks that we have in the YTO check layer tool, this makes your layer a little more safe. Um, it makes it safe for your own development team so you're not wasting time internally and it makes it safer for downstream users, which hopefully makes products more attractive.
So the actual criteria for the YTO project compatible program um this is a member benefit um it's open to YTO project members at any tier. It's important to remember that open embedded is classed as a YTO project member for these purposes. So what open embedded can do is sponsor community layers. So this is how things like uh meta clang or similar layers can have project compatible status. So there is an avenue there for community maintained layers.
And to get this you need the layer to pass the check layer tests that we have.
You need a readme file with an accurate list of what layers you depend on.
Ideally, it needs to build without errors. That's kind of helpful. Um, and all your dependency layers have to be YTO project compatible. So, if you have optional dependencies that you're using via dynamic layers, they don't have to be compatible. But anything that is strictly required for your layer to work needs to be compatible for your layer to be compatible.
criteria continued. Um we do enforce separation of BSP layers that is layers that provide machines and distro layers.
This is to avoid kind of lumping too much together in one go. Having multiple layers within the same git repository is fine. It just needs to be that little bit of separation there.
If you have some sort of combined repository that includes your layers plus Bitbake and open embedded core allin one um those core layers have to be clearly identified and any changes that you're that you have to those have to be at least submitted upstream to the project.
And the last one is alignment with the overall goals of the YTO project which is around you know collaborating on a common set of tools and ways of doing things for embedded Linux.
Um we have just launched I say just within the last six months launched version three of the Shioto project compatibility program. This is essentially a bit of a relaunch to try and drive some more adoption of this. Um the criteria have changed slightly over the last five years. So it was good to give this a new version number. Um what what's been added here? We require layers to have a security file. Um we say you can't go and disable some of the QA checks and we say that you can't start enabling network access outside of do fetch. you have to use the the bitbake fetches if you want the layer to be compatible and the compatibility is branch specific. So when you submit there's this I didn't actually put a link on here. Um there is a form on ytoro.org to submit a layer as a candidate for being marked as compatible. When you submit, you say which YTO project releases you support. Um, we will track support for new YTO project releases if you say you support master and you create a branch that matches the new YTO project release. So, one of the jobs that's on my list uh probably for next week is go through and just anything that's now got a Rhino's branch that said it was compatible with master, we just need to rerun the checks and hopefully we'll be able to mark quite a lot of things as compatible.
So, um the YTO check layer tool. Um so this is essentially the the automated part of the compatible criteria. It also effectively acts as a way of enforcing best practices. So even if you're not looking to get this shiny badge, I still think it's worthwhile at least trying YTO check layer and seeing what it flags. and hopefully being in a position to fix those things.
So what does chuck do? What are words?
What does the octo check layer do? Um it checks one or more layers. Um including the dependencies. As I say, you need the dependency chain to also be compatible.
Um it validates that you meet the compatibility criteria, enforces best practices. Preparation for running YTO check layer. Um you need an existing build directory where you can run bit bake commands. We do not mind whether you use bitbait setup c shell any other way of getting uh build environment set up.
As long as you're in an environment where you have a build directory and you can run bit bake commands should be pretty good. At the minute um we do dynamically add the layers to be tested to BB layers. So we need to start off with the layers you want to test actually being removed from your list of layers. This is a little counterintuitive and it's usually the first thing that catches people out.
Um, and I would advise keeping local.com and other config files quite simple because they will be used by the the test cases. So that can impact the results that you get. So ideally keep a very very basic configuration.
And then once you've got these things set up, how do we run yto check layer?
If you have a simple layer with only dependency on open embedded core, it's pretty straightforward. You run yto check layer. This is in the scripts directory for open embedded core. So if you're in that environment where you can run bit bake, this command should also be on your path. And you give it the path to the layer that you want to test.
and it will go away. It will run all its test cases and it will give you some results.
If you have a layer with additional dependencies, you essentially just need to pass this d- dependency and then a list of dependencies. So this is how I would run it for meta virtualization.
The no auto dependency argument is quite useful. It says don't actually go and run all the tests on all these other four layers. We just assume we know those are already passed. We've tested those already. Let's just focus on this one layer.
For BSP layers, this gets slightly more complicated. So, we need to know what machines within that BSP layer we want to test.
And ideally, I would say even if you're not testing a BSP layer, it's actually really useful to pass this machines argument and give it at least two machines specified. And I'll cover when I cover the the tests that are performed, I'll kind of point back to to this in terms of how this interacts with your build directory. As I say, it uses the existing bblayers.com. It uses the existing local.com and it uses the same build directory. So setting variables in local.com/h having already built things may impact the validity of these tests. And say the layers to be tested must not be in baylayers.com already. So the recommendation there is set up a fresh build directory. Set up a very very limited config for running YTO check layer that may be much simpler than the config you're actually using for you know building a production image.
Test automation fairly simple. you should run this regularly in CI and that will hopefully catch any issues that creep in. Um, in terms of what we can do, we do run this on the autob builder for member companies and community layers because obviously if we're saying that someone's compatible with the Octo project, we need some way of finding out if that ceases to be true.
So um the tests are relatively lightweight.
This will take you know on my machine it for for a lot of layers it will take between sort of 15 and 30 minutes to run a full check layer test which is you know quicker than building every single recipe in um core and your layer. So we try to keep this relatively lightweight.
Couple of things we do want to improve here. You might may have noticed some of this is a little clunky. Um the argument handling can definitely be improved.
It's sometimes a little confusing the way that the depend dependency takes multiple arguments after it and d-machines takes multiple arguments after it.
We should switch this to using a separate build directory so that it's isolated from anything you've already built, anything you're going to build later.
We rather than requiring layers to not be in bblayers.com, we should actually say the layers that you want to test have to be in bb layers.com for already because that's what people would expect.
And we should be able to automatically find the layer directories and the dependencies based on what's in baylayers.com.
And for BSP layers, we should be enumerating what machines are in this layer rather than you having to specify the list. So we do have an issue on the bug tracker for this. Um this is an area that we are planning to do some improvements hopefully in the 6.1 time frame.
And the idea is if we want more people to run this, we do need it to be a little easier for people to use. We know this.
So, what does this actually test? Um, this tests that your layer has a readme file, that your layer has a security file. It tests that all of the recipes in your layer pass, which usually, you know, the the build would fall apart pretty early, you would think, if uh that wasn't true.
But particularly in the context of trying to have a limited local configuration when you test this, it's trying to make sure that you don't need special things to be set in local.com in order to make your layer parts. Um, we check that we can evaluate the the Bitbake environment fully.
We check that you specify what layer series, so what YTO project releases your layer is compatible with. And we do check that none of the required QA tests are skipped. So you can remove checks from error QA and warn QA in order to disable them. Um, but if you disable important QA tests, then your layer can't be marked as compatible.
patchup streaming. So the YTO check layer looks at all the patch files in a layer. It it doesn't look at source URI.
It just scans for patch files.
And it's going to make sure that all of those have valid upstream status tags.
So upstream status is the way that we record whether a patch has been submitted upstream, whether it is a backport of something that's already upstream, whether it's inappropriate for upstream because it's something very specific to how we do things in YTO project.
Currently, the tool allows the upstream status to just be pending. Um, but this may change. we may start requiring people to actually put in at least a short explanation of why patches haven't been submitted upstream yet.
And yes, this does apply for all patches in your layer, not just the patches in open embedded core for compatible status. Um, we then do signature tests. Um this the purpose of this is to check that simply adding a layer doesn't change the task signatures.
So if you have some new feature that is enabled by your layer that should not automatically be enabled just because that layer is included in the build. You need some configuration option in order to turn that on.
And for BSP layers, we also check that if you change the machine from one machine to another and rebuild, that should not cause changes in machine independent tasks.
So if you have a recipe that says that it is targeting all architectures because it's not compiling something, then that shouldn't change when you change machine.
want to be a little more specific about what this means because the concept of task signatures is not as well known especially amongst sort of newcomers to the project.
The task signature is essentially a hash over you know the task itself which is the the shell or Python implementation the the inputs to that task. So what variables do you reference um mostly and what the dependent tasks are. So for example, um let's off the top of my head think about do do patch as a task. It's going to be a signature over the actual do patch function. The inputs being well what are the check sums of the patch files and the dependencies which would be the the do fetch and the do unpack tasks that happen first. And this is how Bitbake figures out do I need to rerun a task because something has changed.
And changing any of these three things, the task itself, the inputs or dependencies will cause that signature to change. So just as this is useful in Bitbake to say do we actually need to rerun this task, it's also useful in this context to say has adding a new layer caused something in there to change or has changing the machine caused something to change where it's not marked as machine specific.
So the thing to be careful with is setting variables in layer.com.
um changing things unconditionally in BBENS provided an up providing an upgraded version of a recipe in your layer and not setting preferred version. Um this is where I'm not going to repeat the content of my previous talk on friendly layers. There's quite a bit in there about what you should do in order to not have adding your layer unintentionally go and change everything.
Future test cases, we should be testing distros added by a layer. We should be making the patch validity checks stricter. We should be checking that passing is possible without network access. So ideally none of the metadata is actually going and fetching things from the internet. Um we should be checking that the layer itself has a valid license um or at least says that it's prior proprietary if it is. And one thing that was mentioned earlier was um machine readable maintainer info instead of um just an unstructured readme file. We are open to other ideas of what we think should be tested, but the test cases here need to be lightweight. YTO check layer doesn't actually go and build recipes. It just evaluates signatures and runs tests around things like what's in the readme.
Couple of limitations that we want to remove. Um so we know that currently YTO check layer can't handle multiconfig builds or where one recipe is dependent on uh multiconfig.
We know that it can't currently handle bare metal machines. So if you have an SOC that has like a Cortex A core that runs Linux and a Cortex M core that runs some Arttos, we don't want every single recipe to have to have compatible host set to say it only works on the Linux side. Don't try and build it for the CortexM.
Um we should have some way of marking a machine as somewhat more limited.
And there are some variables that you should be able to unconditionally modify in your layer. There's a list of valid items for image features. Uh if you want to define a new image feature that can be enabled, you need to add it to valid items. And when you do that, Yu check layer currently rejects it. So there's a few things here where we do need to actually have a list of exceptions where you are allowed to unconditionally modify things.
So that's the content I've got on YTO check layer. I've got a couple of minutes left, so I'm going to rattle through some further advice and best practices that wasn't in my previous friendly layers talk. Um, anonymous Python functions, we all love them, we all hate them. Um, you can run Python code at past time. If you didn't know this, you do now. Um, it's very, very powerful. Um, it allows you to do things that you couldn't do just by setting a variable. Um, be very careful of the impact on pass time. If you're doing complicated things in anonymous Python function, that is going to slow down pass of everything and make people sad because builds take longer. Um, it's also evaluated quite late. So it's these anonymous Python blocks are evaluated after we've already inherited any BB classes after we've already included any files. So you can't actually figure out what classes you want to inherit using an anonymous Python function.
What do these look like? Um this is an obsolete example I found. I wanted something that fit on one slide that shows you the sort of things that can be done. These are old kernel versions. So yes, this is obsolete, but I wanted to get the idea across here. So to actually set these variables in a way that's dependent on the version of a recipe would be a bit tricky without having the ability to have structured if conditions.
So anonymous Python code that runs during pass that allows you to set variables, do other things, very very powerful but use sparingly, use carefully. Um other things that can be expensive um variable assignments. So you can call a function in a variable assignment. This be a Python function. If that function goes and does something complicated like takes check sums of hundreds of source files in a repository or goes searching for particular types of file or other thing that is going to be evaluated multiple times during passing people think oh I've only called it once in one variable assignment so my function will run once and it doesn't matter if it takes a couple seconds because it only runs once. Um, every time you have a set variable call in some sort of anonymous Python, which there already are quite a lot. So that is these type of set variable calls.
Bitbake has to re-evaluate well what now that I've changed one variable, what other variables also change because they reference that.
So if you have expensive function calls here, they will get evaluated multiple times during bit bake passing your recipes and that can have a really outsized impact that can surprise people. So do again something to be aware of if you weren't already. And last one, if you do have things that you want to explicitly run once and only once, um a good way to control this is event handlers. The syntax is a couple of extra lines over and above just defining a function, but you essentially say what event do I want to listen for and then what code do I want to run when that event is triggered and Bitbake fires off all these various events during its process. So in this case, this is taken from the um BB class that creates the SPDX um sbomb, which you know, we only want to create the sbomb once during a build. That would help.
And so in this case, it's done based on this build started event. When that fires, this code will run and it will be able to go and iterate through things and create the spdx data.
If you look at the event.py file in bitbake source, it's just a big long list of event classes.
So this is worth a look if you do have something that's quite expensive. You don't want it to run multiple times during passing.
then event handlers are the way to go.
So that's what I've got. Um, thank you.
And any questions if I have time? No time.
No, no time for questions. Sorry. So come and find me later on. I'll be here all day and happy to talk about things.
>> Paul has time for questions >> outside for coffee in in person. You can heckle him all the time. I hereby declare 15 minutes coffee break. Then Anna does her presentation as planned and we just cut Philillip short. I declare that he will do a lightning talk by by the order of the mighty zombie pirate.
>> Sorry people.
Is it true that they not just go into the task signatures?
>> Um >> I I have had the experience that that I need manually make sure that they >> not be in the task signature.
>> Yeah. So if you actually do something that you want to have rebuilt still good thing might be the right thing but you might want to remember to add them.
>> Yeah. I know that is very true always the complications >> it is but it's a better approach you could do that sometimes if you have that I was writing this last All right.
because we have a lot of layer 1 hour.
So some of the builds runs quickly.
Yeah, He Somebody's not >> because I have Now we're going to turn Everything in my leg.
Most of the most ass.
You want to set something?
You could probably check as well. You still have to still have recipes that have specific machine.
Yeah.
something even That's why I love it.
like to go beyond that.
I don't think like understand what to do.
start.
Okay.
By the time we We got All in all, Can someone make your hands?
Okay.
So, you got to pick the This one is left.
Oh, no.
I got a t-shirt from yesterday.
Unfortunately, you can't close those.
Who are they? I've been looking at them.
But it has to >> all just know So with this USBC Yeah.
So the problem is 65.
I'm not changing anything.
The other modules keyboard.
many people.
>> That's actually very nice.
going on.
>> I mean, I can I think I can start. Hi all. Um, today I want to talk a bit about u managing long-term risks and compliance in embedded Linux with YTO. Disclaimer one, this talk was initially held on uh the embedded world conference. So if you're here, you're probably uh not the target audience for the talk. But I think um maybe you can also take something with it uh from the talk and maybe there are some nice manageable uh managementable slides you can use to convince your boss, your customers to uh make it right. But let's start. I'm Anna. I'm uh a senior embedded dev/tech lead for embedded Linux systems at Inovax. I'm quite long at that company um since 2015. I have a background in um embedded systems but also studied electrical engineering um started as a as a hobby.
Um and in terms of Yakto, I'm probably around 2017 Yakto user at least since preLTS times.
Not sure, but I'm quite young, so properly that counts.
Um, and for now to start, I think we all know YTO has a really good built-in support for running products for a really long time and helping with that.
But let me introduce you the new room in the room. Uh, the new elephant in the room. And I'm pretty sure you all know Cyber Resilience Act.
And to make sure you won't look as that guy here in the picture, um, let's continue how YTO can help you build successful products that run for a longer time fearlessly. And just to make it sure, it's an AI generated picture.
No elephant were harmed for this picture.
Um to start with I think one of the most important parts of CRA and I think one that really goes in the right direction is um it gives us some kind of paradigm shift with CRA. um we are forced to threat or to treat software not as a necessary evil but as a real important part of the product. It forces us to really do security as some kind of a core system architecture guideline and not like um yeah just left the UAT unpopulated and you're fine. Um it really forces us also to do continuous vulnerability management just instead of maybe we can fix some critical bugs if there's time maybe but even not um and also it brings a continuous liability for at minimum five years depending on your product even longer instead of just a fire and forget mentality.
So the important takeaway um software increases in uh the importance of from a regulatory perspective and with that it also should do in your product development.
I think for all here in the room, it's a no-brainer. But if you're working with um companies doing machines, not really into software, this is really a big shift.
And a short reminder about CRA. Um I think the most important um requirements I want to talk about in this talk um are from NX1 part one and two.
Um on the one hand side um the essential cyber security requirements with things like um you should ship your product with a secure standard configuration with no known vulnerabilities.
You should include security updates and a plan for that.
also providing things like access control and minimizing the attack surface, but also um things like um vulner vulnerability handling requirements from part two with um you need to have and need to provide an asbomb at least if someone asks you to do so.
Um depending on your product class, you have to do security tests, automated scans, maybe panests and you need to do continuous monitoring for the uh CVE database for example and as also uh already said security updates with a secure distribution.
I think you all know Yapto can help you already with a lot of that.
um just to um make it bit visible here.
But before we um go into how Yoku can help you, I won't talk about um the fundamentals for all of this. Not sure if it's really visible right here with this overlay, but um I think it's really hard to get CR right if you really lack in the fundament.
If your B support package is crap and you run with a fork vendor kernel with a lot patches with security updates not getting in there and no upgrades at all available, um you will have a hard time getting CRA um right without too much additional effort.
And I think there are also two really big pitfalls when it comes to BSPs.
One is what I like to call um the layup load pitfall.
Um because when speaking about vendor BSPs um in the past I have already seen often things like bloated layers with demo applications maybe proprietary additional drivers binary props with a lot of things you will never use in your real product but there come with um the BSP bundled without an option to just take that parts that are really needed for your product. Maybe it also comes with predefined distro and images rather um yeah um intended as a demo but a lot of customers a lot of um product vendors um tend to take this as given and don't really understand it's just a demo and not required use and I think all of you understand the risk We get uh applications installed from nowhere, hard to control, hard to find, and everything you install that is not really needed opens up a security risk.
You get a bloated system and essentially your system becomes a black box. Not really controllable, not really um understandable what's going on in there.
And for sure this should be for uh should be avoided but but it gives you um some uncalculated risk.
So let's continue with the second risk that comes from vendor BSPs um with the fork kernel. I already mentioned it a bit, but to make it even more visible, um I think it's fine to say I hate forked vendor kernels. Um because there are from a maintenance perspective uh just really unpredictable.
Um, often vendors tend to use fork kernels because they want to showcase unique components, features, may some things that are not yet upstream. Maybe they do not even try.
Sometimes it also um contains proprietary binary blobs. Um sometimes um the reason is that they try to ease their own development and their own um maintenance workflows. But the risks on the other hand are real.
Um if upstream security patches are not pulled in in time um if the code base diverges um all that additional effort for fixing security in a product um comes down to the integrator to the product manufacturer and for that reason I think a really essential part of getting ready for CRA is uh evaluating BSP um and especially the kernel before you start even with your product with the Y to integrate uh integration.
Um otherwise I think you really have a hard time get a CRA done right.
But yeah, let's continue with the YTO part of the things. And I tend to um see YTO as some kind of a compliance engine that can help you getting CRA ready and help you with the most important things.
Just a reminder, Yak really help you with a lot um with vulnerabilities with access control maybe if you enable it with minimizing the attack surface as bomb. But let us have a deeper look into I think um one of the most important points YTO gives you is um it enables you owning your system.
Um with YTO the idea is clear. You build everything from source um which enables you um some kind of full stack patchability. You are able to control each component, each software, each line of code in your product and you can patch it if needed.
So you are forced to own the system and really take control over but on the positive side you can do it. You can patch each line.
You also have support for things like the Aiva class which enables you to create a source code archive for each released version.
Um so if you have to fix something in the code years after maybe a really simple fix and the upstream repo is gone. We have seen that in the past for example with code Aurora. Um the code is still there. You can still arke it and recreate your YTO build from that and also I think nothing new to the community here. Um YTO is from its concept um reproducible.
So um you can rebuild system, you can make sure it's um just recreatable, but also it's a known system and it gives you some independence from just a little p u a little um number of persons that really know about your system.
It's also understandable and repusable for other people that are into Yokto.
So taking ownership for your specific system should be the first starting point um for uh a really compliant and maintainable system.
Of course we also have some kind of security built in. Maybe not all features needed right from the start but um I think we have a really solid baseline you can just get right from Yakto.
um with removing unneeded image features and distro features, you can just set a baseline um to limit down the things that really go into image and I think a minimal image is just the best baseline for security.
Uh, another really lowhanging fruit is enabling security flags but also minimizing um the installed packages and really make sure you do not include anything not needed right from the beginning.
Um, of course, you can also easily um limit service and user rights with apps, remove um unnecessary or potentially um dangerous kernel configurations if you want to look have a deeper look into kernel configurations.
Um it's maybe worth a try um using the kernel hardening checker and um overlay your kernel configuration with um a config fragment with the um revel revel how is it called with the not needed features disabled.
And if you need even more advanced features maybe give meta security a try.
I think the maintainer is also here.
Um, in terms of compliance and software traceability also here, YTO gives you a a really good starting point because YTO was always um was always built to track license and keep license uh requirements in place.
So with the license BP class we have a really good um base for that.
Um only issues I think if you um work with languages like go and rust modern languages that come with their own kind of license of um of dependency tracking. Um it's yeah it's a bit um an issue with their own dependency tracking. They um work around the YTO mechanisms to keep track of licenses and dependencies.
Um there are ways to solve that issue.
But um for example using um go mod vendor to vendor your dependencies um of needs you some additional steps but in the long term it really helps you because you have defined dependencies in a defined version and um the oto tracking mechanisms can work as intended.
Um, of course we have um, sbomb generation in place as a Linux foundation project. Of course, spdx um, nowadays with rhinos um, spdx 3.0 is right in place and you do not even have to um, include it into your build. It's just there.
And um also for CVE checking we have really good tools in place um CVE check nowadays um was replaced with ASPOM CVE check and including it can already be done with an OE fragment which is really good improvement I think so it's also really easy to enable that and if you want to do more Um, of course there are also additional tools available. One thing I want to mention here is wound scout because of two things. The first thing is what you see here. It has a really nice UI and I think this UI is really helpful if you want to make sure your management understands what is going on in the system, what uh vulnerabilities are there and why you need time to take care of it.
And the next thing um why I think wool scout is really a interesting tool is um what is basically um visible in this slide here. WS Scout is able to use already um several sources um to check CBEES against not only the NBD but also other databases and other input or output formats. and you can include it it into a CI run and define fail conditions for your CI based on um severity conditions for from databases. I think that's also really interesting to make um the the sheer amount of CVEes more manageable and um help you with evaluation.
And I think the last thing which is worth to uh mention in terms of CVE is updates um because it's just such a cornerstone of the CRA um for sure we have no one single um client integrated in YTO but there are several available right from um really good maintained third party layers like Manda Ral book SSW update the whole um actualizer OS3 ecosystem and um maybe it's also worth to keep um systemde update in your mind for future it's also an interesting approach um in general in terms of update I think not really um needed to uh mention it here you should use image package based updates over package based ones. Um, separate functional and security updates from a CRA perspective. It's recommended there to make sure um you can ship security updates independently from um functional updates and of course sign artifacts and also probably not worth mentioning here but um test your update test your update process go creative.
um funny things can happen but probably you know already and with that um I can already go forward with the summary and the path forward I would suggest um if you want fearless long-terms maintenance I would recommend starting already with selecting a wellsupported hardware platform with a kernel that is really good maintained right from the vendor or um even better directly upstream.
Um plan for your internal and uh regulatory requirements even before starting with writing the first lines of code. Integrate and update client. No.
Related Videos
Agentforce NOW AMA: Build with React and Salesforce Multi-Framework
SalesforceDevs
490 views•2026-05-28
How agent o11y differs from traditional o11y — Phil Hetzel, Braintrust
aiDotEngineer
450 views•2026-05-28
Re: 🗣️📍theprophedu📍2026 GST 103 CLASS (E-EXAM REVISION)
theprophedu
636 views•2026-06-04
WEB TECHNOLOGIES UNIT-2 | Degree 4th sem BCOM Computers web technologies unit-2 full explanation💯✅
LearnwithSahera
1K views•2026-05-29
More tests are always better? How to use AI to identify tests that bring little value
Alliance4Qualification
335 views•2026-05-29
Search Algorithms Explained in 60 Seconds! 🤖💨
samarthtuliofficial
218 views•2026-06-01
People of Game of Thrones using JavaScript DOM
AltCampus
296 views•2026-05-30
Instagram accounts got PWNed
EricParker
13K views•2026-06-03
