Marrying U-Boot, uEFI and grub2 - Alexander Graf, SUSE

all right it's half past um I have about 150 slides so we should probably make sure we start early it's my pleasure to show you all the amazing best boards you buzz-buzz you always wanted to hear in a single talk you if I go up and do butall at the same time it's net awesome so Who am I I'm Alexander Graf I work for Susan I my official position really is a virtualization developer I usually don't get around to do embedded hardware things in in my official assignment good thing is that I don't stick to my official assignments so I end up doing a lot of arm work which is what is down here I'm basically one of the founding members of the suzerainty so back a couple years ago four years or so roughly we sat down together and moved up to a position where we said suzer should be in the arm business which means we should also be in the embedded business a bit more and figured out ways and and worked on started working on things that made us move towards that path and this is one of the outcomes off of that work so how does putting on arm work putting on arm it's a story full of mysteries it basically starts off with your boot ROM so you have a boot ROM can you hear me well alright also you have a boot ROM in your in your CPU which one's very target specific code it once basically your SOC specific code in there that's what that symbol symbolizes and it's really only there to boot some other small stage of bootloader or even bigger stage of bootloader basically eventually you're getting to a to some kind of film which is something that whoever puts assembles aboard puts on the on the system to describe how that ball works to bring it up initially so that the operating system can take over and that is also very target specific code because you obviously to initialize the board and so you need to know what their port looks like and then you have an operating system running on top which may or may not be target specific and the hand over power over here that's basically the main piece we're talking about that one today is either some custom protocol externus configuration files V booed UEFI I'm sure they are plenty more out of there of ways how to get from film where all the way down to your operating system now me is operating system person I don't care about all of this over here really I mean I sure I did patches and I do work on it to improve it but from a from a user's point of view if I want to use an operating system I I don't want to have to care which board I'm running the operating system on I just only want to plug it in and have it work and not worry about which hardware platform I'm on this is me coming from a server and desktop B background I guess it's very different in this audience but this is the expectation that our users our customers have also all the stuff down here all that craft it's very annoying if you want to have a single if you really want to have a universal image you can support every single boot method this out there in that one image it's it's she impossible which why it could even if you tried it wasn't it wasn't doable so we really want to have one single protocol and then just be done have one operating system have one saying a protocol to talk to your film where leave firmware to others and we're happy right then we are universal and we're we are all off-site find off on what we're doing so to understand how we could potentially get there let's take a look at what the UEFI boot flow looks like so I'm gonna explain what UEFI is later but the boot flow is basically the example set set example on how to do it generically because exit is 6 software that years ago right I mean they do know what they're doing if they want to boot windows and every system out there so you have your film wear which is you if I compliant and that film we're then goes in and looks at and vram which contains a boot list boot order and it just has a couple of files that it can boot from on that boot order so it goes through that list and tries to find the first file in that boot order if it can't find it it goes to the second file in that boot order if it can't find it it goes to the third file of the important pieces the boot order it's not just the device it actually is a device and a file usually it's actually it's an actual path now if none of these boot path is work and that's important for us here none of these two parts work then we in the fallback case in which case we have something called removable boot which is which was originally intended for things like USB sticks and CD ROMs or you did not know beforehand what you're going to boot you're just plugging it in and it should work which is basically what we're trying to do on arm system so what you should plug it in and it should work so this is really what we're trying to model that removable medium stuff basically has a predefined file name so it's per architecture you have different file names that are default but it searches on every one of those devices that it knows of it searches for a for that file name it's as simple as that it goes in and searches to have that file name on my disk no I don't have it on my SD card no there's no I sneaked up locked in do I have it on a cd-rom that's plugged in somewhere yes I do awesome next step next step is we are booting our payload this is just in case you can't see it this is the new amazing better type logo of co-op so crap so we're booting our our payload be loading it from from our from our storage rebooting it it goes in and then that payload receives a a thing called efi one-time data it's basically just a pointer so it's similar to how linux gets the device tree as a pointer when you're booted in an EFI world the if I payload gets the efi one-time data as as the payload as the as the reference it can use to to then further on figure out what it should do if I want end data contains really just four main things it contains console support boot services runtime services and tables console is self-explanatory I would guess I mean everybody knows what a console is um it's one slide too much all right but the the the thing that we're going to use over here oh no that's not sorry too much animation there you go using this one time data we now have a bi-directional communication channel between film where and our payload that's the important piece so you get this one time data our film we're into our EFI binary goes and uses that one time data to have callbacks back into UEFI so we have a bi-directional channel established and thereby we can call backs we can actually communicate with our film wear and make use of our firmware to do other things like for example boot services which provide us objects that we can use to access devices that our film wear knows about so EFI for example has awareness of a what a block devices right and it provides you interfaces to talk to block devices using the some special protocols but basically using the boot time services so this piece of code can now go in and read data from this block device but it doesn't have to use the file system for example from from from your film where it can easily implement its own so for example here grew up can just go in and implement its own butterfat support but use the block layer of UEFI to then say load the Linux kernel and run that one which again is a EFI binary in case you didn't know Linux kernel is say you if I binary and one also gets the spy directional channel to UEFI and so that one's running a CDFI binary now so now we getting to the really interesting piece of you if I it has this thing called called exit boot time Services likes a good exit boot services where it basically just tells you if I go and kill everything that's not me because I'm taking over the Machine now and I don't want you to control the hop anymore I want to do all that control it's called Christ on power for example in case you've ever worked on that one there's usually a call in film where where the operating system can say alright now I'm taking over that one also exists in you if I but you if I still keep some memory still keeps around a bit at least some some pieces to provide runtime services so one-time services are something that Linux can call into while it is executing so you have Linux running and everything's there but some check pages in memory you still contain executable code that the nose can call into to have other services provided for example so the three most important ones are in vram you can modify the boot order it has one real time clock support so that you don't have to re-implement real time clock drivers for every single system out there and your board can specify which one it is and how to access it and it supports reset and and shutdown services so you just say if I I I want to shut down the system and that's it you don't have to implement that for every single system out they you then so those the other the main main pieces in the runtime services now why why is efu if I any I mean why do we have any benefit from using UEFI of our traditional boot protocols that we that we do have on the embedded world no I don't mean no standardized they are in there forever they're good well there's a few things that actually make life a lot easier for us the first and most important thing to me is we basically create a bubble around our film where thing there right we have a standardized interface all the way over here and create another bubble which is what the user provides on the other end that means that any value add that we have now which is not in our film where does not have to be in film where we can just modify the thing that comes with our operating system and add something to it that was not in in UEFI before so you if I by default does not dictate any file system support except for vfat well good luck booting of a vfat partition it works but it's a really big massive your standard stock distribution we really want to boot from other effects for example so if you want to put from butt we just grew up into a fat petition where it can lie around and do whatever it wants but that one just loads by a butter fest module internally uses that to load the kernel and we have booted off a part of FS or we can build off of ZFS or we can build off of a next for partition that happens to have 64-bit capabilities enabled with a broken new boot all of these would are basically fixable by the distribution because the distribution is the one providing the filesystem so why shouldn't the distribution be the one providing the file system drivers just at the same time right basic the rationale is you have a line down here where this comes from a completely different entity than this here and that specially the main main difference between the traditional embedded market that we've seen one really really amazing value add that our product managers just love is this you have a graphical boot menu isn't that awesome you can display logos yeah I know nobody really cares but um apart from it being graphical having a boot menu is actually really really useful because you can go in edit the command line on the command line and just tag array which is maybe not what you need for your typical embedded device which runs as an appliance but during development it comes in incredibly handy to be able to modify the Mac command line using just a couple of keystrokes right another really interesting thing is that you if you're thinking out of the box the first guys that I've seen that adopted the UEFI boot was actually not us I mean I I pushed all that code upstream but the first ones that I've seen using it for the FreeBSD ones because they had the same problem they they need to have their own bootloader which then runs something off of ZFS or their own whatever I don't know and they want to be able to boot FreeBSD on arm 64 systems so just jumped on board ported their bootloader to to you if I enter using their own arm 64 these days just actually pretty cool one thing you also should always keep in mind when well I mean this is really important to us it might be common according to you is that this allows for compatibility so in the same image now once on all those systems out there right because we edit that bar we basically try to move all of the hardware specifics out of our image that we're actually deploying that same image now can run on a random server system or just the same on an embedded target so you you suddenly have an image that is universal and if you really do need to switch to a different type of hardware you can depending within the scope and the limits of what you're trying to do obviously right but it just makes life easier to switch to new things because you're not locked in that heavily so what is you if I'm UEFI is a specification I know a lot of people think you if is an implementation it's not it's a specification it's a gigantic enormous document with lots and lots of interest Li interestingly written text that describes how to implement different interfaces about 5% of these are interesting really and useful and Intel basically started this as EFI and then gave it to the open start a consortium called UEFI consortium and the newest specifications are called UEFI so if I say if I forgive me I really mean UEFI because UEFI is everything that people use these days so UEFI has a reference implementation and that one's called tiyanak or if you've ever seen an EFI system that's either Tiano core based or some homegrown implementation of a commercial distribution so I don't know I don't I don't even know if ami for example uses Tiano core I would doubt they do it they might use some parts parts of it but jello core is the reference orientation that basically Intel uses to verify whether the spec is sane and how to and to control that people can develop against something that is that is widely available so why do we need another implementation of the same thing why do we need to have you boot suddenly involved as well and at the same interfaces to get another boot loader I mean what's the what's the point I see Tom grinning and I'm using I'm using that logo throughout I just really found it very cute so channel core the first and foremost reason for me personally if you've ever looked at the code it does not follow how do you could say this um it does not follow coding style guidelines that I embrace how are you politically correct this is the most readable code I found in all of channel core just so you're rare at first tried to find another function rich didn't fit on the screen even which did basically the same thing as the that you would function and which follows just an almost enter the nose coding style right I mean this is readable code it's not the most readable code ever because we have to have these efi entry and ii if I accept micros to safe and registered but apart from these it's all just normal linked together proper code just the same way as you would expect it to to look like so if you've ever wondered what how if I works just maybe if you got stuck on the weeding channel quad code trying with the u-boot code it's much easier then one really big amazing difference that I have found to in developing it is that if you if you would be a normal developer and you want to call say something from one C file to another C file module some something inside your code base and you want to call into some other piece of the author of your codebase what do you do right usually you you have a symbol and you call into it not so into a no Courland in Tiano corland you first call a broker that gives you a handle that allows you to then do an internet function call back into your other module so that you build amazing black boxes around every single piece of code that you're writing yes this makes everything incredibly hard to understand if you're trying to follow the path what you're actually calling it usually stops at the point where you're trying to do that in direct reference to some other module and you just have no idea where that comes from because there's no no direct linking inside the same code base whereas in Ubud again same as linux it's one big monolithic thing that just linked together which makes it much more readable debuggable you just attach TDB you see function traces everything just works the way you would expect it to see scope done so and last but not least on the and the important pieces that make you boot very different from from general core is that general core is meant as the core it's even said I mean if it seemed sesor in this name right it's meant as the small piece that implements a few reference systems reference designs so that it shows that it actually can run something but it does not want to include every single board support in one code base instead it wants you to fork it it wants you to fork special board support into a different repository life now finally went ahead and actually got fed up with that and created something called open platform package where he has an amazing five I think what support it down but that doesn't solve a problem that you still have to somehow merge code back all the time and you don't have one code repository where you can develop interfaces in lockstep and keep things internal because in Tiano core nothing is internal it's just they they basically drove themselves into a corner where it's really hard to improve their co-pays where's your boot well I'm just letting numbers speak but that board support is not even remotely comparable to Tiano core by enabling channel call you you basically get yourself on a few systems out there buy anything you boot while you conquer the world it's a different league so comparing those two you can see that it makes a lot of sense to enable your boot because I mean I want I like the Yuga code but I really like to hack on it it's very hackable it's understandable if you need to modify it you can modify it I see a lot of reason to have a standardized boot path that allows me to do my distribution with at the same way I always do it on other images to film where but in a heckuva manner in heck of a fashion and like proper linux ii kind so what do you if I interfaces look like I was always abstract why you have these objects new things there so you if I interfaces let's take a look at objects so you if I basically gives you objects this this is a disk object a block object and a CD object and the network object and every object is aware of its parents so it has a four parent and child hierarchy so this for example is an HDI controller and you have an HDI controller object that you can talk to that you can poke through and find the PCI bus of that age so I controller and whatever it's it's a full full hierarchy with everything included you can even have children there you can have a file system object our file system driver creating object attached to your block device again and a partition layout object and whatever each of these objects have callbacks and properties fields whatever your name of the day is that happens both for block as well as for network so each of them have callbacks that you can use to basically send packets or wheat data and they just describe some layouts like what is the sector size now in Ubud on the other hand we do also have objects but we don't have a tree right we don't we don't have this hierarchy we just have objects for specific endpoints which is good enough you don't really need to traverse trees externally but we also have these callbacks we have every area of the every one of these objects basically knows like what that size is like the block device for example all set size it knows it knows sector sizes and no it can it has callbacks to read things that has callbacks to write things it looks the exact same it's basically if you leave away the hi Ricki part the actual objects that we care about they're the same thing just with a different semantics and what you usually do when you have different semantics basically different languages is you just write translations to him right you basically just write a small you can you can basically can translate from from u-boot interfaces to you if I interfaces very very easily with a really little code you just implement the you if I call back and call the u-boot call back and that's it they might not have the same parameter names but it's very very little code and all of that is a new bit upstream called efi loader it's in slash lips like CD if i if i loader and it basically just goes and converts from one thing to the other all there is to it very simple very little code really very little code if you want to look at it now we can basically talk efi but how do we get this binary to even run all right so we now know how to how to talk interfaces to to an application but we need to somehow get an application running as well and that's where booty if i comes into place so we already have things like boot z boot m boot i whatever on your boot so now we also have one more thing called booty if i sew a booty if i does is it basically or what you do when you want to use booty if is you at first half your memory and you somehow need to get your binary into that memory from your storage just like you do with the normal boot flow that you have on on boot zebu die whatever you want to call them for normal traditional you boot so you take that you use that normal load command with you bit implements to take your payload and move it into ram done same as always a new boot it's the same thing Willian i really just doing it and now what you can do is now you can tell you boot go ahead and execute that binary with this device tree that I'm giving you you can also leave out the device tree if you don't want to pass a device tree at which point you boot goes in runs the once the in this case is Linux right once the linux efi stopped which then runs Linux and you're booting off so it basically if you're running this on a Raspberry Pi 3 which I just had lying around as a queueing new target it basically looks like this so you would load something from your storage that you would load your your kernel image from storage you load the device tree you modify the device tree so that it contains a working command-line argument filled in there so just ftt chosen basely updates the current device tree and then you're booted and it boots up it it's finding Linux now and there we go now it's switch to graphics mode and you're just booting up and obviously it doesn't find a root device because we didn't patent any but it's the same as any other boot method you have a new wood it doesn't differentiate between them it looks the same one really amazing thing but this allows us to do is that now Linux is actually has the spy directional interface to your film wear so what Glynnis can do now is it can go in and talk to for example a random number generator driver in UEFI which then allows it to relocate itself to a random location in memory and implement KS a lot of this way so if you want case lower support you right now need to have UEFI support and I'm sure that's going to be more features like this coming where Linux just more and more depends on having the spy directional interface to film where available so having a booty if I path even in trivial cases does make a lot of sense because it doesn't actually give you any downside over a boo type app for example now unfortunate a distribution I don't want to type load something from sd card and booty if I that parameter there all the time so there was a really night messing there was something really really amazing work and and you would have stream called distribute like couple years ago and that basically gives us a standardized bood method so distribute describes just boot targets that it wants to boot from so you have this variable in in your new boot environment you can modify it if you really want to you can just fizzle them you can change them safe and and then you boot from a different device and for each of those devices it tries to find a valid boot boot target boot file that it can boot from so in our case we're trying to before a block device so it tries to search for an external current for a boot script and for an EFI payload this talk is not about excellent ups or boot scripts so we're only focusing on how the if I boot then is implemented so the EFI boot basically goes in and looks at your storage device it tries to find if you actually have one at first and if you have one it looks at your partition table and it assumes that the first partition on the partition table is your efi system partition so if i persistent partition in case you've ever worked on the efi x86 system is just a fat partition usually that stores your payloads your grub for example the thing i was referring to earlier so we're using that same partition because in most cases that is your first partition it can give the UEFI specification allows you to have it in a different place but you would just ignore that part right now so we take that petition and then you boot also has awareness of what your device tree is called so there's a device tree dollar divide ftt file parameter every Tifa environment variable that describes what the file name for your specific board for a device tree would be so it searches for that file on these standard locations so that if your first partition for example is your root filesystem which happens to have a slash boot path which happens to have a boot DTB path you could then just poke your device trees in there and it would automatically find them and use them that's the idea at least it also goes and tries to search for our removable media path so you saw this thing earlier where you have the boot order if if I files and then later on the removable path efi files and this is basically the m60 for removable path which is the one I'm just using as an example but it also supports the other architectures yes please the question is is that signed let me come back to that after we're done signing is its own topic doable or implemented so that binary can then for example just be our friend grew up which distributes and executes and there we go we have booted right in a nutshell on a Raspberry Pi 3 extent example again because it just was just there in qmu it looks like this you basically have auto boot time out that one searches for your for for a file it finds one it boots into grab grab loads all its files shows your graphics and well this is actually a genuine sp2 iso booting of on a stock raspberry pi 3 basically right now um grab then can load the kernel cannot an inert ide can boot the kernel can boot the normal operating system just the way it does on any other in any other architecture out there same difference not going to show you until it's gonna take forever it's all emulated on x86 system so we have SD cards implemented now we can boot from them so we are good right unfortunately we distribute our distribution using ISOs and a lot of people out they also want to do network boot so we also need to support these things so how does distribute work on these Isis was pretty simple there was a hack from I don't know I think it was it definitely was before 2000 from some PowerPC folks I don't know if it was called 3 scale at the time already who figured you know my ISO is really just like this big file which has Al Torito pieces in them which contain my payloads to boot from so it can contain multiple of these which means I really just have this thing that can be segmented into multiple other pieces which kind of reminded them of a partition table so what they did is they implemented an amazing module into you boot that basically just exposes an ISO as a partition table so that each partition is an El Torito image inside of that partition table which means our first partition now is the efi system partition which we can load our device tree and our grub foam done so all of that is already in in there since 2016 or three or so so it's stable code by now so I subdued works awesome actually the demo I just showed you was I salute now the only thing we have left is network boot I never puts interesting so network boot they're two different boot methods in in in distribute there's pixie boot and DHCP boot pixie boot is excellent not specific so I'm not gonna go into that DHCP boot however is basically what you would usually can refer to as pixie boot or as Network good so DHCP boot engage the people your boot goes in and sends a DHCP request to a DHCP server and along that also passes a to a hint a token that says hey I'm I'm an EFI payload running I am EFI system running on this architecture using the VCI that's the vendor something specific interface in the in the DHCP request so a DHCP server can figure out which file it should return so returns a file name property in its egg which we can then use to download that from a th the peas TFTP server and well executed right done to fast good all right awesome so network boot is all settled and done and upstream and works it basically works the same way as it does on an actual Tiano core system so if you have or am i film where whatever so if you have a a working pixie boot implementation that work boot implementation for EFI in your network it will just pick it up and work so what are you fight tables so I described earlier on that we have console that we have console boot services runtime services and tables so we covered all of the other pieces we can't what we didn't cover the console but it's obvious we did recover what boot services are that's all the objects we covered what one-time services are that's your and vram one-time configuration and reset and such so what our tables tables are basically just pointers to binary blocks with a UUID prepended to them that's all tables are so tables is like this list of things that you can just pass to the operating system and say like go go and eat it you can have for example device 3 in there you can have a CPI tables and there you can FSM bios tables in there there are a bunch of tables that basically just describe things that you pass to the operating system as blopps now hmm.you boot does not today implement a CPI if anybody wants to implement that in a usual environment be my guest I don't know why you would want to do that but it's possible right you can describe your heart by using a CPI tables if you want to test something or you want to verify whether your system works on both it's doable however one thing that is actually really cool with those tables is that you're moving your your device fee information all the way back into your film where because film we're now has to populate your device tree before your bootloader goes in and select anything so this does not leave any excuse to device trees that are concur no specific because you can only have one you can't have different device trees depending on which kernel you choose it actually is a good thing I think because it finally pushes device tree people into being compatible yay so another really amazing aspect aspect is that while you boot can also use device trees to configure itself so one thing that you can do and which is implemented today is that you can just use you see boots device tree pass that one into the table which then gets passed into Linux and so Linux reuses you boots device tree so you only have a single device tree to maintain one not five one it's much easier and it's much more in the idea of the original inventors so now we've heard what's all in there there's a lot of stuff missing obviously because you can't always invent the whole world at once so what do we have missing in our implementation well the first and foremost thing is is you're in the UM support so the runtime services they all right so usually when you have one time services running Linux can use them to access your and VRAM while it is running which means you need to have a device dedicated to film where that is not in use by Linux implementing that generically and you boot turned out to be really hard since a lot of these devices don't even have two storage devices that you can put things onto right depends on your price point so I basically did not have any device there that I could store anything onto well so we don't have that interface sorry we basically just don't have a boot order that you can change from from the operating system which really in an embedded world you don't really care that much about because you have a static boot or that you pre-configure anyways and you could but if you want to implement it it's definitely doable all the stuffs are there or the functionality to do one-time services and implement that it's all in you boot it's all generic and doable you just need to find a device to carve out make sure that Linux doesn't have access to it and then implement the feature the bleats uh pieces then sorry to poke data into it and then you're good another thing that's missing is well so we have this object thing right this this bucket of lots of objects that we we provide to efi binary's now usually in an EFI world you in a UEFI world what you do is you initialize the film where that creates all those interfaces and all those those protocols and buy an object and then you run some other binary some other EFI binary which for example in this case is a part of FS driver the battery fast driver can then go in and add itself to that packet of objects so that the next binary that you're running can use that object and do something with it in u-boot we are recreating that bucket on every booty of I execution so yes you can use your body FS driver you can run it it will add itself to the device to the object bucket but the next time you're trying to execute anything else it's gonna get removed because we're recreating that bucket so this is one thing that we're that that is going to change sooner or later if we're finally starting to merge the u-boot object model with the UEFI object model so that every year boot object becomes a UEFI object internally too many use another thing that's missing is you have these objects but apart from actual useful objects I would say like things that describe hardware and features that you want to talk to you you also have libraries in there so you have a an object that you can query that gives you a constant callback lob with function func pointers that do things like string Len and string compare if you really want to have those now the efi shell uses those I don't know why they don't just link things into their own binary but apparently it was really cool to reuse code from Tiano core which we don't implement so we don't have the aphasia you really cared to might want to implement those protocols I never cared about the if I shall so we don't have them you have to use your own if I blow up in the end anyways so the if I shall isn't much use in case you ever you saw it at all it's not a great show so why do you want to do all of this right I mean you came here you went all the way to to look through his slides why why would you even remotely consider to use the UEFI booting path in you boot well that's a couple of reasons why why it's interesting to at least think of the idea the most important one to me is the talent separation so you can have people that work on your hardware specifics in a completely different department company people whatever you can actually separate between people who care about your hardware specifics and people who care about your operating system specifics they can be separate entities which if you have a mesh together I need to have my bootloader and my kernel and everything has one thing approach that's really hard to to implement also one thing that I see happening a lot is that people at the value-add on this side right so if you want to suddenly implement a butterface boot support you would go in and hack a butterface module into you boot or you would do a lot of other fancy things down here so you have a lot of a lot of value add in in the film website that really is not film where specific or bought specific but more not operating systems it's not necessarily operating system specific but approach specific like you you want to you want to do something generically on your product line but you want to do this for every single board you want to have fallback boot on every board you have right but you don't want to necessarily have fallback boot implemented in on this side because it looks the same on every every system that you have so you really want to have it in your braiding system and you don't duplicate work so what happens is that people start up with you boot here and then they modify you boot until it doesn't look like a you boot anymore or they go in and invent amazing scripts that are 5 kilobytes long and nobody can review and read anymore and it just becomes a maintenance mess right if you move them over to the operating system side it usually becomes much more maintainable and scalable you can have even more fancy value-add with an EFI application so you can do graphics and all of that I do you have full interfaces to it you can move your hardware underneath of your value-add so if you suddenly want to go for a system with a stock ami firmware well there you go just do it right it's the same interface you don't have you're not bound to necessarily always run on you boot you can switch between different systems if you suddenly need to switch to a different architecture well go ahead and do it it's all generic right the same code runs on your x86 system on your arm system I've even seen the mips point of UEFI you could do it there as well if you wanted to and one day when I get around to it I am going to write a mainframe point you can for example we place even more things you can replace your operating system with a stock operating system which which is where I come into place again where I come into place again there you go I come into place again so this is what what but basically pays my bills at the end of day with you guys have the chance to use our code it's a good thing for me because it pays my bills or if you really wanted to you can use non Linux there because it's still the same interfaces if your value-add goes in before the FreeBSD loader you just run the FreeBSD loader and it runs ahead you don't you're not bound to specific interfaces on how things work left and right you finally have a chance to at least build on generic things on top of each other or if you really wanted to you could use you boot as your operating system and just built a value-add that only ever shows a CAD running over the rainbow yeah so so that you would never even run an operating system you could ride your bare metal operating system in a architecture and platform-agnostic fashion so why do you have to re-implement disk drivers to preload your five megabytes of payload every on every single board don't do that just preload them generically and then go into your busy loop that just does whatever there's there's no point in reinventing the wheel every single time right so with that let me come to the first question secure boot UEFI specifies exactly how the cupid works it can it can sign and verify every single piece of the chain it's just not implemented in Ubud right now because I particularly personally don't care all that much about the secure boot chain but they're just a personal preference all of the the code is basically trivial to write all you need to do is implement the secure boot protocol and make sure that your boot efi also calls into it and the rest will just automatically work because every bootloader that are certified as being secure boot compatible is already going to use your UEFI secure boot protocol to verify against whatever that you are secure so you could probably even go and call you boots internal shims to verify things and have all of secure boot imprinted in I don't know 100 lines of code 200 it should be trivial if you really wanted to more questions sorry [Music] the question is how do we how do we get from a film where that is used to really go away completely once you boot into your kernel to a film where that stays resident to provide one-time services what we have is we have a a marker in the code underscore underscore efi underscore one time that you put in two functions and variables that you need to have available during runtime services and these are marked specifically in the efi memory tables which get pass to linux so that they don't get overwritten later on and they also so you also have to the reason we don't just mark everything as run time is that Linux can relocate your runtime code to any other location it likes in memory so you basically need to have runtime relocation for every code that is one time one time servers capable so we have this magic there that basically every variable that you would try to do reference needs to go through a special call bank so that we can find it again but it's just look at the code it's it's much more explanatory if you look at question is does it move in a physical or virtual it can do anything it like it basically tells you you you were on address 5,000 before go and play in on two gigabytes it can do anything it just need okay's you just said that yeah why the answer is yes we have special persisting code similar to the PSC icon that also we persists itself because it has the same problem it's running in the year 3 and still stays alive during the lifetime of the operating system which by the way would be the way I would implement any runtime service I would any time I would do a runtime service that is more complex I will just make it be a PSC I call and then call into something that at least is aware that it stays in the same address space it's much easier the common was basically that a people are afraid of using SPI which I completely concur and be why would you want to have all of the overhead of this if you have a really small system if I get the right for BB is very easy to answer I don't have current numbers but back when I did the patches the additional code overhead of having boot efi support was 10 kilobytes of compiled code 10 kilobytes on a 500 kilobyte binary negligible it's basically less than less than what the compiler difference would be compiler versions having that support in there is almost no one time overhead and I mean definitely no one time over it if you don't use it and no one time out almost no one time overhead if you even if you use it and know almost no code overhead so overhead why especially nothing there an ACP I I personally don't see anybody implementing a CPI on this why would you and even if you do implement a CPI you would implement a CPI as a compliment to a device tree based world we have this so beautiful flow there where you can have you would have the same device tree as the kernel why would you want to break that up really I mean this this makes a lot of sense having a CPI is just an option I don't like to block people into anything at all right it's it's very frustrating when I see people dictating say you have to use UEFI whatever and don't read UEFI but mean this specific implementation of you if I buy this specific company right not the Kali names here this this is built around the concept of choice right if you want to use it go ahead and use it I see very little reason not to do it but if you do see reason not to use it go ahead and don't use it I don't mind but this also keep keep in mind that there's almost no overhead to it so we are one minute over with you really quick it loose okay so questioners paci versus EFI PSG I lives in eo3 so it's you basically have yo P EO 3 which is your on x86 speech SMM then you have L 2 which is hypervisor l1 which is your system mode and your 0 which is user space all of this lives the if I want time services live in in your car the same content in the same scope and you cannot listen so yield one or year to depending on your kernel PSC is all in year 3 that's the difference all right awesome so we had two minutes over thanks a lot [Applause]

Channel: The Linux Foundation

Views: 5,813

Rating: 4.9587631 out of 5

Keywords: embedded linux, embedded linux conference, linux foundation, openiot summit, internet of things, linux

Id: qJAkJ3nmWgM

Length: 52min 30sec (3150 seconds)

Published: Tue Feb 28 2017