Discover UEFI with U-Boot
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47429 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Physical systemBootingGroup actionInformation technology consultingVideo gameSoftwareWhiteboardMultiplication signWeb pageChainAreaSinc functionSoftware maintenanceBoom (sailing)InternetworkingData conversionPCI ExpressAxiom of choiceWeb serviceServer (computing)Scripting languageAddress spaceArchaeological field surveyAuthenticationIntegrated development environmentNumberiSCSIMathematical singularityFiber (mathematics)Computer filePartition (number theory)Table (information)RoutingBlock (periodic table)Hard disk driveRootClient (computing)Communications protocolInformation securityData storage deviceEncryptionNetbookIPSecFirmwareLattice (order)Latent heatBitSoftware developerPlastikkarteDifferent (Kate Ryan album)Formal languageWorkstation <Musikinstrument>Computer wormNeuroinformatikStandard deviationWebsiteBoss CorporationDrop (liquid)Kernel (computing)Structural loadComplete metric spaceBinary codeCASE <Informatik>Event horizonCodeFehlererkennungStatement (computer science)Video game consoleFerry CorstenSystem callStapeldateiMIDIAdditionPoint (geometry)Gastropod shellConformal mapDensity of statesStatistical dispersionText editorBasis <Mathematik>Public key certificateSoftware testingTotal S.A.40 (number)Process (computing)ArmBefehlsprozessorMereologyLevel (video gaming)Run time (program lifecycle phase)Interface (computing)State of matterCoordinate systemException handlingPower (physics)Instance (computer science)Operating systemImplementationCausalityVotingObservational studyComputer iconGraph (mathematics)QuicksortTelecommunicationOpen sourcePointer (computer programming)Set (mathematics)Service (economics)Network topologyConfiguration spaceObject (grammar)Type theoryAtomic numberDevice driverDevice driverData structureWeightFunctional (mathematics)Office suiteField (computer science)Revision controlMedical imagingKeyboard shortcutLaptopGame controllerMessage passingRule of inferenceProcess capability indexMatching (graph theory)Installation artArithmetic meanFile systemSound effect.NET FrameworkCovering spaceSCSIIdentifiabilityLogicPlanningPhysical lawLie groupForcing (mathematics)Object-oriented programmingPolar coordinate systemCore dump1 (number)Right angleSingle-precision floating-point formatThread (computing)Interrupt <Informatik>CoroutineQueue (abstract data type)Endliche ModelltheorieINTEGRALSubsetElement (mathematics)Shift operatorGoodness of fitDisk read-and-write headArithmetic progressionChaos (cosmogony)Computer hardwareElectric generatorMiniDiscResultantComputer configurationFitness function
Transcript: English(auto-generated)
00:09
Good afternoon, welcome to my talk about the UAV subsystem in U-Boot. My name is Heinrich Schuchardt and I'm working in my paid life as a software consultant
00:28
in the ERP and in the supply chain area, but I've been contributing to U-Boot since 2017 and I've been since beginning of last year's maintainer of the UAV subsystem in U-Boot.
00:46
And now you may wonder why I got there and this is what I will start my talk with and then I want to dive with you into the internals of UAV so that you understand how UAV really helped me to solve my problems in booting from the network. So let's get started.
01:06
So why do I want to boot from network? So I have a few little boards of raspberry size, not raspberry itself, and the fastest connector on these boards was really the ethernet port. They didn't have Zata, they didn't have PCIe and of course you could plug in a USB 2
01:25
converter to a Zata drive but a Zata drive still cost me more than the board itself and so I thought network booting would be the natural choice to carry on.
01:40
And network booting exists in U-Boot so you can set up a boot or DHCP server that will provide the address of a script and the script can be downloaded via TFTP and then you can boot from an NFS server but unfortunately as U-Boot only supports UDP
02:01
the server has to be set up that is running by UDP. There's no authentication at all and I thought oh gosh that's not what I want. And then I knew of course what we were using in our company and typically in a server environment you are running iSCSI or you're running using
02:24
fiber channel or whatever. So iSCSI is not like a number serving singular files but it's really providing a block device. So it's like just a virtual hard disk that you have that you can put your own partition table on and then create your partitions and then you will have your boot
02:45
partition and your home partition and your root partition. And it offers really authentication so the server and the client can mutually authenticate each other. It's the chat protocol
03:01
that's being used so it there's some common secrets those two parties have to use some challenge so that it's not always the same being transferred so yes you cannot not have replay attacks and if you need more security you could separate of course your storage array network
03:22
from the rest of the network by VLAN or use IPsec for encryption. So this is what I wanted to do with my board which was running U-Boot and U-Boot is one of the most common firmware for those little boards for booting. So I've looked at the specifications started implementing
03:42
a bit in iSCSI and so it's tedious and hasn't anybody done it before why should I do it myself and that's when I came upon a software called a pixie where the main developer is Michael Brown and it's just like a Swiss army knife it has implemented lots of different protocols
04:05
the origin of it was it was just a replacement ROM for your network card for doing pixie booting but now it can support booting from HTTPS server from iSCSI that's what I'm interested in can boot via fiber channel over ethernet or auto over ethernet it has its own scripting
04:27
language and it can be built as a UAV payload and that's when I thought okay on my workstation at home I'm having UAV booting my it is a six computer so does this also exist for U-Boot
04:44
yeah and in 2016 Alexander Graf at that time working for SUSE now it's at Amazon he was really starting to implement the UAV standard inside U-Boot so the driving site for his company SUSE at that time was that they wanted to boot all devices the same
05:04
way they said if we boot a server by Graf and then Graf loads a Linux kernel we want to do the same on a raspberry 2 and that's was why SUSE was interested into getting UAV into U-Boot which was running on those small boards and I said oh that looks it's complete so I have a pixie
05:22
I can compile it as an UAV binary run it with U-Boot and great that's what happened I just got a return code a bit cryptic but if you convert it to a hexadecimal and look it up okay you see it's error code nine out of resources because there was only one event
05:45
possible that was really the reason I said okay maybe now everything is there let's try compiling a hello world just writing hello world on the console and then do a return statement and it crashed again because Alexander assumed that every executable would exit via the exit
06:07
api call and that's when I really thought okay that seems to be really something that has been started but needs some support and that's when I got into this so in I started sending in the
06:24
first patches mid of 2017 when there was really it could barely boot Graf and the nothing else and in 2018 with the may edition of U-Boot I could finally really run
06:45
a pixie and boot from my iSCSI server and of course the voice was not finished there so it was still not really conformant with all the details of the UAV spec
07:01
and finally last year we got it to a point that we could run the UAV shell that is a shell like the DOS shell really primitive but you can run different binaries you can set variables you can have a small editor even in there and this is the basis that you need to run
07:20
the self-certification test that life and art had been talking about and so I have written about 60 percent of the UAV code but they were in total 40 contributors contributing to this to get it running and now you may ask yourself where's really UAV sitting because when
07:46
some people talk about UAV in the x86 world they're just talking about if it as if it were the whole bias if the whole firmware is UAV no UAV is simply a standard it's defining an API the question is where is it used so what I have put here on the board is just the boot process
08:06
this arm trusted firmware as it's running on 64-bit CPUs so where does it start really the CPU has a little ROM which is knows the first part of the arm trusted firmware which then
08:23
boots the bl2 trusted boot firmware which then runs through the next part loading bl31 which is exception level 3 runtime in this runtime you find things like as power state coordination interface which is responsible for resetting a board so they provide already an API which then
08:46
can be called by you boot for resetting a board it can but it not always does also boot in the secure world an extra operating system where you can run for instance opti
09:01
this will come in handy if you really want to have secure boot because we could use it for storing variables that is something that lian now is currently thinking about and yes of course the bl31 also loads bl33 which in our case is you boot but there are of course other implementations like tiano call edk2 like we heard in the last call and now you would or
09:27
edk2 they are offering this API which is defined as UAV spec on 2500 pages and now this spec defines different API calls we will look into and this can be used by graph or by ipixie to
09:47
communicate this new boot or edk2 and they can also be used in the linux stop for the same sort of communication so when we now start a UAV binary what is the first thing that it sees
10:05
it simply gets a pointer it gets a pointer to the system table and the system table contains different services that are available and by these services it can also discover some protocols which offer additional apis and you have two major parts in there and the system table the
10:25
one thing is boot services this is what is available until really the operating system is and when it's running only the runtime services are left over for instance those services that are necessary for rebooting or setting boot variables and there are also
10:45
configuration tables passed we heard art that he said okay currently we are passing the device tree can't we get rid of passing the device tree in here as a configuration table the servers use instead act b or and also we have an sm bias table passed and if you look at the
11:03
protocols they are really providing things like network access they are providing access to block devices so if you now look into what are the atoms really of uaf the two object types they
11:23
are one thing that is handled this is just a pointer on which protocols are installed and they are events that are triggered by time and then called back into the binary or they can be triggered by a call of one of the services if you think about what is
11:42
a lifetime of such an object of such an handle it's created when the first protocol is installed and it's deleted when the last protocol is removed when we look into drivers what will be coming interesting in a second is a driver is simply a handle which has a specific protocol
12:04
installed on it so it's a piece of software that when it's installed the handle is created if you drive a binding protocol is installed in it until you see what really protocol means the protocol is just a structure a pointer to a structure and it's a good which identifies
12:23
this protocol and in the protocol interference for instance of the if you drive a binding protocol you find there are three functions in it supported start stop and there are three data fields which version the handle of the image that was loaded to get the driver
12:41
running and the driver binding handle and on the other side of course there are the devices also in the specification sometimes called controller and this is a handle which has an ap device pass protocol and which you could use just to get an overview of what devices
13:01
really exist i've just printed out what i had on my laptop where you for instance see okay there's a pci route on the pci route there's some nvme drive and on the nvme drives there is a partition existing and the same thing also for the on the zata side this for example
13:22
just of such devices that exist there and now how are drivers and devices attached to each other in the boot services there's a call called connect controller and this one calls the supported function of the protocol finds out that there's a match then the start method it's called
13:55
of the by a driver binding protocol and then the driver is really started and it installs it's
14:03
own protocols on the controller for instance if you have a hard drive and the hard drive asks okay who can serve me then maybe the controller will install a fat file system on it and it also may create child control so extra handles it may break and if you now look into how this
14:24
foot is put into the picture with ipixie on the right side i simply have some parts of uboot so in uboot there is a network driver on the for the network driver inside uboot there's a simple network protocol exposed and there's also some driver existing if you block device which exposes
14:47
the driver binding protocol for block devices and now when ipixie is loaded and running then ipixie installs a TCP IP driver this is necessary because uboot doesn't only knows UDP
15:02
it installs a nice SCSI driver and uses this SCSI driver to connect to the server and installs on the drive that is connected to a block io protocol and then calls connect controller and this connect controller then reaches out to the block device driver and uboot which then uses
15:26
the fat drivers that exist and and the logic for identifying partitions to expose a simple file protocol and this simple file protocol then can be used by ipixie to actually load grub or directly load linux and essentially grub then will do just the same thing grub will when it
15:47
tries to load something it will call the simple file protocol which internally calls the fat driver the fat driver because if you block driver which knows okay i'm connected to that handle with the block io protocol which links back to the SCSI driver the SCSI driver
16:03
by the TCP IP driver calls the simple network protocol driver and then loads the different blocks of Linux and of the initial ram image that is how these all go together i have here
16:26
a short movie oops it will get it so that's where it's actually starting to boot so here i first of all uboot tries to find its own devices like usb devices it finds its
16:45
sd card and then the script is running which simply loads iSCSI and known as ipxe oops ipixie it loads grub and then grub just continues as we know it to load the linux kernel
17:12
so um yeah for me the takeaway really was yeah by providing a common api we really can run
17:21
standard software there on uboot which before that we could only run maybe on the pcs that had an uefi bios or which was running piano core or whatever and now suddenly we can run things like grub right at pixie so when they think about okay what was problematic in
17:46
doing all this the one thing really that was nasty about uboot is that it's running single threaded it has no network interrupts and so especially for implementing events in lots of
18:00
different places one really had to call back into some routines that would handle event queues and no he was waiting for an event and call those functions so that was one part of the nastiness in it another thing is uboot is more than 10 years old and of course it comes
18:22
with its own history and the model how drivers are implementing uboot is currently changing it's trying to get more modular this new model based on device trees installed inside uboot but it's not used everywhere and this really stops us from getting a very tight integration between
18:44
the uefi code inside uboot with the drivers it really sits more on top of it than being really well integrated and that's something we will have to work on once we get the driver model really firmly established yeah when we look into what are the development targets for
19:06
uefi inside uboot it's not the idea to implement all those 2500 pages and then come up with a binary which is several megabytes long the target of uboot has always been should
19:21
boot on a very small board and this is why we will only implement a subset of uefi there has been an effort led by arm to define a restricted subset which is called the embedded base boot requirement specification which is available on github which requires that you have
19:45
okay the was a boot service in place you have the runtime service in place and there's one chapter which defines some other required elements that you should have and we really want to stay small so i often get complaints the uefi part is already growing too much currently it's something
20:01
like 70 kilobytes in the firmware and your body will be happy if it gets much bigger so what have you achieved last year now we have all those all boot services in place we have had as i said we were able to
20:24
run the uefi shell which allowed us to do self-conformity tests and this is conformity testing using the sct we were able to fix a lot of differences to the specification especially
20:43
conformance issue where we're not checking incorrect variables being passed and yeah we can run the efi shell on arm on x86 we can run the sct and now let's finish off with what is work in progress we have just merged a work by kristian to a cult here um so that we can have a verified
21:07
boot which is based on fit images there's um linao with um takahiro akashi working on uefi secure boot um what we already have merged is um uh support for hardware run um the number generators
21:28
and um so i'm confident that we are improving a bit by bit thanks a lot for your attention and it's up to your questions yes please no i um the question
22:02
was where is i pixie located i personally always loaded from the afy partitions so i have an afy partition um we have this on and i have the device tree on essentially i have the firmware the device tree and i pixie on my sd card yes and everything else grab the kernel and the
22:26
rem disk is then loaded via isca yes please yeah it's essentially what is in the ebbr
22:40
what we want to have so the question was which parts will be implemented and that's that's why i mentioned the ebbr and we we have implemented some extra things that were necessary to run the shell and to run the conformity tests because they require some
23:00
protocols that are not in the ebbr yes please in principle you the question was can we really run
23:27
extra drivers we have everything in place but i have not seen any implementation where we using this so currently for in u-boots there are drivers for all sorts of storage devices and
23:41
for a network and for usb and we at least the network and the storage devices we are exposing via uafy protocols without any extra driver having to be installed but if you say there's some sort of special device which you want to expose then you could load a driver that you
24:02
have written yourself yes this is in place yes please it's a configure out parts of the uafy back the question was how configurable is the way the subsystem there are parts or the if you
24:30
look into the configuration of u-boot it's like configuring a linux kernel we are choosing just the same kconfig system and some parts are optional that you can leave out or you can
24:40
completely eliminate the uafy subsystem if the board is really too small so there are some boards that only have a place for 300 kilobytes of firmware and there you cannot have a wavy subsystem but if you have 600 or 700 kilobytes it will well fit in yeah then thanks a lot for your
25:09
attention