 those as well but I've been informed that some of them may not work so I will just distribute those and then in a process maybe we will have some work but I am not sure so if you have laptops and you want to follow it's like 2.3 gigabytes the second file is a BIOS binary and then a third file is a startup script basically all you have to do is just start the script it will start QEMU KVM virtual machine with the disk image provided and BIOS image which is also on the flash drive so hi guys let me introduce you to this workshop which will be done by Michal Sekletar and it will be about introduction to UFI application development please ask questions Michal can give you these carves if you are active enough so please do also evaluate the session you can let us know about your opinion on Twitter or post a blog also I would like to remind you that tomorrow is great contest and in the end of the DevCon and you can get some awesome prices like Raspberry PI, UB keys which are for you know that's also please enjoy thank you for the introduction so yeah that I will get to that okay so let me start with the first slide which is basically your question yes I mean it depends it depends on your firmware and your platform I will take no responsibility for any brick machines during this workshop so that's why we have VM image and we will be doing the work in a virtual environment because yeah I mean it's every time you interact with the firmware it may work I mean it should work but in a real life there are some vendors which screw up and then you will break your machine so first every time you do something like that like I don't know writing to EFI variables or updating the firmware check first on on the forums on them and on you on OEM or manufacturer website whether it is safe because I can't tell I can't tell it depends on the platform so yeah we will be we'll be using the VM image because it is it is safer to do it this way so like I said on that on that flash drive you have three files so it's basically the disk image bios binary and startup script script is that simple it's only just shorthand shortcut to call QEMO so yeah let me first tell you what will be the contents of this workshop so the title is introduction to UEFI development which is sort of a bit misleading because it is not only about the development because I don't think it like makes sense to do some life coding in this workshop I think that and it doesn't make sense to do that as well because I have no idea who actually has some prior experience with UEFI and C C language and has well basically some prior experience with programming so that there will be some something like development work at the end of the workshop but before that I will I will start with some other things so first I will show you some secure boot demo then I will talk about briefly about legacy BIOS I will clarify vocabulary a bit I will be using in this workshop because there is a lot of terms floating around everybody is using similar terms to address different things so I will clarify what I mean by by what basically then I will talk briefly about UEFI then I will talk about secure boot more and actually show you step by step step by step how you can how you can basically take over your own machine because okay so how you can take over your own machine and how you can use secure boot for your own benefit and then we will get to do UEFI development which will where I will address like how to how to set up and basic environment what do you need to actually write hello world application which can run directly on top of the firmware what the built tools what what other tools are necessary because it is a bit different than well basically the C GCC normal workflow this that image contains secure boot stuff as well as so so you can use it for secure boot setup and the demo and UEFI development tools are also installed and inside that image in a root home directory root user home directory is actually very small UEFI applications basically hello world example and that there is a script which will set up secure boot on that on the VM so that that image should address like both things secure boot as well as UEFI development so okay I will start with the demo because I think it is at least I think it is interesting to see first where we want to get to and okay so let me ask who knows what is secure boot okay couple of people and who thinks it's a bad thing or who okay so I will use the same basically the same script as you have so I started the VM so this is my this is the bootloader environment that is actually system deep boot loader so I have fedora row height in in that image so let me start row height hopefully it will start and it should be quick because it's system the inside yeah it's quick by the way password for a root user is red hat and there is also test user and the password is the same so red hat okay so like I said in a directory of the root a user you can see hello world example then there is a secure boot demo and some Fedora CA certs you don't have to be bothered with those I left them because I would like to be able to boot kernel signed by Fedora signing keys so and if you accidentally delete Fedora key it's not that easy to recover that key because well it's just not that easy okay so secure boot demo now let me show you that currently okay so for system deep boot loader we have a command line tool called boot CTL it has couple of top level verbs basically like status install update and remove if you don't provide any parameters it will do status so it is going to tell you which version of UEFI from where you have what is the current secure boot mode and couple of other important informations so as you can see my loader is system reboot and yeah and secure boot is actually now disabled and platform is in setup mode what those things mean I will get to that so I will just run okay so yeah it requires test setup script requires one parameter it is just it will be used as a part of a distinguished name for generation of certificates so it generated some certificates maybe printed some debug output and it enrolled keys into the firmware as you can see I have couple of keys enrolled and I have Fedora secure boot CA key enrolled as well so I don't have to resign my kernel L and all kernel modules yes they are actually enrolled in a EFI firmware so now I should have I should have system reboot x64 EFI and that is actually you'll see here is the unsigned version and here is the signed version of the bootloader so I signed bootloader with the key I just generated basically and now I can I can copy the bootloader the final destination which is boot EFI system D so I will overwrite what's currently there okay that should be it now if I reboot the machine okay so first thing I was able to launch a bootloader that's a good thing because now secure boot should be enabled and enforced so that means that my bootloader is correctly signed with the correct keys so I can now launch Fedora row height and it seems like okay so it started up so that means also that Fedora keys is properly enrolled in an EFI firmware because I didn't do anything like resigning of the kernel so Fedora keys is in there that's why I was able to boot that boot that kernel and now if I run boot CTL I can see that secure boot is enabled and I am actually in a user mode I'll cover secure boot modes during the presentation so now I can look in a system key ring and I should see that yeah so I have my own keys and Fedora key in a system in a system key ring so no Microsoft key no Lenovo key no no no other keys than this so no one else is basically able to to load any malware into my into my kernel basically no also no bootkit malware should be able to succeed on such a setup because unless somebody stalls my keys right and the sign smaller in my keys okay so that someone came again I didn't get that secure boot is enabled and the setup mode is used by this binary well it reads you know it by looking at this it read source on the screen I mean it does this not in lens you well it depends you have to trust your firmware right because it's firmware is telling that basically via the EFI variable which is exported to the kernel and and kernel exports that to the user space special file system so if you don't trust your machine vendor use I guess you are screwed anyway right whatever you know yeah I mean all this all this trouble just to still have to trust something yes of course you have to trust your firmware vendor and your hardware vendor if you don't trust Intel and if you don't trust Intel then running anything on the processor yes of course because I mean I don't know what is running in system management mode I can't tell and system management mode can run basically any code and even operating system doesn't know what is running so if NSA has begged or in Intel hardware and some code is running in a system management mode the problem may be in software which you already have you think that this is it's only trusting these keys and it shows you these keys you don't actually know it by when you type of course you didn't check all the megabytes of code between you and no no no so we go through years and I don't know how many many years of development or what I don't necessarily agree because I mean you are good secure boot is a protocol for building a chain of trust and the chain of trust has a trust anchor and if you don't trust your trust anchor then I mean right on your your own firmware and your own hardware I don't know I mean you have to trust somebody at the end so yeah question yes of course because you have to also verify the compiler for VHDL or very long or something you are using to design software yeah of course so but at least if you if you accept the premise that firmware is not lying to you and your firmware vendor doesn't put backdoors in the firmware on purpose then you can you can be sure that for example now even somebody hacks my machine and will run some malware under the root it can't install it can't install kernel modules without my permission basically if I okay now I have signing keys on that machine so I would have to of course took signing keys to some other place safe place not to leave it on the machine that's that's of course just a demo setup we have here but in a real life you would have to secure your signing keys and then well you have several hundreds of kernel modules already you never reviewed their source of course and what they do and maybe one of them already has something and they are all signed so in second module for your I don't know USB keyboard and there is there is something you didn't know yeah of course but I mean if you don't trust anyone then you don't have you can't use any software today unless you write it and even then you don't have any any any means to run it because you don't trust the platform where you run it so yeah that's what I'm saying you already trust your kernel modules so why all of this signing nonsense I don't have secure boot here I don't expect it here to magically new modules to appear with viruses and I don't think that's I don't think that's necessarily a good thing to to trust that you will be so lucky that you will never encounter any rootkit malware I mean you can't trust that it never happen it will never happen to you but you can take a measures to make sure that it never happens to you so that's the thing that's the point right I don't know anyway okay so that was the demo let's go back to the slides so yeah I will try and summarize some facts about the bios and also clarify what I mean when I say bios firmware UEFI EFI and whatnot so basically by legacy bios I will be I will be addressing a type of the firmware which was pioneered basically by IBM and it was standard in all IBM PCs since like late early 80s early 80s basically so yeah and actually the interesting fact I discovered when I was doing the research for this video this workshop that IBM wasn't IBM PC wasn't first computer which used like bios like firmware there is this sort of exotic and very old operating system CP CP M which was running on a computer which actually had something like bios by IBM bios firmware even before before that so maybe IBM took some inspiration from from that I don't know I just mentioned it on the slides as interesting fact so yeah so IBM pioneered this concept of of of bios as we as we know it then couple other vendors implement basically the same thing they reverse reverse engineered what IBM was shipping on their computers and implemented similar set of features similar set of interfaces bios is quite old actually it is here from from late 70s to 80s and up to late 90s basically and even today you can you can see computers which use which usually have like legacy bios non UEFI based biases problem with the bios is that it is written in assembly and even if you want to extend it you can buy some license from from some some vendor like of art bios any bios couple other vendors are around so you can you can buy a license they will probably give you the source code like assembly assembly and you have to extend it also in assembly the execution environment is not that great I mean it's running in 16-bit real mode and it's you can address like one megabyte of memory and that that's it pretty much I mean there there are different implementations different vendors these days so it's hard to generalize but well that's that's probably the the limitations which apply to almost all of them basically so what actually bios does so you reset your machine then after the reset CPU will start executing some code defined by reset vector that will probably do some some basic CPU initialization and then it will run something called post power on self test basically it will initialize chipset main memory video adapters other hardware you have like PCI PCI subsystem USBs USB these days and whatnot then it will it will continue with boot device selection and then if you are lucky and you have some something you can boot from it will actually load the OS loader or operating system basically these days on Linux machine it it will usually load grub or part of the grub which then will load grub and usually it includes setup utility where you can do some basic system configuration and configuring hardware subsystems stuff like that okay so problems I already mentioned that execution environment is not that great problems other problems are that bios doesn't scale really well Intel engineers in in late 90s late 90s when they were designing itanium platform they they basically saw that there are issues of running really primitive sort of primitive code basically on a new 64-bit machine which itanium is or or was and so the bios just doesn't scale well on big iron machines like big servers which was the plan with the itanium yeah and it's proprietary multiple vendors but still most of the there is no open source implementation I know of and there are no standard interfaces so I have no idea how they how they how the vendors communicate or what they do but I don't know I guess somebody implements something first and then the other vendor comes along and reverse engineers how is that functionality done and does something similar so now something about UEFI so UEFI is also type type of the firmware but it is not it is not legacy legacy bioscode from from the vendors which were displayed on previous slides it is completely new thing new implementation of the firmware so why should you care probably runs on your laptop I don't know who doesn't have in this room laptop if UEFI I guess almost everybody oh everybody has it's extensible and it is standardized so actually you you're on your own you can develop extensions to that firmware and it's written in C and another good thing is that now we can see that some cooperation between OEMs and industry vendors is is formed basically they still compete with each other but at least they can sit around in one room and decide what they want in their basic platform so you take two completely different computers and you can be sure pretty much that at least what is in the UEFI spec will work on both of them and it doesn't doesn't really matter who who develop who menu of who is the manufacturer so yeah bit of a history about EFI and UEFI so UEFI stands for unified extensible firmware interface and its predecessor was EFI that is the thing which Intel Intel people wanted for their itanium platform so in late 90s they they developed EFI which eventually involved in evolved into UEFI that is the name of the specification as well as industry standardization body behind the specification so it is formed by by big companies by the vendors and it has different work groups which then have some subgroups and each group is responsible for part of the specification and from time to time they get around get together and really is a new version of the spec and the newest version is 2.6 from January of this year so UEFI based firmware goes through the different steps while basically booting your machine so I will briefly very briefly cover what those steps are maybe some of you already seen this picture because it's used so many times but it has been used so many times but I think it really captures what are the main main phases of the system boot in in a firmware which is based on UEFI so so we will start here with the first phase which is called sec or security phase this is the so basically one once the machine is powered on it will jump into some code which basically verifies from where the firmware itself is stored it verifies the integrity of the ROM then we transition to PEI phase which is pre UEFI initialization phase and in that phase we are still running from ROM out of flash execution we don't have any main memory so we use so that code which is running is part assembly and some part already in C it has to use CPU caches as as wrong on Intel platforms I'm not sure what arm-based platforms do okay so basically every platform uses what is available and that will be okay thanks so but the main point of this phase is basically in a slice memory we programming without memory is hard and that's why we want to have like main memory available for the rest of the system boot then we transition to and we transition to driver execution environment like Dixie phase and in that phase both of the firmware code is basically running the biggest portion of the firmware code is running in this phase and in this phase we execute Dixie Dixie drivers which implement architectural protocols which are defined by UEFI platform initialization specification and then we dispatch all EFI drivers and those drivers provide us with EFI or they implement EFI protocols which we can then use in in applications so and then we transition to boot device selection phase and then we usually we either start up some operating system loader or we can load basically operating system itself because Linux these days carries like EFI stop loader in a kernel so kernel binary can can basically masquerade or or trick firmware into thinking that it is itself EFI binary so firmware can directly launch Linux if we don't want any bootloader or always loader and EFI specification basically only covers this blue strip UEFI interface so that is the main interface to the to the firmware okay so I basically covered all this so now now we have basic understanding what UEFI is how it roughly works I mean to describe it in detail it's too much too much work and the specification like the specification of the interface has almost 3,000 pages and there are a couple other specs so it is thousands and thousands of pages so I will I will be not not covering anything else because I don't think it makes actually sense to do is to do it here so are there any questions about about this part or comments please feel free that's a good question I have no idea maybe somebody else can I answer that I actually never tried that so I don't know I can't tell does somebody know if it is possible to be to boot 16 bit code I I would be surprised but so why did you ask just out of curiosity or you have use case for this mm-hmm sorry I I don't know I don't know oh ACPI ACPI is it like I'll just so dot org specifications so here are the all the specifications which are produced by UEFI forum and ACPI specification is separate from UEFI specification so but it is very very related or I mean it is produced by same group of people basically I would say those two standards like co-exist together but I don't know if it answers your question we can I mean I haven't really studied what's what's in the spec in the newest version I actually found out that 2.6 was released like a month ago so but it doesn't seem they changed that much it seems that it is basically the same thing and as it was before yeah but what to answer your question ACPI is separate separate standard so it is not it is not described in this document but it is separate you can I honestly don't know no idea whether that's mandatory or or vendor extension I can look for ACPI there is a couple of matches yeah so seems like they ACPI table tables are there is a protocol defined by standard install ACPI table uninstall are the methods of the or parameters that that will be mandatory I think okay so now I will cover one specific protocol which is secure boot I picked secure boot because I think that there is a lot of misinformation about secure boot in a Linux community and Linux users are sort of I don't know sensitive to that subject so I picked it on purpose sort of so we can we can discuss secure boot issues here so yeah so basically what secure boot is secure boot is protocol described by chapter 30 of QEFI spec and basically it is a protocol for building a trust relationship between between the components which are involved in a boot process so it builds trust relationship from the firmware up to the operating system and each component in that trust in in that chain of trust basically verifies the next next component in the in the chain so that's that's in a nutshell the main main idea and main concept so to to talk about secure boot we need to first understand that there is crypto involved and there are a couple of key databases so and those key dope I mean like keys in those databases are used to build that trust relationship basically or they provide you with the way where you can verify the trust so there are four four main databases described by UEFI secure boot first one is PK platform key it is database which contains always only one key then you have Keck key exchange key also database which contains only one key then you have DB which is signature database that may contain more keys or hashes and then database the last one is DBX and that is the that contains basically keys which are revoked so it's a revoked database of revoked keys or hashes known hashes of a mouse so if if the new malware which for example I don't know like there is some attack against Microsoft bootloader Windows bootloader they can release new version where a patched version and they can enroll a hash of the old one in that database and that means that platform firmware will never will never boot that or will never run that code I mean anymore so that's that's the point of the DBX database and in those databases these days I mean the specs says that there are multiple options what can be stored there but basically almost every vendor these days and every platform every firmware implementations I encountered supports x509 certificates with RSA RSA keys or shot of 256 hashes so this is the this is the diagram which which which shows which shows you which secure boot mode actually exists in the demo you saw that I started here in the setup mode and in setup mode I can basically run whatever I want secure boot is effectively disabled and then I enrolled enrolled keys and I transitioned into user mode so in that mode secure boot is secure boot is enabled and enforced so we will check signatures and we will build the trust relationship and we will actually refuse to refuse to boot unsigned code and there are a couple of there are two other modes I will not bother describing what for what is audit mode but deployed mode could be it can be said that this is the most secure mode so you can transition from the user mode to the deployed mode and in that mode basically the EFI variables are read only you can't change them unless you can't change them programmatically you have to you have to be present at the machine and transition back to the user mode or yeah transition back to the user mode and then you can programmatically change the keys or you can also there is a platform specific way how you can see your platform specific way how to how to transition from user mode to the setup mode question where is the mode stored like if I change the mode to deployed what changes that I can need from somewhere that's got that nature in nvram oh so it is exported then as EFI variable basically I mean the spec doesn't says where it is where is it stored it says that what what are the requirements for storage so I think at the end of the day the fact where is it stored on the on the given machine would be platform specific but it has to comply with the requirements which are given by the specs so for example the database must be tamper proof and stuff like that and I think you it should survive that yes so you are not supposed to be able to do that but well that document is just a spec so what actually gets to the end users I mean it's hard to tell it would be nice if all the vendors complied with the specification but yeah like I said the spec itself doesn't doesn't says where it should be stored it puts some requirement on that storage yeah maybe that that's maybe the case I don't know but I don't I don't recall that the spec itself says that and so maybe some other document has more and more information on that for like yeah okay so those are those are the modes and now as for the benefits from my point of view that's sort of open for discussion if you may may agree or not but so yeah so like I said chain of trust from the firmware to the OS should protect you from the boot kits no unsigned code running in kernel and only signed drivers are loaded so more or less no root kits basically yeah doesn't doesn't yeah so there are risk involved as well so on most machines that chain of trust include third parties so it's not only you and and manufacturer of your machine but typically Microsoft because your laptop probably has Windows Windows 8 sticker on it or maybe Windows 10 these days and Microsoft mandates that if manufacturer wants to put Windows sticker on their laptop it has to have Microsoft has to have their keys in a firmware by default and secure boot must be enabled yes of course you can so secure boot actually and that is another thing which is not mandated by the specification but this is mandated by Microsoft can't be disabled on the ARM based devices with Windows 8 and newer so yeah on Intel based hardware we are fine we are we can still run whatever we want basically we throw away keys which are provided by the vendor we install our own keys redhead key fedora key and we can run whatever we want but on ARM we are sort of out of luck because there's no way how to how to turn off secure boot so if you if you buy I don't know tablet with Windows 10 then you can't can't disable or shouldn't be able to disable secure boot I can't really imagine that Microsoft would allow such such devices to be sold to the end customers if the manufacturer doesn't comply but I don't know I wasn't very like actively looking for cases where this is actually not the case so yeah doesn't secure boot doesn't prevent infection of your machine from malware this is not what it does you can still have your machine hacked even if you have secure boot enabled it's just that the hacker will probably be not able to inject any code to the kernel I mean via the measures of loading kernel modules he can of course trigger some some some back in kernel via other means and possibly inject code this way no no it is going up to the level of the operating system and not to the end you go to the applications that's the line yes so if you have your any drama first or if your any drama first was tampered you are again out of luck and secure boot will not will not save you because the problem with any drama first is that it is generated at install time when you are installing Fedora is the last step of installation there are post script plates post trans script plates running and then as part of the post installation process any drama first is generated so it can't be signed by by Fedora or redhead so any drama first is not signed these days there is some work going on to address that Harald Hoyer is working on pre-generating of any drama first and storing hashes of the of any drama first and and kernel command line hashes to TPM so system then can be read also system then can do remote attestation and prove to the other party that it really booted with the kernel command line parameters it was supposed to boot with because of course you can't you don't even have to like really change in in IDRD if you are present at the machine you can just say in it equals bin SH and you don't have to do anything else to take over the machine basically so once we have we have a possibility to do remote attestation secured by TPM then we will be will be able to tell that okay if I have this set up in my environment in my organization those machines are can't be can be supported this the this way because hashes of the of the kernel command line will be stored in TPM and then it will do remote attestation so also there are problems if you are running with secure boot enabled currently on Fedora I don't know about policies in other distros what they do but in Fedora direct IO to Dev K mem is disabled then writing to machine specific registered via MSR kernel module is not supported also if you want to so K exact is also disabled and that implies K dump is also disabled so yeah I mean in enterprise environment it's not not that great because K dump tool is used a lot and K dump uses K exact functionality there is a so if you're basically if your kernel crashes there is a separate kernel which will be which will be K exact and it can then collect some more information about the crash and those information then can help support engineers yes yes yes yes that that may be the case I saw patches on only mailing list but okay then no I don't think it's used in so basically I'm here describing Fedora setup but it is good to know that patches upstream has been merged so yeah so K dump will be will be usable then so and that and that's good thanks well so yeah I mean with the security features and security it's always a trade off right so that there is some more work involved so basically if you have third party modules which are already signed I me on my own laptop I don't have any hardware which requires those so I didn't doubt with this problem myself like personally so but I would I would think it is possible to strip the signature from the from the from whoever is delivering the module I mean NVIDIA VMware whoever and then resign it with your own key and then you can load it I mean it's a heck but it can be done and yeah so I think that there is no other way if somebody if somebody knows about some other way how to do that more effectively please speak up because I don't I think so and also in Fedora hibernation is disabled but again I face personally don't use that so it doesn't bother me that's the suspense basically hibernation and suspend I mean suspend to RAM that's works so that is suspense to the suspense to disk so now as for the demo okay so in demo I showed you at the beginning basically those are the steps I I did or I have a script which did those steps so basically if you want you can you can check in a secure boot demo folder so this is the script and these are basically the steps it does so first think it checks some parameters that's not interesting then it will generate some random UID unless it is already provided in a in a in a file like owner GUID then we basically using open SSL generate RSH keys and X509 certificates then then we convert those certificates to the form which can be then used by or can be enrolled in into the firmware it's called EFI signature list so it is you can imagine that it is like like the certificate is very concrete thing and and standard says that you can enroll a couple other things except the certificates in a firmware so on top of the certificate you have that EFI signature list which basically encapsulates the certificate in our case but it can it can accept encapsulate a couple other things like standard hashes again a specification is very very concrete what what can be what can be stored in a EFI signature lists and then basically what we do we sign we sign the signature we sign the signature list and the signing is done here it is a bit of a hack but in a in a real life it would work that you have your so you you generate your own your own platform key and once you enroll that you are the platform owner basically that is the that is the sort of the meaning of that of that key whoever has that key enrolled is platform owner so in in a default setup OEM basically owns your machine because the key belongs to the OEM so if you change that key then you become the platform owner and then all the other keys in key databases I I showed you before like keg DB and DBX can be changed by you and the way you do that is you have to you have to generate like out it's called authenticated updates to those key databases and the key databases I mean keys in those databases can be updated always by the updates which has been signed by the key from the database which is above the database so the as we as was it on a slide first we had PK then we had Keck then we had DB so this is the hierarchy I mean you have your own PK you own the platform then you can generate authenticated update to Keck database and you can basically append to you you can basically change the key in a Keck database so or at at the key to the Keck database and you signed with the platform key and then if you want to change key in a DB database that would be the key you are using for signing for example your own kernels or your own EFI applications you will sign that update to the DB database with the key in Keck database so that's the hierarchy excuse me what happens I mean DB and DBX database are like top at the bottom so there are no other databases below them basically so you always have to sign updates to the DB and DBX with the Keck key but in the reality as you can see in that script I left it there for the demonstration purposes I basically I am signing all the keys with the PK with the with the platform key so you should sign the DB key with the Keck key and Keck key with the with the PK key but you can you can and it is even allowed by the specification you can sign everything with the PK key it is well I I don't know I don't know pretty much what was the like the story behind behind this idea but if you if you don't have your own keys like imagine that you bought a brand new machine and PK key and for example it's Lenovo so in Lenovo case PK key PK key is owned by Lenovo and then in a Keck database the one below you have Lenovo key and Microsoft key and in DB you have Microsoft key and then if you want to run some some binary you either disable secure boot or you have to run something which is signed by Microsoft or Lenovo basically and Microsoft provides you with the they provide certification service sorry not certification signing they provide signing service and for example if you want to have your binary signed by Microsoft you would have to deliver the binary and source code to them they will do some security checks on their source code and after a couple of weeks and once you pay them I guess $200 I'm not I'm not sure they will sign your binary and then you can run it on your own machine so yeah so basically keys are enrolled in a firmware and then whoever owns the keys have to provide a way how to sign binaries with those keys basically and by default Microsoft has keys installed in every every laptop and then and then Microsoft can sign our binaries it wants and those can can be run on on on such laptop I mean in Fedora default Fedora setup is bit different from what I showed here and it uses sort of a hack to the spec I mean they use extra database which they call MOK machine owner keys this is like a separate database implemented by the tool default in default Fedora there is a tool called shim and that shim tool is basically it has been signed by Microsoft and then firmware will launch the shim tool and then that shim tool knows how to how to basically find the grab binary and and link the grab and then it will jump to the grab code then grab you will see the grab then and before it jumps to the grab it will it will verify that grab is signed with the Fedora key and the public a part of embedded in a shim binary so it is like a weird setup I mean shim is shim is signed by Microsoft then inside shim there is a public part of a key which Fedora uses to sign grab and kernel then shim links the grab jumps into the jumps to that code before that verifies that binary is properly signed then you will see grab menu and before you before you see actually the menu grab will find all the kernel binaries according to your configuration and it will ask back shim hey please verify the signature on that kernel on that kernel binary because grab itself doesn't contain any crypto code so it calls back to the shim to verify please please check the signature on this kernel binary and that's I mean I don't think that's particularly good design but I know that there are that there are like use cases which they want to support for example dual booting windows which I don't care about personally and maybe that's what I what I didn't mention yet I mean if you have your if you have your own keys and Fedora key for example I get in a setup I showed you you are basically and secure boot is enabled you can't boot windows because firmware will refuse because Windows Windows boot loader and Windows Windows kernel are not signed by by your own keys or Fedora keys so that is that is the one thing I should emphasize that using the setup I showed you you will not be able to do all boot so if you want to do all boot please use default Fedora setup but that required that I mean it is what it is so for example that a shim I am talking about it contains it bundles like crypto libraries like open SSL for for verification of the signatures and then like I told you grab calls back to the shim and shim does verification returns back to the to the grab and then grab can continue in a boot process basically so you have firmware itself contains crypto code because it has to do verification of signatures and then shim contains crypto code so you have two layers where things can go wrong so if you if you don't care about windows and you don't care about other operating systems care about only care about Linux then you can use the setup I showed you and you can get get rid of the shim layer how do you update your file? so we have bias updates on the older machines your file is just a new kind of bias you won't update and they've discovered that they have bugs there so they check it with the APK key yeah that's actually a good question I think that's the case yes you would have to disable secure boot in a setup utility you usually have a flag enable disable so for a firmware update you would have to disable it because usually firmware updates are done via some application which when they're delivered to you yeah you will know about that if it's signed with their APK key you don't need to disable secure boot depending on the size of the APK yeah so that that's what and you can't you can't run such binary if you have only your own keys so you would have to disable secure boot for that time period run the binary which was given to you by by a firmware vendor update the firmware and then enable secure boot back so yeah maybe you can do that I didn't try it so so question in the back one of them is you mentioned that the shim contains open as a cell right so in case there's a new open as a cell which fixes some serious security bug you actually have to re-compile shim and get it re-signed by microsoft or how do you just deal with this that is my understanding that you if you do some changes to the shim code you will have to deliver that new code to the microsoft certification service to to sign to sign by microsoft which takes about two weeks so yes that takes time yes it's a very small amount of code so you know that's what you want is something very small that's not going to have a lot of issues that's yes that's the case and another question you said that the root is calling into the shim the verification services yes shim just call directly into the uefi shim establishes another like shim implements its own uefi protocol which is then used by graph because uefi api doesn't have like top-level api please verify signature it has api basically what a system did boot is using is uefi api called load image and in approaching weeks of loading that image the signatures are verified in case secure boot is enabled but there is no api to actually just verify a signature so shim itself implements own it extends uefi firmware it's a good example how you can actually extend the api which firmware provides you just look at the shim code and you will see how they how they do that how they extend and provide their own api for graph to call back what happens if i verify a signature of the image and change the image and then load it so so you do what you verify the signature yeah mode probe what probe reads in the module in the memory and then make a system call load the image so the loading is checking the in the signature and then loads so what if this so you are suggesting that this this scheme is vulnerable to time of check time of use bugs in a mod probe yes and you are probably right i mean yeah i guess i never checked the mod probe code but i use module signing it around but what you are suggesting is that i check the signature and then i load the module and in the in the in that very short time window between i i do check and then load somebody would somehow but he would he would have to hack your kernel anyway because how how they wrote the kernel one probe i have a pro by fork and other thread which is just but yes but if you if you need to read the module in the memory first and then validate the signature because yes validate the contents of the module yeah yeah you would have to have so it's low the module was loaded first yes the module is validated yes the code that is already validated is then inserted with the kernel yes at this moment you can't change no no you can't why because because because attacker would have to break like the memory management subsystem of the linux kernel right to hack into the mod probe uh like he would have to attack or somehow get into the mod probe process uh to to change the memory mod probe already so so this thing is not protecting you against user space attacks so we can we we are don't we are not talking about cold cold is malicious maybe assume this that's fine because mod probe code just pumps some sort of binary into the kernel space and then the binary which is pumped into the kernel space that off limits to the user can change what is in the kernel space to verify the cryptographic signature and then you insert it but there's no way the user can actually change this the module okay so it's put into the kernel and that's very fine okay make sense okay so some more questions martzl so for qualification so in your setup not using shim you write your key directly to the vk database or uh yes yes you you so you rewrite the original key yes Lenovo key is not anymore there so how you would have to download Lenovo key or backup the Lenovo key before you delete it so we would have to read the contents of that efi variable basically what what actually it is right now put it somewhere she's impossible to have just one platform yes it is possible to have just one platform key so not it's not really a database it's a place for one key a platform key is for one key and then all the others are you can have multiple keys okay so so you write the platform key and then you have keg right yes and in keg database you can have multiple keys so when you write your own key there you if you edit and the microsoft key still is there or it can be there if you want to but you can remove it you can remove it yes so it can be there if you want to and even in db database you can leave the microsoft keys so and then then you would be able to do all boot yeah just what what are you going to ask okay yes yes so and you don't and you don't need to use shim then no no but the setup i showed you which you have only your own keys and fedora key you are not able to do all boot because you are not able to start windows bootloader i mean that's the question for people who implemented the scheme in fedora i i mean they wanted to use grub that's that's the one thing i guess grub is the default bootloader in fedora and it would be very hard to get rid of that and i don't know so i guess maybe the story starts there that their requirement was to use grub question you can sign whatever you want so basically with your setup i'm able to do windows if i sign that they yes if you take that binary there is a specification where those keys are placed in a binary so you just find it take it out and put something else there you compute the compute the hash sign it and put it to the binary again uh no no though as far as i understand hash is computed uh in a way that it's the inside of the signing envelope yes key key is not part of the of that computation so you basically compute the hash you sign it and then you then you put it uh signed hash into that binary so i i i can resign my internal basically it's by default signed by fedora key so i throw it away sign it with my own key and i can i can boot it then okay so yeah so basically we sign the keys sign the yeah sign the signature list and then we enroll them into the firmware and then once we enroll here at the bottom pk platform key that automatically takes the platform to do user mode it should it actually doesn't you have to review and that's probably a bug in a firmware because or maybe it does but it doesn't tell you maybe bug in her no i don't know i would have to check because if i run boot ctl it tells me that secure boot is disabled and platform is in setup mode i guess but it really should say that secure boot is actually enabled and a platform is in user user mode once we get to here okay so we already talked talked about alternatives how you can how you can implement secure boot so actually you don't have to you don't have to use any boot loader you can you can just sign your kernel and use efi firmware to to load the kernel directly there is a efi variable called boot order and whatever is defined in that variable will be at least tried by the firmware and if you define a path to your kernel which will be on a efi system partition then then it you can boot basically without the boot loader then there is a grab plus shim approach we discussed and there is one more thing which is related to grab plus shim approach and that is the tools made by james bottomly the scasi maintainer in kernel he already he also does secure boot things and efi stuff so he sort of did a hack where they have separate key database called mok they install key there and then they do very weird thing which is sort of it is as far as i know it is not standardized and it is like a hack but it works and the point is that they override something called efi architect security architecture protocol and they install their own hook into that so basically they hook they they chain another key database into that into that chain so basically if the key is not in pk not in keg not in db it will it will try mok as well so they have like i don't know it's couple line of assembly uh but it is a hack and so far as far as i know it is not it is not standardized it is not allowed by standard to do such hacks but they tried it and it worked they claim that everyone is using basically the intel implementation of efi only asus is doing their own thing and they also tried well hardware with the asus firmware and it worked everywhere so they they do that i mean they invented their own database and and install that override into that protocol so that database is also checked uh i don't know up to the up to you to decide what you think about it so now you efi development so very quickly uh the main thing you need is if you want to experiment with all the stuff we talked about so you should get uh edk 2 uh installed on your machine so edk stands for efi development kit uh there is a here is the repo you just add that repo or if you are on fedora sentos or uh rel uh if you are on your boon too uh i guess you just have to unpack rpm and copy the files to the correct destinations so uh so that is the repo and from the repo you can install the install that package that package actually contains uh uh binaries for uefi firmware for open source implementation of the uefi firmware which lives on which actually lives on github and the guy uh cracksl he actually runs jenkins instance against the git so you can you can have basically firmware built every day also fresh so you can experiment with the fresh uh fresh master may not work uh from time to time it depends uh so couple other things if you are using uefi you should you should have your disk formatted in a way that it uses gpt partition table i mean there is no reason not to use gpt mbr is terrible you can have three or four partition at most and they they are small so you should use gpt i mean all the standard tools provides that functionality so fdisk cfdisk whatever you are using all provides uh possibility to to use gpt instead of instead of uh dos uh partition table then uh then you basically create uh one partition which will be your boot partition and you format it as fat 32 that is mandated by the firmware uh specification uh and you mount it somewhere i recommend and what in the image is done is you don't specify anything in fs tab and you let system d do its magic it will discover that you are using gpt partition table it will figure out which partition is your is supposed to be your boot partition and it will mount it automatically so you don't do anything system d will do it for you then you can use uh bootloader i showed you so i really recommend using system d boot it's very lightweight bootloader uh two thousand lines of c code basically to implement basic function functionality of well i don't know who uses grub for anything else than just booting their laptop okay one guy so then system d boot is probably not for you but for everybody else on the laptop setup i don't see a way why should i bother with grub can you document that process because i actually tried to switch fairly recently and i was able to succeed but i know quite a bit about this technology i don't think anyone that is not uh would be able to switch to uh to it yeah that's from grub and it's not even packaged in fedora so okay uh i mean human system d boot yeah it is part of system d rpm it is i check the binary user lip system d boot efi uh path i mean i guess this was a while ago so maybe it was so okay so i might have an old package but yeah maybe so try try fedora 23 rohe it should be there if not filo buck it should be there uh so once you have that uh like once you have system d boot which everybody should have because it's packaged in system d you should have top level tool uh boot cpl and with that you can do nice things like status uh install the bootloader and you can install uh also for the development purposes i recommend installing efi shell but these days the firmware itself embeds shelf in its in itself so basically you don't need to have separate shell binary it is in a firmware by default and you can run it from the from the setup utility menu uh it is like boot device menu and in there is a sub menu where you pick efi shell in a image i i provided you there is a separate shell binary installed so you can you can play like that uh so the actual firmware firmware implementation itself is at that uh you'd have uh you'd have account tiano core uh slash edk 2 tiano is old name intel used for for that stuff i mean legacy uh these days it's like it should be named like intel slash edk 2 but doesn't matter uh and to actually do some efi development you need really basic tools you need just gcc make and binu tools and that's pretty much it you don't need anything else and gnu efi uh develop package so here's really simple hello world application where i would like to show you a couple of differences between between the normal c hello world and hello world for efi uh so as you can see the main function is called a bit differently it's called efi underscore main convention uh efi uh it takes a couple of parameters so it's two of them efi handle to image so basically uh it is a data structure basically describing the application itself when it is running and then system table uh in the table there are a couple of function pointers to basic protocols like output as you can see here console output uh it is from that system uh system structure so that is the that is the pointer to to the protocol uh we can see that then the protocol is used here so and we are we will be calling a method of that protocol output string with two arguments uh this pointer basically and the the actual uh string we want to we want to print uh yeah you can see here that i'm using all prefix because all the strings in efi applications are basically utf 16 that's unfortunate but it is what it is i mean the standard itself was designed in 90s and i guess back then utf 8 was not that popular so they went what they had okay so so development environment like i said very simple gnu make binutils uh yeah so you see here that i am calling basically this function but i am not calling the function uh directly even though i have pointer to that to that map to that efi uh function i'm calling this function via the uefi call wrapper because uefi uses different calling convention as gcc by default and that wrapper will provide you with the with the correct calling convention for the correct for the current target so basically uh it doesn't it doesn't matter whether you are compiling for 32 or 60 64 bit code if you use this wrapper uh it will do just the right thing depending on the target uh so yeah i mentioned ucs two strings so that's basically utf 16 minor differences for the most part it's a utf 16 uh yeah and there's no standard library basically you can't use mem copy that there are routines in gnu efi package that there are libraries you can use you you have to look in the header file to to see what's there uh api is it it it is it resembles windows apis like the conventions for the code it is camel case and stuff like that so i mean it's not that nice i would say as a standard c apis we deal with every day but whatever uh it is what it is and yeah so for a more complex example you can actually look at the code of bootloader how we we used in our demos i really really recommend looking at that code because it uses different protocols like output graphics and stuff like so and it is very short it is couple maybe two thousand line of code a c code so you can you can get the feeling how would you go about implementing non trivial efi application and it's not that hard yeah and i'm out of time and that's pretty much it so thank you for your time i was told to and scarves for questions so i guess it's okay so oh so we have two spare tickets to the party who doesn't have to get to the party and wants to go there