 Hi everyone, my name is Leif Lindholm. I used to work for Linnaro for many years and part of this material was created when I was still employed by Linnaro, so I figured I owe them to build the logo up there. As of the start of this year I now work for Nuvia, which is a processor company. I am also one of the stewards for the TienaCorp project which is the umbrella project for the open-source reference implementation of the UEFI specification. And I'm here to talk a little bit about open-source UEFI and TienaCorp and how we're trying to help improve the interactions with community with regards to updating specifications. And that's a special thing we agreed last night. Art is going to pop in at the last few minutes to talk about some ideas he has about unifying the Linux kernel boot protocol on UEFI platforms. So I'll start with what we call the UEFI code first process. Code first is kind of a weird thing to be talking about at FOSSTEM. I think everyone in this room knows what it is just not that you needed to have a name for it. What we mean in this context is maybe easier to explain by talking about how UEFI forum has worked on specification changes or additions up to this point. And that requires some history. The UEFI forum was originally set up as a collaborative environment between on the one side a bunch of competing hardware manufacturers like AMD and Dlarm but also system and card vendors. And on the other side a bunch of competing firmware houses or BIOS vendors as we still tend to call them. And peace was maintained in this situation by the UEFI forum bylaws which as in many industry standards organizations at least these days focus quite strongly on protecting against submarine patents making it into public specs. And the ultimate guarantee of this protection is the process through which specification changes happen which happens through effectively well mantis or bugzilla tickets being tracked in the background and called engineering change request or ECRs. And these ECRs are discussed in NDA covered meetings as part of the specification publication process members are then given a deadline of speaking up or implicitly giving up any opportunity to claim infringement on any of their patents in the future. As a result of this the guidelines have always been that before publication code implementing new features cannot under any circumstances be published. And as someone who was working on the 64 bit ARM side to try to get things out align in time this can be more than slightly frustrating. So the key point is that really only after the specification has been released is anyone actually protected from the patent nonsense. So coming back to code first. In short it's a proposal for how we can organize the work of prototyping new features in public without violating the bylaws. I recently sent out a proposal to the EDK2 RFC and EDK2 develop mailing lists. The specific message is a link you can download from the presentation which should be in the system already. And the short short version of what this actually means is we will be tracking development of new features in the Tiana core bugzilla and we will have reference code and documentation of the new features held under the Tiana core GitHub area. And then I think I forgot to put a slide in that points out that once we've done this prototype in the open then it will turn into an ECR which can be discussed by the forum and the bylaws are not violated. Okay I think that went quite quick. Does anyone have any questions on that section before I move on to other random bits? Okay so I have a question. So the question is how can you ensure that you're not violating any patents while you're prototyping the feature and the simple answer to that is you can't because we've not gone through that process yet. So while you're prototyping it we would recommend that you don't put the prototype thing into your product but it does mean we can do all of the development in public beforehand rather than doing something in the specification and then moving into the public. It's that is certainly theoretical possibility but the intent is very much that that's not going to be the case. Yeah so I mean as a when we're putting the whilst the things are in flight we have a repository called EDK2 staging on that GitHub area which is separate from the main EDK2 repository. Is that what you meant? Yeah. So this isn't actually news as such as in I could have presented this last year but I didn't give a talk last year so it's the first time it's been talked about at FOSTA I think. So the UEFI self-certification test suite. There are many test suites available to help verify the correctness of system firmware. You have the firmware test suite, you have the ARM server ACS, you have Chipsack and probably a bunch of others that I couldn't be bothered to dig up for the list. The UEFI SCT is a very basic one but it verifies fundamental API conformance for UEFI implementations. Historically that was not only secret but like not properly version controlled really and it was all a bit of a mess but as of October 2018 that is now open source on GitHub and people can contribute to it. And yeah I think I'm giving up on that. One of the benefits of SCT is that it is a test suite for all UEFI implementations. So with the addition of the UEFI interfaces to Uboot it's been really useful to be able to prove interface consistency between the implementations and for me even more important is that we're finally able to test the test suite against different implementations. And as part of his work with Uboot, Heinrich has already resolved some issues in the UEFI shell and inside SCT itself which we could not trigger just against EDK2. Right. So I'm completely random unrelated slides before I hand over to Ard. Risk 5. I actually missed the Risk 5 talk earlier today but the support for 64 bit Risk 5 is going upstream in EDK2. A proof of concept port was initially submitted in 2016 but that was then kind of left alone until summer last year. But now we've been going through and reworking it. I've been reviewing it and Abner Chang at HP been reworking it and upstreaming it and working also with OpenSBI to make that easier to plug into the EDK2 port. So you can track the current status on the Risk 5 V2 port at that link. If you click there now you're going to find something very very boring but if you wait a few days I'm gonna have the latest stage of things up there. My personal goal is that we include Risk 5 in the Q2 stable tag of EDK2. Licensing always important at FOSTA. EDK2 used to have a really tedious licensing situation with a separate Tiannecore contribution agreement working in conjunction with the 2KLAWS BSD. Finally April last year we re-licensed all of this to a BSD 2KLAWS with the explicit patent grant which gives exactly the same kind of protection as the Tiannecore contribution agreement did but it wasn't home rolled. At the same time we took the opportunity to transition to using SPDX instead of re-urgitating whole licenses in every single source file. And the OpenSource platform tree EDK2 platforms also followed suit in a bit later last year so that's that's all up to the question. We support Python 3 and Python 2 these days which may or may not be useful depending on how many extensions you get. We fixed the maintainer's text format so we used to have a bit of a very non granular way of who was maintaining which part of code. We've now moved to something that looks a lot more like what QEMU and Linux have and also developed some new scripts to help so we have a get maintainer.py and I also wrote a setup git.py to make some some common known good settings for sending things to Tiannecore work right and no no I think I think it's time for art oh yeah I have stickers. Just hold it like this. Good afternoon everyone my name is Art Beechhovel I work for ARM and I manage the Linux EFI subsystem. Wonderful okay yeah so I maintain the EFI subsystem in Linux and while my background is ARM I was formerly at Lenaro as well and only lately like the past month so I have the pleasure of looking at the x86 code we have in the EFI stop to boot well find in it RDS and find command line find parameters etc and so what I'm looking into now especially because we want to have secure boot stuff going upstream in Grubb and other places is to see if we can unify that get rid of all the well bespoke pieces for different architectures that live in the various bootloaders. So what I'm proposing what I'm prototyping and what I'll send out to the list soon is a way of booting the Linux kernel in EFI mode completely generically so yes so what I'll be proposing and sending to the list soon is a way to boot the Linux kernel from Grubb or from Uboot or for whatever EFI capable system firmware completely generically so there will be no DT handling to put in in it RD addresses or no boot params truck that gets populated etc it's all simple EFI protocols and interfaces that should permit like the next architecture that gets Grubb support or the next architecture that gets added to Uboot or whatever to just use complete generic interfaces and hopefully move over the existing architectures well we discussed play yesterday it may take five years or it may take 20 years but at least we have something to move towards to to make it completely generic. Any questions about that? All right, Harkins. No no no it doesn't look like it does. Closed UFI implementations? I have I personally no but they all do it themselves so sorry I was expecting Martin to be loud enough to be heard from over there the question was whether I had tested SET on any closed source bias implementations I personally haven't I know other people have and I know that all of the bias vendors they kind of have to do it okay thank you