UEFI Boot for Mere Mortals

welcome everybody thank you for coming our talk is UEFI boot for mortals so I appreciate you all that coming out at noon for a talk on UEFI that shows a lot of stimuli I know lunch is right around the corner so I'll try and keep this mostly brief pushed off a little bit about us my name is Stefano I work for Intel and currently the Tiano core community manager and I'm also an open source firmware and hardware advocate I was a nerd way up next he is the KVM the QEMU developer for Souza and he's one of the founding members of the Susa arm team so let me start off with a quick demographic check how many of you like me six months ago think of UEFI and you think of a blob 5 to 10 megabytes that lives in some flash web part somewhere that's really complicated good I'm in the right room ok so let's start with UEFI then it turns out UEFI is actually just a PDF so that's what I want you to think the next time you think of you if I UEFI is a series of PDFs and if you are looking for a sleep aid I would highly recommend reading the entire thing but really you can use it as a reference for how the specification of UEFI is laid out the definition is actually in several parts so platform initialization is one of the things that's defined in its own specification you and runtime interfaces are defined a CPI which is its own talk than which I am not qualified to give is its own specification and UEFI shell is another specification so when you think of these things don't think about implementations think about specifications that define an interface a way to standardize and calls in to hardware and that gets me to what the point of UEFI is which is really standardization and it's the standardization of the transition from hardware into some payload and that payload could be grub it could be Linux it could be lots of things but the transition from hardware net into that payload is what UEFI is all about so let's talk a little bit about how that process works how many people here understand what a reset vector is okay good number excellent well for those of you who don't know once the magical world of hardware has done the thing it needs to do it's going to pull the reset line low and that's its way of saying hey all that stuff I'm not gonna tell you about is done now and there's a pointer to some well there's a place in memory where you can go and it promises it will start executing instructions assuming it did its job right so UEFI is concerned with what happens when you get to that place what do we do next it's concerned with the most basic fundamentals of hardware acceleration like DDR memory initialization so getting the timing right making sure that you can write something to memory understanding where the media is that you're going to boot from and initializing some silicon specific stuff like you like PCI or USB or even simple stuff like you arts so that's everything from the hardware end and you can sort of think about that in terms of the initialization of the hardware then from the play mode end there needs to be a way to look back into that firmware sort of a thin interface to look into the hardware and make calls and that's where UEFI comes in it creates these standard definitions of how do we do things how do we call back into that firmware so sign capsule update is one of my favorite examples because I think it's one of the less known features that UEFI enables so the LV FS which I've written down rift and Linux vendor firmware service is a really exciting thing that you should go look up because again is its own talk on its own and Mike Kimmie from Intel did a great talk recently on that Lenora connect HTTP boo if how many people here know it EXCI boot is excellent I really him in the right room we would really like for that to go away and for those of you who go away an HTTP view is a great way to make that go away graphics output protocol just another good example of how we standardize something like how you interact with a frame buffer but these are all ways that that payload that I talked about can then look back into the hardware and make calls and in some standard way so that you don't have to roll everything from scratch you can know this implements the UEFI spec I can know what to expect and it's important to remember too that it doesn't the UEFI spec isn't an implementation it has no interface it tells you how to write an interface and that's an important point so I don't want to spend this entire talk talking about UEFI because there are other really important boot loaders out there coreboot and simple little things that again could be their own talks but things that you should go out there and look at and there are corporate people here in the room so please throw something at me if I say anything bad but the idea that I have in my head when I think about things like core boot and some blue loader is if you want to get to your payload as quickly as possible the minimal amount of hardware in it that you really need to do to get the memory initialized and to get yourself into some payload that's where coreboot really shines so if you're looking for a quick handoff to some OS those may be Linux or some boot loader who knows maybe grub that's the thing you should be looking at the idea is that you're booting the LS you want as quickly and efficiently as possible UEFI really thinks more along the lines of what if you wanted to boot a whole bunch of operating systems how do we make that efficient so this is the slide I bring two things up on the screen which many of you probably aren't used to seeing which is UEFI in you boo and this is why I have an expert over here with me I can't talk to them very well but I can't talk to Tiano core so hardware digitalization done in such a way that it isn't minimalistic that you really do want to have something more robust where you could have networking and you could have USB capabilities providing boot time services and allowing firmware to be updated and as I look at this slide I realize easy may want to be in quotes these are things that are all that we attempt to address and one of the things that we really wanted to do with this talk is so with the ways in which both of these pieces of firmware are really great choices for different things so don't think of them as competing software they really are trying to accomplish the same goals just in different environments so for one example you boot has been open source since day one channel core was open source in 2004 for those of you who have ever tried to open source closed source software you will know that it is a tad complicated and so when you look at the code as Frank Sinatra said please be kind it's things that you're going to have some issues with but realize that it is the effort to drag that into the open source world that is our goal so from the channel core side you've got both platform initialization so we do the hardware part and we do that to the UEFI spec and then we also do I'd said that word I say thank you to the PI spec I'm clearly gellick to many acronyms so we do that to the urea they'll hit three times before I'm gonna promise you boo on the other hand does implement the parts of UEFI that are necessary but just enough so that when you look back into that firmware you see the things you need to such up the payload will know I'm in a UEFI compliant environment there are numerous platforms available for Tiano core and we'll get to that in a different slide but as most of you will know there are an amazing amount of platforms that run you boo so there's a huge feel to play in their UEFI shell is implemented in both and that's the slide that I'll get to later on - so etk - coming to the part that I think is also somewhat misunderstood edk - is a number of things it is a build environment it's a place where you can build a reference implementation of UEFI firmware it is not the actual firmware that you're putting on the board though it does contain it so there is open source firmware code inside the edk - repository but like with many complicated projects like this it's hard to put a pin on with all of these words mean because you have things like unify and etk - and seattle core and you just want to know what to call the thing you just build but the thing is built is custom firmware so the fact that the open source firmware is in the repo makes it a little more complicated but the thing that I think is really great about the about this repo is that it has a number of different large corporations contributing to it and as you all know large corporations are really good at working together so clearly it happens seamlessly and there's never the arguments or problems and all the crickets merged flawlessly to combat that effort we have the open source community that I am working to build and we'll talk about that in the next slide one of the things to know is that et k2 has fully validated UDK releases but you can also work from the master branch obviously and then also several stable branches that we release we release the stable tags on three-month cadence the part that I actually like to talk about because I feel like a little bit of an expert is the theatrical community because that's the thing that I'm trying to push I've set up monthly community meetings so that people who were engaged in working on the software or just interested in learning more can come and ask questions we usually have some of the experts in the world of UDK too and you if I present so they could answer questions or we talk about topics like how do we improve our mailing lists how do we communicate better as a community I'm going to be setting up when I get back from this event bug triage is so that we can go through Bugzilla in the public sphere and say here are some of the things we found here's some feature requests here are some bugs that we're trying to fix and that gives the community opportunity to pitch in with the project that is often looked at has really just stuck in the domain of corporations and we're also working to build a continuous environment a continuous integration environment and we're trying to do that in a community oriented way so I'm working with people from Corbeau and Linux boot and with people from new boot to try and make this something that is a community effort to do CI rather than just going off in the corner and doing it ourselves I want to talk briefly about utq two platforms so I mentioned that there are some platforms that Tiano core can natively support and EDC two platforms is our way of trying to pull some of that code out into its own repository so specific hardware like the Beagle bone is available there will be available there shortly the stable branch is their track the UDK releases so those completely validated releases get tracked in stable branches and then we currently have development branches which I will admit need a lot of cleanup but if you're trying to get that Hardware booted just so that you can play around with it the develop the development branches are perfect just for that purpose if they need a lot of work to that so some of the boards that we're looking to to get going obviously the BeagleBone black as I mentioned is something that we're going to be working on and up squared board which I'll talk about briefly is something that I'm personally excited about and macchiatto been and I some of you've heard of the minnowboard project which is a continuing project and that we hope to continue to support so I'll talk briefly about to the an up square board so the up squared board is really interesting it's got a whole lot of really fun i/o and it actually has a max10 fpga on it so there's a lot of possibility in this board and we currently got a booting Tiano core as of version 2 oh okay yeah so it's been up there for a little while so this is one of the things that we're trying to further we realize that we have open source tooling we have an open source code base but we need some the form of hardware that everyone can afford that is readily available that we can give people to test on so an obscure blur is one of our first efforts in this area but we are gonna continue and try to push other boards as well the idea being that we know you need something relatively cheap to put on your desk so that you can play around with this stuff so this is one of the boards that I'm really excited about there a couple other that I'm looking into that I won't talk about here but catch up with me afterwards and I'm happy to chat about so with that I've talked a lot about UEFI and about UDK - I'd like to have Alex come up and chat with you about either Thanks so I'm the the upstream UEFI u-boot maintainer which means that I take care of the UEFI implementation parts inside of you boot so who of you knows what you Buddha's very nice who of you understands what the bullet points me so important what one important piece that's intrinsic in Ubud is its it's a very open salty project it's it's all GPL code HS code with Linux even in a couple of cases and you can really think of it more as a as a long stretch boot pace arm of Linux almost right it's it's it's a very open source intrinsically open source community based product a product that project the idea of you good has always been to be as small as you can and as fast as you can so you want to be out of the boot phase as soon as possible which means you want to be really really quick and small one of you it's amazing features is how can boot where you basically do pretty much nothing until you you're up in in in Linux land which is a similar goal to what core boot is trying to do which basically goes hand-in-hand with where it's targeted so you booth is really really big whenever you get to embed it appliances where you have vertical integration of the whole stack you want to just you you want to control what your boot environment us because you don't want to have that throw anything in your face while you're running which usually happens on normal actually six big service because vendors happen to add amazing new features into the S&M mode which happens to run while you happen to run operating system and suddenly you're losing real-time mobility you Buddhist is trying to avoid any of that you trying to get out of the persons as fast as you can which means it's ideal for an embedded appliance you know you can if there's a bug you can fix it because all open source and you can you do control what happens which means if you if you find any latency so issues you can you can actually solve them it because of a teratogen the little community and people around there the whole coding style looks like Linux so if you are a Linux developer contributing to you Buddhist trivial right it looks the exact same basically it's you will know how the code works within minutes and traditionally you would has implemented very direct boot mechanisms like for example the direct Linux boot where you just implement the Linux boot protocol so you can hand off really quickly to Linux because that's what the boot loaders job is supposed to be right and out really quickly to the operating system it has its own you good API which some people use so example some bsds use the u-boot api to implement whatever that file system is called and ZFS drivers and whatever additional drivers to to that they cannot pour it into a GPL compile code base in a payload or they didn't want to have it tainted by GPL so channel : the other hand is basically the way I usually put it it's it's it's built to fork right you you it's it's the whole purpose of channel core is that it's a base for people to take and build their own thing with and then ideally never contribute back we're trying to I mean people are trying to change that right it's but but but if you if you're an HP you you don't really want to push your HP nail man back into some open source project because what's your value add what's your what's your revenue stream for getting open source firmware in there right is that's that's very little incentive for them to do so there's a lot of incentive in enabling communities with those we're by having upstream enabled support such as what we're seeing in channel the channel core community now but in I would say 99% of Tiano core based systems out there film we're out there is eventually in a closed source environment it is much bigger than a typical kyboot Lotus because it supports way more interfaces it actually has amazing features in there right Stefan I was talking about HTTPS boot we don't even have TCP support a new boot not even speaking of HTTP or HTTPS right this is a full-blown operating system channel kora and edk to the UK to the words are terrible the the Tiano core community has support in its cdk2 project for a lot of amazing features because of that heritage where it allows you to really do close source firmware this is the big market it's in right if you if you get if you're getting a random server today it's probably going to run some code from this codebase maybe not everything of it but a lot of code from the indicator cope a coding style wise if you are used to politically correctly saying camelcase code you will feel very natural in in that UEFI like environment in the in the unity on a core environment whereas if you from a linux heritage i cannot read that code yeah life isn't either so it implements a lot less interfaces because media at the end of the day what you need to implement is this is wrongish a-- ppi it implements the the front-end interface to have boot loaders and and anything above running interfacing to to your to your UEFI standard firmware and implement drivers that's basically it only lists in a UEFI only world where you boot lives in in this weird state in between at this point and so what's the whole point of adding you if i support to you boot then right why do we want to blow it up with code you actually give us something that we already have in my temptation for my why do something more well turns out abstraction interfaces are a good thing because using this small UEFI information it's not feature complete it doesn't print everything everything from the spec but it implements enough to boot into Linux to boot into BSD to boot into grab it at most things you want to run except for Windows work just fine because both implementations implement the UEFI spec to that point you can then have the exact same boot flow regardless of which environment you live in if you have a you could based environment you can just run the exact same binaries as you can on on a you if I on a DD k2 based system and see even I get the words wrong so this is all possible because we basically have this abstraction interface and this abstraction interface is what the UEFI spec is all about and what you see down here looks artificial but really what it enables you is it enables you to boot any standard distro that you want and I just happen to care about the openSUSE what any standard is to you one regardless of what is there on the upper layer it really just is an abstraction integer right it's imagine it like the JavaScript engine for for for firmware so what this leads to is the really nice benefit of it is the number of maybe the overlap of machines that each fill my runs on there's very little overlap between the two right so the typical system it's that you have a Tek to based system on it's not the technical system you have a you wood based system on so by enabling the exact same interface you're suddenly broadening you reach by many full right you you can run on pretty much any system these days but it's either x86 or ARM based without even thinking about all of this booting stuff because people really don't want to be in a business that just happens to be a difficult but we don't want to make this difficult only be as easy as possible so with that you more than happy to conduit to either one or the two or even both or just I mean jump between worlds it's always always a great thing you can reach Stephano I'm here with those credentials the Bayliss of their patches are always welcome to everything if you want to implement some cool new feature make Windows boot on you it's it's a great thing to have and now we have about four minutes left for questions because I'm sure you will have some yes [Music] how's progress for the you if I want m7 is going on you boot it depends on you consider progress so the we we have had if you if I want time services from day one so that's always been wantin service because without one time services Linux will just call into null pointers you have to have something there admittedly most of these runtime services implement error which we turn in - error and not implemented and that's it there there are two things that we're doing one is as part of the ebbr initiative the embedded base food requirements farm we added an ECR to the ufi spec which allows you to not implement one-time services so it's you you would finally become spec compliant but not implementing them so you if you can't change i mean if you if you don't want to you know you what's what's there the mountain and the profit thing in english you know you know what I'm getting to so so that once the ones there and the other one is we have a lot of infrastructure to implement one-time services but it's not as pretty as it should be in in new boot right now and it's intrinsically bound to the way you want time services are done it's just a key there are some suggestions on many is today even just just from this week on how to clean all that up that maybe we should build another tiny version of you boot inside the build process that only comes with a small device model and only the devices you need for one term services and then you embed that into your bigger you boot and you make that your intensive as well you running we all have to see how we how we get there right I think we eventually you will want to leverage some of that infrastructure we have a new boot for one-time service today we don't it's just function overloads and in couple sections that you put stuff into but you can't do one term services if you want to yes which architects to be support in Tiano core or in you others one of the main contributors to to the ek2 copay so he you know all these pieces a new boot currently we support x86 32-bit 64-bit arm 32-bit and 64-bit RISC five 32-bit was five 64-bit yes I don't think anybody went into MIPS yet we do have people who understand PowerPC so let's see yeah can you want you with functional core course you can now you can you can run either from either just whatever this is yeah and anything anything goes you can you can have you would be a an actual payload on an EFI payload you can have you would be an EFI operating system which kicks away et k2 and takes over the machine at which point you can then run EFI applications from you but again the whole world is open to you what's the difference between 22 and that was what Stefan I was explaining it's very easy you know Tiamo core is the is the umbrella project right that's that's that's basically than the name for the overall arching project indicate you is the toolkit itself that allows you to build firmware and the film of that falls out of it doesn't have a name in a nutshell yeah any other things yeah if I like what is what is light the UEFI spec is it's not quite ten thousand lines at a ten thousand pages here but it's getting close it's it's big right so light basically implies everything you need it's not it it implements enough to make real-life use cases from today work so that the approach is different the indica two approaches let's give you a reference imitation that influence everything that there is in the spec whereas the you would approach is let's look at what people actually do use today and what they do need what what do we need to make Linux work what do we need to make Rock work what do we need to make to make to make beasties work and turns out all of these have almost the exact same requirements this that's very little you don't you don't need additional protocols you don't you don't need the human interface interface or whatever it's the hie databases and such to to just make group work you do need it for the UEFI shop so we haven't known you good because you can now want the UEFI shell but there's a lot of these really arbitrary real protocols that nobody usually runs except for very specific targeted workloads that I haven't seen yet also you are missing out on any on most parts that make up the whole driver environment we do support some of that so you can hang me for example at add amazing code you can in you boot you can run I pick C as an EFI payload which provides a UEFI block device which gets merged back into a you boot block device inside the you would layers here the compound layout so you can use you boots partitioning code and you would file system code which exposes a UEFI file system protocol again to so that you can use that to no driver to turn of binaries throughout all those layers so we have we have some driver parts well we don't have a PCI abstraction layer for example that the whole stuff just doesn't exist that's what light means light doesn't mean it doesn't boot you it might just means things you really don't care about

Channel: FOSDEM

Views: 2,757

Rating: 4.909091 out of 5

Keywords:

Id: 6jt1nNWAwEk

Length: 28min 32sec (1712 seconds)

Published: Sun Feb 10 2019