 Let me welcome Kirk Bresniker from HP who will be presenting on UEFI and Linux. One note, we will have a QA session later on. I will walk around the mic, so just show up so I walk the mic around. Okay, so welcome Kirk and let's begin. Thank you. So today we'll be talking about UEFI and Linux, platform, interface advancements and collaboration. Really wanna give you guys, if you're not familiar with, with UEFI, introduction to the technology. We'll go over some history, some timelines, how we got to this place, give you some updates on the current state of the specifications, the testing regimes, and ACPI. Talk about open source developments related to UEFI. Talk about some of the challenges that we've had in, in driving this technology out to market and finally have a call to action. You know, what can you do? What can we all do to participate and make this the most effective technology implementation as we all can collectively. So as far as what is UEFI forum and its organization as far as the umbrella organization, it has a group of board directors, there are 11 promoters, they're shown on the, on the logo thing there in the, in the big font. But underneath that, we have officers, Mark Dorn from Intel is the president, Dong Wei from HP who normally would be giving this talk, but is out at Stanford doing a very important install of his son as a freshman over at the university. But he will be here on Wednesday, is the, is the CEO. We have the secretary, Jeff Bozen, Bobzen from Inside and Bill, Bill Quinn from Lenovo is the treasurer. But underneath that, we have 250 other organizations that are all participating and are members of, of the UEFI forum and anyone who's a member can work on any of these working groups. We periodically spawn new working groups as they are necessary and each of those working groups in turn has subteams. So you can see underneath the specifications, subteam of security, configuration, network, the shell, the arm binding subteam. So these are all brought together. They, anyone can participate as they then go up, they come up and become specifications that are then published. While there is a vote mechanism that is possible for the 11 promoters to decide on any particular technical aspect of a specification, at this point we've never had to invoke the vote. Everything has always been universally acknowledged and unanimous as far as the decisions of what goes in the spec and what goes out. So if you want to be able to participate, you can join the, join the forum, either join via your business sponsor or you can individually join as well. So I think it's a very fairly open and easy to participate in mechanism if you do want to influence the specifications. So this is sort of the timeline. How did we get here? Back in 1995, Intel and HP needed a new firmware environment and architecture, boot architecture to get beyond the PCAT BIOS for their joint Itanium work. It was interesting that at the time some people up in Redmond were sure that Itanium needed to boot Windows 95. It was critically important. And some of us tried to see beyond that and then in particular, Don Way on my staff pushed hard for a new platform interface architecture. So we created EFI along with some others in the industry and also made a processor agnostic. So at the time it was both Itanium as well as Intel Xeon x86. 2004, tianocore.org, the open source EFI community was launched. UEFI forum became, the U was added as AMD was and the 64 bit was extensions were added. UEFI as in 2009 was extended to the ARM ARCH 32. I thought it was interesting, one of the things in Jim's kickoff speech this morning that I thought he could also highlight as a critical industry change that is driving the acceptance of open source and Linux is ARM is now the majority ICES shipped in the world. And I think that is another one of these generational transition points that we're seeing and I think that's why it's great that over the last four years we've been working hard to extend UEFI as the technology for platform interfaces to the ARM architectures as well. 2008 though Windows 8 was one of those tipping point events that drove UEFI to ubiquitous adoption in the PC desktop environment for Windows. Now we have in 2013, we have 250 members, we are extending to ARM ARCH 64, ACPI die next, we'll have a slide on that in a second, but we're also having today Wednesday, we'll have the first ever plug fest for Linux sponsored by the Linux Foundation and UEFI forum that we've had these for several years to begin to test out interoperability of platform interfaces, IO card systems, and it's a great way for everyone to really be able to test that plug and play mentality. In terms of current updates, UEFI 2.4 was released back in July. The most important highlight of that was the ARM ARCH 64 binding, but you can see we have released updates in many of the other subsystems, adapter information protocol, a capsule delivery mechanism to deliver firmware, disk IO2 to support asynchronous IO and supporting NVM express devices. In the platform interface, which is the lower level, if we remember what UEFI and this looks like, we have the platform interfaces, that's what talks to the hardware, and then we have UEFI, that's what you, the OS and application coders code to that level instead. But as far as underneath in the platform interfaces, the big thing was adding I2C bus protocol into support for the platform interfaces. You know, it's ubiquitous control mechanism used in lots of SOCs, all these different little devices out there, so it's important to have native support for I2C in the platform interface. And NVM express disk info, GUID, and the PCI enumeration complete GUID as well. So working on all of these things continuously. In terms of tests, updates, and plug-fests. Again, do a start on the right here, plug-fests. We had a plug-fest in Taipei, hosted by AMI. Back in March, we had the UEFI summer plug-fest up in Redmond, hosted by Microsoft. And here we are, later this week on Wednesday, we'll have our first ever Linux-focused plug-fest. So Canonical HP, Intel, Microsoft Red Hat, and the UEFI forum along with the Linux Foundation are sponsoring this plug-fest. And you can actually go there, and I believe it's open to everyone who's here. You can go in and see the stuff and see how people are doing, kick the tires. In terms of the SCT, which is the self-certification test, we don't have like Windows has their Wickel and their logo kinds of things. We don't have the same thing inside of UEFI. We do have the self-certification test, test it so that you can tell and test out your implementation. One of the things we'll talk about today is there's the specifications that specify what some behaviors, but then there's a lot of implementation details about how you actually wanna implement this. And I think that's one of the nuances and why it's great to have a collaborative community development environment because there are gonna be some practices that we'll want to definitely give out tip of the hatch too and wag the finger at some other people for some of the implementation details they've done. Not necessarily anything that's in the spec, but we wanna make sure we keep those things separate in our mind. But the Starnage Compliance Test, they run essentially one cycle behind. So we can see that while we introduced the 2.4 UEFI specs in July, the 2.3 test came out in July as well. So they target compliance with the prior generation. They are, it's a collective effort. People are contributing, they're test cases contributing into the SCT. We have Intel and ARM where the major contributors into the test cases and there's some interfaces that are not covered. So this is certainly an opportunity if you would like to join that testing working group. I think they're always looking for people to contribute into those tests. The 2.4 will target compliance against what was released back in July and its goal is to be released July of next year and new Wimpers are certainly welcome. So ACPI, this is a curiously blank slide but we have the ACPI, the tables for describing power, RAS feature control. Currently it's managed by a group of five companies and the bylaws that they set up were really kind of limiting. They allowed them to sort of generate a specification as necessary and then only do bug fixes unless they wanted to come together and generate the new specification. As an industry ACPI.x, we need to find a home for that. And so that's where we looked at something like UEFI where we have a much more open process where lots of people can join, everyone can contribute. And so while it doesn't say it's on the slide, that's something that we're looking to do is to try and move ACPI from that small little cadre of companies that have been controlling it and making a much more open and collaborative process. So stay tuned to this blank slide and see if we can get something moving here before too long. In terms of open source UEFI development, here you can see the source forage page for Tiana Core, Tiana Core EVK2, TianaCore.org all points to here. It's the reference and implementation for UEFI and the platform interface specifications. So again, the only thing that UEFI produces are specifications. This is, here's the specs for the methods and the behaviors of the system. Everything else is in implementation detail. And there certainly is a lot of detail in there. And that's why the TianaCore.org reference specification implementation was put out there. It's got a BSD license. It's hosted on source forage under TianaCore.org. It supports virtual environments, NT, OVMF. It supports AR64 and the AR64-based FVP. And then you can see the link in there. And it's also supports several reference boards, the OMAP, the Beagle board is a very popular one, ARM RealView, ARM Virtual Express, and new in the x86 side, MinoBoard. So MinoBoard, if you're not familiar with it, is an open design. It's open from the hardware's respects. You can go and download the CAD files and implement it. You can buy them. Intel had, their IDF was this earlier this week. Right now, if you go to the MinoBoard and you click on the firmware link, it takes you to TianaCore.org, which is just the general purpose reference implementation. I believe when they had the MinoBoard presentation and IDF this week, they said they'd have the source trees out for the MinoBoard within the month. So go back to MinoBoard.org there in a couple weeks and see if they have something beyond just the straightforward pointer to the TianaCore.org page. Linux on x64, the distributions are supporting UEFI Boot and UEFI Secure Boot via the UEFI Certificate Authority Fedora, starting with 18. Ubuntu starting with 12.10. OpenSusage starting with 12.13. Linux Foundation has certainly been a key part of this. And Greg has some great blog entries. If you just want to get started, you want to sign some things, get things going, he's got some great blog entries there to walk you through the process. What does it take for me to generate the certificates, to sign the images, to get them in, to walk through? What does it take for my platform to get my keys into the database to move between the different UEFI modes on my particular hardware? And we'll talk a little bit about that, because that's, again, one of those implementation details. The spec says you have to have methods to enroll keys, to disenroll keys, to move between different modes of having the platform sealed up or open. But how you do those things are all implementation details that are left to the individual firmware implementer. And that's one of these things where the plug-fests are great because you'll get to see how other people are doing it. And frankly, it's great for some firmware developers to see how the other guys are doing it better. And that's another good thing about the plug-fests and certainly something we encourage people to really get in there and try and do things and post your results. The best way for these firmware designers, I know this is true at HP, the best way for us to get them to do the right thing is show them when they're broken and to walk them through and say, this is what I did. I would have assumed I could do this and this and this and it failed. Why did it fail? And just be able to give them that straightforward feedback about what they need to do to improve. That's the one. So that's, yeah, that, yeah. As hosted by Microsoft. So, Linaro, Linux on-arm not-for-profit organization. And this actually has several branches of it. It has the Linaro Enterprise Group is the one that I know we've been involved with a little bit there. But they have been recommending UEFI as the preferred boot model for ARM V8 servers. So we have the lay group and you can see the pointers there. We're experimenting on one or more physical platforms. The ARM Bristol Express we mentioned earlier. The Panda board, some Samsung devices supporting KVM and enable the UEFI self-compliant test to run on ARM systems. So that's one of the things that the leg group is doing. And they're also talking and advocating for ACPI as the preferred runtime interface for ARM V8 systems. And you can see there's their recommendations about how RAS features, power features, and control features should be surfaced in these platforms for consumption by the higher level software. And again, what we're advocating for is a more open ACPI hosting environment where more people can get involved and give feedback and generate the next generation of ACPI specifications that would include better support for these platforms. So on to the challenges. And we've already talked about this a little bit, but there's the difference between standardization and the balance between standardized and differentiated. Everyone wants standards to make life easy to enable plug and play, but also everyone wants their thing to look a little bit better than every other guy's thing. And that's one of the challenges we have with UFI. Again, it's the only specifications. Everything else is an implementation is reserved to the implementer to make their decision. UFI intends to support a very wide range of platforms all the way from embedded up through enterprise. And we're already seeing that, even at HP, we have our largest enterprise, Superdome platforms are all running UEFI as our laser jet scanners. So for us, it does go from deep embedded applications all the way up through enterprise servers. And part of the benefit of that is that we actually have firmware engineers who are checking in modules that are used across all those devices, all of our personal system devices, our printing systems, scanning systems, and then storage systems, even some of our network equipment, and then certainly all of our enterprise servers. So it has the breadth, the capacity to operate across that entire range. It standardizes the platform interfaces for interoperability rather than the implementations. And we standardizes the human interface infrastructure. So we standardize the infrastructure how the events and user interface devices come together. How you as an implementer, if you're a firmware engineer at a device manufacturing company, how you decide to implement those is again reserved up to you. The UEFI shell is a little bit of an exception. That started out as not being specified, but people realize now you really do need to know some baseline of shell commands that can be implemented that everyone can count on. And that's really because you need to be able to write shell utilities, shell scripts. The shell is one way for value add software to very quickly implement it and deliver it onto a platform. And so that's why the specifications were extended to include the shell. But everything else, when you power up and you see that some of the new personal devices have those nice, pretty, high resolution graphics with touch, with mouse and everything else, although it's amusing, you can tell where they stopped and where they said this is 90% of the world and there's 10% because you have these beautiful screens until you say I wanna do an alternate boot and then boom, you're dropped back into 1989 with yellow letters on a blue screen and you're hitting the arrow keys to move around and type in things. But it is something that is happening. Richer user interfaces in the pre-boot environment, which is actually interesting because sometimes that pre-boot environment now only lasts like five seconds. And again, one of these standardization things. What is the key you hit to interrupt a pre-boot sequence on a laptop? Well, you can hit F8, you can hit F10, you can hit Escape on HP Equipment. And frankly, you only see that little message nowadays for about a second and a half. And if you go to Costco and you buy a PC and you unpack it and you turn it on and you blink and you miss that, oh, suddenly you're out of Microsoft Windows, click through EULA screen that has a choice of yes or turn off. And those aren't a very satisfying set of choices. A great choice would have been, why don't we power back down to that UFI setup screen? That would have been, and that's what we asked for, it didn't quite make it into their decisions. But those are some examples of the things that, again, we want to make sure that if we've encountered things like that, that we're voicing that, that we're saying, okay, you know what, I just bought your equipment and it was a pain to be able to add my second boot screen or my second boot device and make this a dual boot device because of X, Y, Z. And I know that's the feedback we give to our designers inside of HP. And Dong Wei, I know he's coming to the plug fest with about two dozen different distros on live boot USB sticks because he just wants to go around and say, okay, show me, show me the steps. I got my camera, I want to videotape this and post it so everyone can see because sometimes it's complicated and it doesn't need to be. There's nothing in the specifications that says, you must hide an alternate boot thing down below some other hidden menu. It just says you must have multiple boot support and it works really hard to get that in there. If it's obfuscated, that was a decision or a non-decision by the implementer, not part of the specifications. So user interface design, boot options. Again, this is what we were just talking about. It's very flexible in a multi-boot environment and we provide the EDK that tianakor.org provides a baseline boot device selection with multi-boot support. And, but again, this depends on the vendor and some of them are hiding some of that stuff. Some of them are not doing it as well as others. So again, that's what we want to get, you know, the power of users, the powers of reviews of social media. If you see something you don't like, make sure you let them know. Systems feature management. The HII provides that human interface infrastructure and vendors are very creative. I've seen some beautiful designs. I don't know if you have. Not only on laptops, but on motherboards with very nice interfaces for plug and play motherboards and hobbyist motherboards to walk you through setting up all the things and they're pretty neat. And some people are really getting creative and really raising the bar on configuration and management in the pre-boot environment. And I think that's one of those things we certainly want to applaud and encourage vendors. So, but the truth is that there is no standard presentation of these things. So that's just gonna be one of those areas that we've decided to allow and encourage differentiation. Secure Boots. This is one everyone's always interested in. UEFI, actually it will go out on Wednesday. So you get a little preview. They just put together a white paper. UEFI Secure Boot in Modern Computing Security Solutions. And it talks about implementations, talks about what's in the specification and also talks about what's not in the specification. What's left to the implementation details. But the bottom line is root kit attacks are real. UEFI Secure Boot is one way to protect against some of those attacks. And as of right now, at least, no one has claimed or demonstrated attack that can circumvent the UEFI Secure Boot on a system where it is properly implemented and enabled. And again, this comes back to implementation. There's the specifications and then have you done everything? I know I've seen some attacks that were based on things like I'm gonna go through and you do the Secure Boot but if something fails, then I'll drop back to some BIOS compatibility mode and then just boot things anyway. And that then opens the door where what you probably should have done is say, oh, if this fails, why don't you prompt the user? Why don't you do this? So I think that's just one of those, again, implementation details, not in the specification. But it is a, we believe it is a useful optional feature for UEFI to have and physically print users can turn it off on general purpose x86 systems. And again, I think we'll always wanna encourage if you have a CDP piece of hardware where they've taken that choice away from you, then I always believe in the power of the purse, don't buy it and let everyone know why you didn't buy it. That's the best, I think, most effective way to get the point across. As far as the user interface, again, we've already touched on this, it's not standardized and I don't think it's gonna be. People have made their decisions about which key they wanna do to interrupt the pre-boot sequence and that's an amazingly, because we have more than one key in HP, it's amazingly difficult to get things away from people. If they're used to that one, then they're gonna keep in that one. But it's still something that we all need to talk about. In terms of things that are challenges, nomenclature is not standardized as far as what we're talking about in terms of keys and which keys, setup mode, user mode, custom mode is one that Microsoft added and those are the differences between a system that comes with the secure boot on from the factory with the keys that are installed. Some vendors like us will provide things like, okay, you can go from this mode or you can then open it up. You can install your own keys, you can roof keys. Now, sometimes that's done with pre-boot tools in the pre-boot environment but there's also OS tools that can be used to enroll keys, to de-enroll keys. I think that's an open question about which one might be better. There's also implementation decision about what happens after I've installed a key. Can I then seal the system back up and say, okay, it's now back in normal user mode. Does it have to have a different mode once I've sealed it up? And do you provide the ability to do the equivalent of the clear and reset to factory configs? I know that we've been putting this in our platforms but not everyone does provide that way to get that system back to the original factory condition. So still lots of things churning around in the key management and the setup modes. This is all just hitting out in the consumer space now and we're gonna see it in the enterprise space here with the advent of the next round of platforms. Dual booting of Windows 8 and Linux with UEFI Secure Boot Enabled. So there's some great videos from Intel based on Intel residence specifications that you can go out and you can watch how someone has enabled Windows 8 and Linux dual booting securely on the UEFI Secure Boot Enabled platforms but the user interfaces vary from system systems as we've said. I know that Dong has collected up all the instructions on HP Elite Books and Probook laptops and he'll be here Wednesday so if you have one of those, you can button hook him or send him an email and he can walk you through the steps of everything that he's been doing. I think it's his secret plan to get one of every HP personal assistant device with the excuse of he needs to be able to test this so he's got quite a semblance of HP personal devices in his cubes all do booting back and forth. UEFI for 32-bit x86. This is something that's a little bit different and it's kind of popped up and it's a little bit of a little challenge here for the Linux community. Right now UEFI and Linux is supporting 64-bit and there isn't a 32-bit implementation but what's happened is that the 32-bit x86 has been popping back up in a couple of interesting environments. Now most of them are like closed small devices, tablets or wearables or embedded but when we originally started on the UEFI journey we had three, four classes of machine. Class zero was pure legacy BIOS. Class one was a compatibility layer only over BIOS. Class two was UEFI underneath with a compatibility layer that you could fall back on and class three was UEFI only. And what's interesting about these new devices is people just want to say I want to have an x86 32-bit because I have an integrated device or I want to save the power or I want to save the space of my die. I'm not going to have that much memory for whatever reason they've been trolling around in the 32-bit x86 environment. They've also said I don't want to have any BIOS. I don't want to have that legacy environment at all so I want to jump all the way out here to a class three device. An example here for us were HP's ElitePad in their NVX2 personal devices and they had their own reasons that they chose a 32-bit x86 for those but they also implemented a class three UEFI. So as it says here, unfortunately, these are almost all closed systems so we don't have to worry about supporting UEFI option ROMs for IO cards because there aren't any IO slots. These are all just sealed up devices. In order for operating systems to work on this they have to support UEFI for a 32-bit x86 to be able to run on these devices. It's confusing because for traditional PCs, all the operating systems have only been supporting 64-bit UEFI. For these closed systems though, Android and Windows 8 do support UEFI for a 32-bit x86. So it's just a strange thing right now but it's one of these things where they sort of picked one thing from the past and one thing from the future and welded it together and so as far as being able to grab one of these devices and repurpose it with Linux it's gonna be a little bit of a challenge for you. So the call to action. The first call to action is to participate. So we have UEFI forum membership is available at the corporate level. It's available for individuals as well. Now the specifications and everything of course are all available as well and then certainly the tests as well. Open source contributions. We have channelcore.org and Lenaro as two open source communities that you can collaborate with and you can help improve the user experience. And again this is where I would certainly invite people. We'll have here the plug fest but you know just if you see something with a poor UEFI interface that doesn't support multi-boot very well I've seen implementations where they would only have you say yeah we support multi-boot but they only show one boot entry at a time and the first one is taken up by Windows. So it's like well yeah you sort of do it and we call it and say well then you need to execute this shell command and it reminded me of the old boot kind of pass we had to do on HPU XPA risk systems back in 1995 where if you didn't know the exact incantation of boot path things to enter in this it wasn't gonna work and that's not friendly. And so we made sure we gave some feedback there and supporting user friendly UEFI secure boot management user interfaces. How do I get from user mode to setup mode? How do I get back? How do I enroll a key? How do I de-enroll a key? How do I wipe back into factory refresh? Those are all things that again you'll often find those are on the less pretty screens because they're not the ones that people are expecting to be used a lot but if you need to use them and they're not adequate then you really do need to let everyone know that and make sure that we get those continuous improvements into those and the best way to do that is to try it out and complain if it doesn't work. So with that, we'll flip open to some questions though I will admit that I might point you at Dong when he gets here on Wednesday for more technical questions since I'm filling in for him some degree today but we'll open it up and please do use the microphone because they're recording the sessions we wanna make sure everyone can hear you on the tape. We have a question, do you know really explanation why UFI secure build could be disabled on x86 platform but it couldn't be disabled on ARM platforms? I don't know why. I'm sorry, I didn't understand the question. Could you explain why secure build mode could be disabled on x86 platforms but it couldn't be disabled on ARM platforms? So if you're talking about like the Microsoft products that was an implementation decision by the implementers there's nothing in the specifications that says you should or should not have it. Secure boot is an optional feature in the UEFI specifications. Now in the case of Microsoft they have decided on their general purpose x86 platform specifications to say that you need to include a switch to have it off. They decided not to include that requirement in their ARM products. There's nothing about the specifications that says you should or you shouldn't have it. It says if you implement secure boot here's the specification for secure boot but it is an optional feature. Okay, thank you. Early on one of your slides you talked about differentiation. Earlier you talked about differentiation and you gave examples of the GUI tools. So I only care about servers and historically one of the problems we had with server vendors was either a focus on Windows features or a focus on GUIs and they tried to transport that into the server world where we want headless servers and so the examples you gave heightened my fears because that's exactly the thing we don't want is that type of approach and if you're in the business of sending servers you're sending the wrong message to people who care about servers. So differentiation for us has always meant bloat and lack of control of the underlying platform and examples you gave drive that point home we'd like to just jump into the Linux as early as possible and we don't want differentiation. We want a common set of biases just like we do install Linux and it doesn't really matter what the hardware is. We'd like a common firmware experience and it shouldn't matter who the vendor is but this opens the door for more pain for us in the future. How are you gonna address that? So I think what I would say is that you are correct and the differentiation is layered on top of the standard specifications. However, I think by standardizing things like the shell we do provide you with those ubiquitous, low level, non-human interface driven capabilities to interface and to interact with the system. I think it does provide you easier ways to get your payloads installed on the platforms and running as quickly as possible. The fact that we can have the UFI utilities that you can write once and then put out onto any platform, the fact that we've added things like the asynchronous IO allowing you to have a richer set of UEFI utilities is going to be an interesting thing for you as an enterprise server focused user of UEFI based platforms. So I think don't worry about the eye candy. It's there for personal systems to help them with configuration and the like but as far as where did UEFI have a genesis on big iron, titanium and now x86 hardware? So I think it was designed and conceived by enterprise architects for that environment. The fact that it can be extended down to the personal systems and add these kinds of features I think is just a testament to the flexibility that those original shapers had in designing a platform that could span from laser jets all the way through Superdome's. Don't worry, it's on. With the secure boot, you're allowing changing of the keys, haven't you just opened the door for hackers? So you can open the system, you can disable secure boot and then not have it. Now if you're talking about then turning it back on and using it in a secure manner, then you do, if you've signed with the keys and you have the platform key and you have secure boot turned on, then you're still validating against the keys that were put in there. Now if someone has physical access to the system then they can do whatever they want to it. So I don't think that there's a difference in the platform because the operating system code is gonna be checking down and it will check this. So if you have the full chain there then there's not a way for you to come in and put in a different key. So we can have a discussion and we can get it going to explain it to you but I think the bottom line is we wanted people to have the flexibility. If you're using the proprietary stack that's been buttoned up from top to bottom then you can do that. If you wanna turn it all off, you can do that. If you wanna generate your own keys and the layers above, then you can do that. The specifications are just there as a way to provide a standard implementation of those mechanisms. So as you mentioned with the propagation of secure boot into enterprise and then the comment of no known circumventions yet secure boot, if it's properly implemented what steps are being taken maybe by the UEFI group to have a set of tests to ensure that you've properly implemented secure boot or if you just happen to have bugs is it on the vendor that gets screwed up and then has their stuff compromised. So how are you making sure that that's going to be secure booting secure boot? I think that's one of those questions I'm gonna have to toss to Dong and see what he's doing in the security working group. And also how they work with the testing working group. So he'll be here on Wednesday or you can email him or you pass it on to me and I'll get it to him and see where he is on driving those discussions and extending the testing. I think part of this also is just, it's also new and I know some of the things that came out at like the black hat not too long ago were some of the examples here where that was examples of poor implementation that is one of those things until you get out there and getting the security experts really probing these things that you're gonna take some time to ferret out all the vulnerabilities that you've created with implementation decisions. I think it's quite useful to agree on our terminology. What we've talked a lot about differentiation or value add. I'm not quite sure how many people realize that most people will call that value subtract. We're talking about excuses for common features, common user requirements to be gratuitously different, gratuitously absent or broken rather than just implemented once in EDG A2 everybody uses the same thing. Is there any prospect of maybe starting to improve on that? You know, this is always a challenge in standardization and I've been in many different kinds of standards bodies and everyone wants to standardize as much as they have to and no more. I mean, that's just because in the end they want a reason for you to choose their something over someone else's something. And this is one of the ways iCandy and features that are rich in this manner is one way for people to be able to differentiate themselves. You may not appreciate it but they do need to find some way of making themselves different. Oh, well, they manage that. They are very different and that makes users sad. This is why we call it value subtract. There is a disconnect here. And I would certainly encourage you to make that known. If you don't like it, then that's the best thing. And the great thing about amplification of our opinions through social media is it's more powerful when we can share that feedback and have it be amplified and then and hopefully if you don't like it and you get enough people to agree with you then that can resonate. So I think that's certainly an opportunity but this is just the general nature of standards bodies. You will standardize to a certain level and then you all sort of take one step back and think about, okay, we're all gonna be at this level. How are we all gonna be a little bit different at the next level? And I can appreciate your sentiments but it's gonna be difficult to convince people not to try and be better than the other guy. In whatever way they measure that is certainly another implementation detail. I have a question about the Tianokor reference implementation. When new features are added to the spec and then implemented in the reference implementation, to what degree do different vendors pull from the Tianokor implementation into their respective distributions? I'm sorry, there was noise coming in from the door there. Okay, so our, is the reference implementation pulled into the respective OEMs implementations of UEFI? Some of them do. Some of them pull the reference code and send it out. It just depends on the individual OEM. Do they pull pieces of the reference code? Do they pull the entire thing? We certainly have many, many engineers working on UEFI modules for our implementation that's a little bit different. It also depends upon what architecture you're pulling from and whether or not they pull entirely of Tianokor.org or they just pull pieces. So it varies from OEM to OEM. How much of the Tianokor they pull, where they pull everything and then how much they add in above that. So it will definitely vary from OEM to OEM. One last question. Thank you very much. Have a good conference.