 So I'm Olivier Courscaire, I'm an application software programmer and yes, I will speak to you about UFE programming. That might be surprising but you will look why. First things, I will not learn you how to write an operating system nor even a bootloader, sorry. But I will show you the step to make executable files that can run in UEFI directly at the beginning of the boot of your computer. So as I intended this presentation to be for beginners, I will just describe you what is UEFI. Maybe you have a good knowledge of it already but I will just present you the minimum things you need to know for the rest of the presentation. And UEFI is a specification that presents a common interface above a wide range of hardware and it's a specification. And it's present for operating system or bootloader, the same interface, whatever the hardware. But I will not speak in this presentation about hardware initiation, just the communication part between UEFI and maybe your computer or your operating system or your software. So UEFI means Unified Extensible Firmware Interface and there is a huge specification, more than 2,000 pages. And for short, and it's good enough for the rest of the presentation, it's an obvious replacement with extended capabilities. So what I will discuss in this presentation, I will show you existing tool chains and what are the shortcomings with them. Then I will show you how UEFI executable file is structured. Then how is organized the API of UEFI because it is what we will use to communicate with the hardware. And I will give you a short overview of features that could be useful and that might give you some ideas to make something different than just a bootloader or things like that. And after I will describe you an important point in UEFI specification is the protocol concept and I will explain you why it's important. And then I will show you some more things at the end and what I plan to do with, I will follow this presentation. So first, just a disclaimer notice, in this presentation I will don't take care of security. I know it's important, but for learning programming UEFI, I think it's not that important. I consider that you disable a secure boot or things like that and you are the owner of your machine and you do what you want with your own hardware. And I will really focus on what obvious programmers like me really need when programming UEFI. So first I will show you that there is mainly, if you have already done some UEFI development, I hope you don't at this point now because you will probably don't learn something in this presentation. But there is two main stacks, there is Tiano Core, Iideki 2 and GNU UEFI. And when I start learning programming UEFI, I just look at the documentations and it looks like it's not the way for me to go. So from what I read, because I don't even try to install them, it was a quite tedious setup process because you don't have a package that you can download and start writing your program. There is package but you have to download different ones, you have to configure things and things like that. It's what I read and it seems from what I read that GNU UEFI is supposed simpler because for a long time you can reuse your standard Linux compiler for example. But it's not the case anymore, I checked two weeks ago and if you are under Linux you can do almost the same. You don't have to install for example the GNU compiler for Windows to get the job done. It's not more required but before that you have to cross compile this on your machine to get binaries. And with GNU UEFI it was maybe a shortcut but a hack that you can use your standard elf object files and put them in UEFI files, executable files. So why it's so complicated for Linux to generate UEFI is maybe it's because of the structure of the application. One important thing to know is that it's a portable executable file, it's not an elf file and so it's exactly the same file format like on Windows. So that might explain why it's more difficult. If you are on Windows it's easy to get portable executable files but for other platforms it's more difficult. And the only difference is there is in the header of the file there is a special subsystem code to recognize that it is an UEFI application. So there is only a very small difference. And there is three kinds of UEFI applications, there is applications with this code. So it's mainly the most used code, it's for bootloader but you can imagine to make your own bar metal application with this code. And there is another kind of application, there are drivers, there is two kinds but I will not explain more on this feature because there is a good drivers, writers guide at the China Core website so you can look at it, you search on the internet and you will find them. But structurally it's exactly the same file format and it works exactly the same, it's just the intention of what you're making inside that make it a driver. One other difference with the standard file is that there is an entry point called EFE main and there is two parameters under the image that is automatically load by the firmware. And then the firmware gives you a system table and from this system table I will show you in the future with this system table you can call all UEFI APIs. So it's very important. And to call those UEFI APIs you have to use the same calling convention as the corresponding Windows target. So there is also the other problem that you might have with standard Linux object files because you probably don't use the same calling convention and GNU EFI is just about that. You call something that makes the translation for you. So my take is that Intel when they want to publish UEFI want to have Microsoft on board and make life for them easier but more difficult for us. It's my take, I don't know if we're always on but I think it makes sense. And one key important things to know is that the CPU is already in protected mode and with a flat memory model. So it's a real change for beginners like me compared to the BIOS things that you come in real mode. And if you want more than 30 years things you have to go to the protected mode and things like that. So really now you can start maybe something like really close to an application under an OS. And even on 64 bytes you even go in long mode so you're already in 64 bytes and you don't have to transition to but only one core is initialized. So if you want to go multi-threading you have to do your homework and do some hardware initialization. So it's not completely but it should be enough for starting. Now we will look at an important structure in the UEFI APIs. It's the UEFI system tables. From there you can access some services like input output console. So there is also fields to access configuration tables. So if you write an operating system it might be interesting. So for example there is the ACPI tables available there. And there is also fields but there is two other substructures. One is runtime services that provide additional services available even after boot time. So your operating system can call them always. And other kind of services are boot services. And they are only available when you boot the computer. And when you give and to the operating system this service are not available anymore. So some example of feature provided here. There is memory allocation functions. There is APIs to find the memory map of your hardware. So it might be just an int. It might be useful if you write an operating system. As I said before there is a console and input output console on-link. You can get the file system access. It might be useful to find a kernel for example in a partition. And there is also some maybe interesting features for bar metal applications like graphic interface with even mouse support or even some network access. So it might give you some ideas of the possibilities. It might depend on your hardware. It might be more complicated than just calling socket things but there is things here. And now I will pick like I said earlier one important concept in the UEFI APIs. It's the protocol concept. If you want to give overview it's more or less interfaces with a set of related methods and fields. So it's just a structure with different fields and some are methods. And they are all identified with a global unique ID and example of protocols. You can find them in the specification. There is a simple text output protocols. This one under console on-link. There is the same for input. And for example for graphic operation you can use the graphics output protocol. So with just a few of them. And there is some more that are at specified system position but generally what you have to do is to find the protocols before calling it. So there is APIs to do that. For example you can find protocols by unique IDs or handle. And from the handle for example you can check if your handle supports more protocols. So it's method handle protocol. And you can check if there is support for this specific one that you are looking for. And there is also another important APIs is locate protocol. And with this API you can find and locate the first handle. So the first reference to the protocols that implement your specified unique ID. So here are a few programming tips about UEFI programming. There is a function that is called exit boot services. And if you are making a bootloader it's probably one of the last function you will call. And because after that it will release all the resources used by your bootloader that maybe you have allocated with the memory allocation function and things like that. And then you give hand to your operating system. So after that you could not call boot services APIs anymore. You shouldn't. Probably it will crash. And one other important thing especially if you do bar metal applications is that boot services by default is only available for the result time out for about five minutes. So if you want to make longer things you have to disable the watchdog and maybe replace it with no function. So you have enough time to do what you want to do with UEFI. So with all this you are ready to write your first UEFI application. It's all you need to know. And so what you need is something that is almost a Windows compiler that can generate Windows binaries. Something that lets you define the untry point with the specified requirements. So the UEFI main application function. And something that can respect the Windows calling convention. With all that you can do your UEFI with maybe any language that provides this services. But it's when I discover that I think about my preferred compiler all this feature. So maybe I could try hack it and write UEFI binaries in my preferred compiler. And then what I plan to do is to introduce maybe what I think is the easiest way to write UEFI application. And surprisingly it's with free Pascal. Why this? Because instead of spending time in selling the 10-core toolkit or things like that I think it was more simpler for me at least to just tweak free Pascal to generate UEFI binaries. Why I think it was possible for just software programmer and application software programmer it's because free Pascal already have an internal linker for Windows and an internal compiler. So with the linker I shouldn't have to deal with LD version or things like that. Everything should be directly in my preferred compiler. So if there is no, if the tool already have a linker there is no external dependencies. So it should be really easy to set up. And one last thing, for me it was really great because I could even do this under Aiku. Because under Aiku with Chano Core would have meant to cross compile or to pop the whole stack under and probably unknown OS from Chano Core and huge step. On the contrary with free Pascal I already have it on Aiku so it's easier to start hacking for me. And I try to do all my OB programming with Aiku so I think it would be simpler. But yeah that is the plan but it's still a work in progress. So I can show you what kind of thing I can do. So maybe you can count with everything but it's maybe on purpose to show you the difference. So I treat a cheat a little because for free Pascal this is a Hello World application that you can do with GNU UEFI on the top and for you the white it is for Chano Core. But Chano Core there is a lot of comments that's why it's longer. But if you look at the free Pascal one and if you know a little about free Pascal really it's just the standard Hello World application you will do in Pascal and this kind of application can compile out of the box and run directly under UEFI. So if we have time after the presentation maybe I will give you a start. I will show you in a virtual machine. So as I said it's an early process but it's already compiled UEFI binaries and what I plan to do now is port the wall and to implement the whole runtime library that is with free Pascal so you can use you can develop for example console application in free Pascal and just run them in UEFI environment. And maybe one thing that will be required would be to write bindings for all UEFI protocols. What it means is just to declare parameters on each functions and register and declare records with all the fields necessary. But it's a huge process so any help is welcome if you think that kind of project should exist. And maybe one of the fun things I like to do with a full runtime library I should be able to compile the free Pascal compiler with just one binaries as an UEFI application and maybe run it directly from the system. So this is one of the funny things I like to do but it may be depends on your help because I only spend maybe a few days per year on this project so it might take time so if the help is welcome if you think it's right to do. So here is a couple of links about UEFI programming. Just links or if you want to set up Gen UEFI or Event Channel Core there is links. And just a mention for the first one is when I saw this article that I think it's about doing UEFI programming under Rust and when I read this article I think well I can do that with free Pascal and it will be even simpler than what was explained. So that's how everything starts for me. So UEFI hacking, I hope it was interesting for you and if you have questions or... For now I only use the output console and memory allocation so maybe I can start just a sample. So here's the command line to compile. You don't? Yeah, see. Ah yeah, it's on the other side. I forgot to repeat the question. It was which protocols were already implemented. So there is the output protocol, so hello. So this has to be now. There is a lot of debug outputs but it's the output protocol and there is some memory allocation functions that are called. So this was necessary, for example, if you want to allocate objects or things like that. Maybe it's time? Yeah, it's time. Thank you.