Open Source Firmware status on AMD platforms 2022
Żygowski, Michał
This is the 3rd edition of the "Status of AMD platform in coreboot". The talk will cover the most recent news around the AMD support in open source firmware ecosystem and updates of the topics covered in previous years. We would like to present status of FSF RYF KGPE-D16 platform revival and related upstreaming effort, TrenchBoot progress for AMD platforms and status of recent support in coreboot and oreboot projects. Finally we would like to present Dasharo - open source firmware distribution with long term stable support for older AMD platforms. The history of AMD cooperation in coreboot projects reaches 2007 where the first contribution appeared for the Geode LX processors. AMD's open-source support continued for many years until now (with some break). This presentation will briefly repeat the history of AMD and open source firmware. Moreover, recent coreboot releases started to enforce certain requirements on the features supported by the silicon code base. Aging platforms kept losing interest and many of them (including fully open ones) starting to cause unjustifiable overhead, because of accumulated technical debt. Most probably it will result in similar situation as with famous 4.11 branch becoming de facto stable branch for some platforms (e.g. FSP1.0 Bay Trail or ASUS KGPE-D16). Nowadays AMD is releasing the newest AGESA with the cooperation of hired coreboot developers, but charter covers modern Ryzen-based processors. We trying to support the AMD platforms by reimplementing the ASUS KGPE-D16 (FSF RYF platform) support in coreboot and keeping the PC Engines platforms in the top of tree. We would like to present Dasharo plan for long term stable and sustainable support for older platforms. If you are interested in open source firmware for most open x86 platforms on the market feel free to tune in and discuss the ideas with us.
 Hello, and welcome to my presentation about open source firmware status on AMD platforms 2022 on open source firmware BMC and Bitloader DevRom 2022. My name is Mikhail Zhigovsky and I'm a firmware engineer at 3MDep. I'm mainly interested in open source firmware advanced hardware and firmware security features. I maintain Brasswell SOC, PCNG and protect me platforms in Corvud. I'm also open power system software technical world group chair. I am nearly four years in the open source firmware ecosystem. Who are you exactly? 3MDep is Corvud licensed service provider since 2016 and UEFI adopters since 2018. We also are a Yocto participants and embedded Linux experts since 2019. We of course provide official consensus services for Linux foundation FWPDLVFS project since 2020. We are also a BM OpenPower Foundation members since 2020. A few definitions that I will use across this presentation. AGISA which stands for AMD Generic Encapsulated Software Architecture. It pronounces somewhat like PISA, AGISA. It is a process initialization code supplied by AMD to bios vendors. You can easily call it an FSB equivalent but for AMD. However, it requires NDA and sometimes special relations to get your hands on it. Well, despite it being compliant with UEFI interface, it does not support open source toolchain like GCL or LLVM. If you want to know more about AGISA history please refer to our presentation from fall 2020 where I talk a little bit more about this evolution. AMD security processor commonly referred to as BSP, so platform security processors. It is an AMD equivalent to inter-management engine. Also a coprocessor but it lives on the CPU itself, the chipset. And this is a performing customer operations plant on me. Some security, cryptography, CPU bring up as well and stuff. There are also a lot of processor code names and architecture names which may be found on Wikipedia in CPUward.com. I will go briefly through the ones that we mentioned during the presentation. We have a few names like macro-acticture names and core-acticture names. For example, Puma is a step-eagle core-acticture. Embedded SOCs which are for example on PCNG's APO2. Boudota and PyDriver are for example server processors based on Interligas or Abu Dhabi core-acticture. Which are used for example on KGPD16. PyDriver is also a micro-acticture name for Trinity core architecture processors which are mobile APUs which are for example used for Lenovo G505S. And we have all the modern Zen micro-architectures called Picasso and Cezanne. These are Zen plus and Zen free core architectures with Ryzen 3000 and 5000 series. Cezanne is pretty new in Corbett and recently we have also may find Sabrina processors which are being added in Corbett however and there is not much information about them yet. All we know that it is family 17H models which vary from AO-Hacks to AF-Hacks. So a short recap from Master about the new platform support in Corbett. There were two micro-architectures being added by AMD. It is Caso and Cezanne. These are the mobile processors that are used on the Chromebooks. Picasso was already pretty much complete last year in 2021. But now we have almost complete AMD Cezanne support which initial patches were issued last year. There was also the AMD Majugola reference board support update and everything took a little bit of time because of the groundbreaking changes to the architecture. I am specifically referring to the RAM training which is done by the AMD PSP now. The course which actually leave out the reset with the RAM already available. So the today's status is that the Picasso and Cezanne are complete and usable although the Cezanne FSP is not yet published. There are also some other patches that for example implement BIOS and B partition recovery and an AMD FW tool or PSP firmware extraction and AMD FW tool. The similar functionality is provided by the PSP tool which was developed over one year ago by PSP reverse team on GitHub and published and announced on Chaos Computing Conference. There are also some first patches for Sabrina as I mentioned which you may find under the links. The past year was rather more on negative side than on positive regarding the older AMD platforms. You may see corporate mailing lists threats or leadership meeting minutes for some evidence. I will also be covering this topic in next slides. The AMD server status. In 2021 on open source firmware conference, Ron Wienig from Google presented an open source firmware on AMD Epic Chrome server board which were running Orbot in Rust and he managed to boot links kernel using this implementation. And of course we had some rumors that there is a chance that AMD servers will also get some open source firmware support. However, there is no updates about it up to date unfortunately, neither on the Orbot's implementation done by Ron. The last issue was that the IO devices were not initialized correctly so it was unable to boot from any storage media and of course it has not been resolved yet. You may also visit the open source firmware sectionals and you can find there some concerning information about the open source firmware support and servers. How the future will shape the AMD open source firmware. In 2021 we had pretty much negative attitude to the old AMD platforms. Many platforms have been dropped from the tree. There are also a lot of complaints on the code quality. There are many copy paste code in the repository. The official explanation of Orbot leadership why the code ended up in such state is that this code was landed in without much review and AMD was supposed to clean up this code base. However, these promises haven't been fulfilled up to date so this is why it ended up in such state. And nowadays new code boot releases come with new feature and options deprecation announcements. These announcements just say which Orbot interfaces will be deprecated, which will be removed from the main tree. And many older AMD platforms which did not implement such new interface for platform civilization or options as a result are of course getting dropped as well. But thanks to the companies like PC Engines who support the open source firmware development through FremDep some of the platforms still keep living in Corbot. For example we have a family 14 which supports APU1 devices and the support for the new interfaces in review. And for family 16 binary PI which is used for APU2 the support is already upstream and the platform won't be dropped for over half a year from now. The Trinity and KBini which is a family 15 and 16 open source AGSA platforms they still lack support for these interfaces and we welcome any donations if you want to have them supported. Donations I mean maybe material, maybe hands, testing or development, anything. We can also help with review if you upload some patches. The future of modern CPUs also is quite dark because recently we have sightings and reports that newest firmware on the AMD processors is enforcing the CPU lock. The CPU lock is related to enabling platform secure boot which is an equivalent of Intel boot guard but on AMD processors and it binds a certain platform key to the CPU. Because of that such CPU cannot be used in another platform with different firmware key if it was already used. Because it's a serious vendor of lock-in which steals the user freedom of firmware modifications and stuff. For example if one want to patch some firmware modules that would change the CPU allow list or any other hardware allow list or freely play CPUs it is no longer possible because you may end up with a locked CPU or just buy a locked CPU it cannot simply put it. This situation is much different from Intel because Intel boot guard uses the chipset so the CPU is still replaceable but you cannot simply run other firmware. For example such a sighting you may find on the link that some Lenovo machines automatically lock the CPUs and they display a screen to lock the CPU on each boot until you agree. However there is some ray of hope with Doshara. Doshara is a pre-emptive open source firmware distribution where we prefer some clean and simple code and long term maintenance also for older platforms. You want to respect privacy, liberty of the owners and trustworthiness of all. And as a sample of such implementation is the KGP D16 revival which has been sponsored by Immunify. It is one of the most performant and most recent truly blobless and library hardware which was certified with Resoftra Foundation Respect Your Freedom. The hardware was donated to us by Vikings which were also distributing this hardware for some time already and our main goal of Doshara on this platform is to provide some ready to flash binaries for various configurations of the platform. The core boot on this platform is based on middle between 4.15 and 4.14 release. It currently complies to all most recent core boot requirements and has a good note to be dropped because of these requirements. We plan to upstream the code soon to the main tree. So a little bit about the sponsor, Immunify is a leading back bounty and security service platform for web 3. They will go with KGPs to have a secure and trustworthy machine for the blockchain developers. This machine is widely used by Immunify and Resoftra Foundation as well. In short what we did for this platform was to rebase the old code onto the newest core boot source that were available on main branch and make it boot. Furthermore, we improved the security by implementing Vboot support and TPM 2.0 support for the board. The scope of the project also involved additional work related to flash write protection support in Flashroom so that we can, for example, using user space applications such as Flashroom to configure the block protection on the spy flash and set some write protection for the status register. For example, for platforms that may use some write protection pins. We also did some small modifications to the flash because by default this platform uses the IP8 flash which is a 2MB flash. For nowadays it is pretty small and we decided to provide a means to use a bigger flash with like 8 for example socket. So we provide some adapter that will have a 8 flash soldered on the adapter and we put this adapter into the deep 8 socket. We also modified the adapter in such a way that it exposes two pins for a write protection support pin jumper so that one may provision a static filter of trust or measurement using an immutable piece of code inside Flash. This is for KGP but there are also other platforms that are pretty similar in terms of used code and architecture and I mean specifically the ACS-KCMA-D8 and SuperMicro H8-SGM. They use the same common siliconization code as KGP D16 and they are also blobless platforms. We have not implemented the support for them because we do not own any hardware so if you want to get the support for these platforms please feel free to donate. It may not only be some financial donations but also hardware or hands to work or tests as well. We will present the sharehold plan for the long term stable and sustainable support folder platforms soon. If you want to know more about the recent news and information about the supported platforms please sign up to our the sharehold newsletter. Also I invite you to our after hours party which will be held right after the end of this dev room. We will discuss more about the open source firmware and its ecosystem in general. Also we plan to hold the sharehold V-PAP fourth edition on the 17th of February. We will be discussing also open source firmware topics and other stuff as well. So please book your time and come discuss with us. And time for questions. Thank you.
 Hello, and welcome to my presentation about open source firmware status on AMD platforms  2022 on open source firmware BMC and Bitloader DevRom 2022.  My name is Mikhail Zhigovsky and I'm a firmware engineer at 3MDep.  I'm mainly interested in open source firmware advanced hardware and firmware security features.  I maintain Brasswell SOC, PCNG and protect me platforms in Corvud.  I'm also open power system software technical world group chair.  I am nearly four years in the open source firmware ecosystem.  Who are you exactly?  3MDep is Corvud licensed service provider since 2016 and UEFI adopters since 2018.  We also are a Yocto participants and embedded Linux experts since 2019.  We of course provide official consensus services for Linux foundation FWPDLVFS project since  2020.  We are also a BM OpenPower Foundation members since 2020.  A few definitions that I will use across this presentation.  AGISA which stands for AMD Generic Encapsulated Software Architecture.  It pronounces somewhat like PISA, AGISA.  It is a process initialization code supplied by AMD to bios vendors.  You can easily call it an FSB equivalent but for AMD.  However, it requires NDA and sometimes special relations to get your hands on it.  Well, despite it being compliant with UEFI interface, it does not support open source  toolchain like GCL or LLVM.  If you want to know more about AGISA history please refer to our presentation from fall  2020 where I talk a little bit more about this evolution.  AMD security processor commonly referred to as BSP, so platform security processors.  It is an AMD equivalent to inter-management engine.  Also a coprocessor but it lives on the CPU itself, the chipset.  And this is a performing customer operations plant on me.  Some security, cryptography, CPU bring up as well and stuff.  There are also a lot of processor code names and architecture names which may be found  on Wikipedia in CPUward.com.  I will go briefly through the ones that we mentioned during the presentation.  We have a few names like macro-acticture names and core-acticture names.  For example, Puma is a step-eagle core-acticture.  Embedded SOCs which are for example on PCNG's APO2.  Boudota and PyDriver are for example server processors based on Interligas or Abu Dhabi  core-acticture.  Which are used for example on KGPD16.  PyDriver is also a micro-acticture name for Trinity core architecture processors which  are mobile APUs which are for example used for Lenovo G505S.  And we have all the modern Zen micro-architectures called Picasso and Cezanne.  These are Zen plus and Zen free core architectures with Ryzen 3000 and 5000 series.  Cezanne is pretty new in Corbett and recently we have also may find Sabrina processors which  are being added in Corbett however and there is not much information about them yet.  All we know that it is family 17H models which vary from AO-Hacks to AF-Hacks.  So a short recap from Master about the new platform support in Corbett.  There were two micro-architectures being added by AMD.  It is Caso and Cezanne.  These are the mobile processors that are used on the Chromebooks.  Picasso was already pretty much complete last year in 2021.  But now we have almost complete AMD Cezanne support which initial patches were issued  last year.  There was also the AMD Majugola reference board support update and everything took a  little bit of time because of the groundbreaking changes to the architecture.  I am specifically referring to the RAM training which is done by the AMD PSP now.  The course which actually leave out the reset with the RAM already available.  So the today's status is that the Picasso and Cezanne are complete and usable although  the Cezanne FSP is not yet published.  There are also some other patches that for example implement BIOS and B partition recovery  and an AMD FW tool or PSP firmware extraction and AMD FW tool.  The similar functionality is provided by the PSP tool which was developed over one year  ago by PSP reverse team on GitHub and published and announced on Chaos Computing Conference.  There are also some first patches for Sabrina as I mentioned which you may find under the  links.  The past year was rather more on negative side than on positive regarding the older  AMD platforms.  You may see corporate mailing lists threats or leadership meeting minutes for some evidence.  I will also be covering this topic in next slides.  The AMD server status.  In 2021 on open source firmware conference, Ron Wienig from Google presented an open source  firmware on AMD Epic Chrome server board which were running Orbot in Rust and he managed  to boot links kernel using this implementation.  And of course we had some rumors that there is a chance that AMD servers will also get  some open source firmware support.  However, there is no updates about it up to date unfortunately, neither on the Orbot's  implementation done by Ron.  The last issue was that the IO devices were not initialized correctly so it was unable  to boot from any storage media and of course it has not been resolved yet.  You may also visit the open source firmware sectionals and you can find there some concerning  information about the open source firmware support and servers.  How the future will shape the AMD open source firmware.  In 2021 we had pretty much negative attitude to the old AMD platforms.  Many platforms have been dropped from the tree.  There are also a lot of complaints on the code quality.  There are many copy paste code in the repository.  The official explanation of Orbot leadership why the code ended up in such state is that  this code was landed in without much review and AMD was supposed to clean up this code  base.  However, these promises haven't been fulfilled up to date so this is why it ended up in such  state.  And nowadays new code boot releases come with new feature and options deprecation announcements.  These announcements just say which Orbot interfaces will be deprecated, which will be removed from  the main tree.  And many older AMD platforms which did not implement such new interface for platform  civilization or options as a result are of course getting dropped as well.  But thanks to the companies like PC Engines who support the open source firmware development  through FremDep some of the platforms still keep living in Corbot.  For example we have a family 14 which supports APU1 devices and the support for the new  interfaces in review.  And for family 16 binary PI which is used for APU2 the support is already upstream and  the platform won't be dropped for over half a year from now.  The Trinity and KBini which is a family 15 and 16 open source AGSA platforms they still  lack support for these interfaces and we welcome any donations if you want to have them supported.  Donations I mean maybe material, maybe hands, testing or development, anything.  We can also help with review if you upload some patches.  The future of modern CPUs also is quite dark because recently we have sightings and reports  that newest firmware on the AMD processors is enforcing the CPU lock.  The CPU lock is related to enabling platform secure boot which is an equivalent of Intel  boot guard but on AMD processors and it binds a certain platform key to the CPU.  Because of that such CPU cannot be used in another platform with different firmware  key if it was already used.  Because it's a serious vendor of lock-in which steals the user freedom of firmware modifications  and stuff.  For example if one want to patch some firmware modules that would change the CPU allow list  or any other hardware allow list or freely play CPUs it is no longer possible because  you may end up with a locked CPU or just buy a locked CPU it cannot simply put it.  This situation is much different from Intel because Intel boot guard uses the chipset  so the CPU is still replaceable but you cannot simply run other firmware.  For example such a sighting you may find on the link that some Lenovo machines automatically  lock the CPUs and they display a screen to lock the CPU on each boot until you agree.  However there is some ray of hope with Doshara.  Doshara is a pre-emptive open source firmware distribution where we prefer some clean and  simple code and long term maintenance also for older platforms.  You want to respect privacy, liberty of the owners and trustworthiness of all.  And as a sample of such implementation is the KGP D16 revival which has been sponsored  by Immunify.  It is one of the most performant and most recent truly blobless and library hardware  which was certified with Resoftra Foundation Respect Your Freedom.  The hardware was donated to us by Vikings which were also distributing this hardware  for some time already and our main goal of Doshara on this platform is to provide some  ready to flash binaries for various configurations of the platform.  The core boot on this platform is based on middle between 4.15 and 4.14 release.  It currently complies to all most recent core boot requirements and has a good note to  be dropped because of these requirements.  We plan to upstream the code soon to the main tree.  So a little bit about the sponsor, Immunify is a leading back bounty and security service  platform for web 3.  They will go with KGPs to have a secure and trustworthy machine for the blockchain developers.  This machine is widely used by Immunify and Resoftra Foundation as well.  In short what we did for this platform was to rebase the old code onto the newest core  boot source that were available on main branch and make it boot.  Furthermore, we improved the security by implementing Vboot support and TPM 2.0 support for the  board.  The scope of the project also involved additional work related to flash write protection support  in Flashroom so that we can, for example, using user space applications such as Flashroom  to configure the block protection on the spy flash and set some write protection for the  status register.  For example, for platforms that may use some write protection pins.  We also did some small modifications to the flash because by default this platform uses  the IP8 flash which is a 2MB flash.  For nowadays it is pretty small and we decided to provide a means to use a bigger flash with  like 8 for example socket.  So we provide some adapter that will have a 8 flash soldered on the adapter and we put  this adapter into the deep 8 socket.  We also modified the adapter in such a way that it exposes two pins for a write protection  support pin jumper so that one may provision a static filter of trust or measurement using  an immutable piece of code inside Flash.  This is for KGP but there are also other platforms that are pretty similar in terms of used code  and architecture and I mean specifically the ACS-KCMA-D8 and SuperMicro H8-SGM.  They use the same common siliconization code as KGP D16 and they are also blobless platforms.  We have not implemented the support for them because we do not own any hardware so if you  want to get the support for these platforms please feel free to donate.  It may not only be some financial donations but also hardware or hands to work or tests  as well.  We will present the sharehold plan for the long term stable and sustainable support  folder platforms soon.  If you want to know more about the recent news and information about the supported platforms  please sign up to our the sharehold newsletter.  Also I invite you to our after hours party which will be held right after the end of  this dev room.  We will discuss more about the open source firmware and its ecosystem in general.  Also we plan to hold the sharehold V-PAP fourth edition on the 17th of February.  We will be discussing also open source firmware topics and other stuff as well.  So please book your time and come discuss with us.  And time for questions.  Thank you.
osf_on_amd_3rd_0_59.png osf_on_amd_3rd_60_107.png osf_on_amd_3rd_108_215.png osf_on_amd_3rd_216_419.png osf_on_amd_3rd_420_1139.png osf_on_amd_3rd_1140_1979.png osf_on_amd_3rd_1980_4091.png osf_on_amd_3rd_4092_6131.png osf_on_amd_3rd_6132_7595.png osf_on_amd_3rd_7596_9443.png osf_on_amd_3rd_9444_11063.png osf_on_amd_3rd_11064_12263.png osf_on_amd_3rd_12264_14387.png osf_on_amd_3rd_14388_16691.png osf_on_amd_3rd_16692_17315.png osf_on_amd_3rd_17316_18887.png osf_on_amd_3rd_18888_22043.png osf_on_amd_3rd_22044_23423.png osf_on_amd_3rd_23424_24311.png osf_on_amd_3rd_24312_24443.png osf_on_amd_3rd_24444_24559.png
Hello, and welcome to my presentation about open source firmware status on AMD platforms 2022 on open source firmware BMC and Bitloader DevRom 2022. My name is Mikhail Zhigovsky and I'm a firmware engineer at 3MDep. I'm mainly interested in open source firmware advanced hardware and firmware security features. I maintain Brasswell SOC, PCNG and protect me platforms in Corvud. I'm also open power system software technical world group chair. I am nearly four years in the open source firmware ecosystem. Who are you exactly? 3MDep is Corvud licensed service provider since 2016 and UEFI adopters since 2018. We also are a Yocto participants and embedded Linux experts since 2019. We of course provide official consensus services for Linux foundation FWPDLVFS project since 2020. We are also a BM OpenPower Foundation members since 2020. A few definitions that I will use across this presentation. AGISA which stands for AMD Generic Encapsulated Software Architecture. It pronounces somewhat like PISA, AGISA. It is a process initialization code supplied by AMD to bios vendors. You can easily call it an FSB equivalent but for AMD. However, it requires NDA and sometimes special relations to get your hands on it. Well, despite it being compliant with UEFI interface, it does not support open source toolchain like GCL or LLVM. If you want to know more about AGISA history please refer to our presentation from fall 2020 where I talk a little bit more about this evolution. AMD security processor commonly referred to as BSP, so platform security processors. It is an AMD equivalent to inter-management engine. Also a coprocessor but it lives on the CPU itself, the chipset. And this is a performing customer operations plant on me. Some security, cryptography, CPU bring up as well and stuff. There are also a lot of processor code names and architecture names which may be found on Wikipedia in CPUward.com. I will go briefly through the ones that we mentioned during the presentation. We have a few names like macro-acticture names and core-acticture names. For example, Puma is a step-eagle core-acticture. Embedded SOCs which are for example on PCNG's APO2. Boudota and PyDriver are for example server processors based on Interligas or Abu Dhabi core-acticture. Which are used for example on KGPD16. PyDriver is also a micro-acticture name for Trinity core architecture processors which are mobile APUs which are for example used for Lenovo G505S. And we have all the modern Zen micro-architectures called Picasso and Cezanne. These are Zen plus and Zen free core architectures with Ryzen 3000 and 5000 series. Cezanne is pretty new in Corbett and recently we have also may find Sabrina processors which are being added in Corbett however and there is not much information about them yet. All we know that it is family 17H models which vary from AO-Hacks to AF-Hacks. So a short recap from Master about the new platform support in Corbett. There were two micro-architectures being added by AMD. It is Caso and Cezanne. These are the mobile processors that are used on the Chromebooks. Picasso was already pretty much complete last year in 2021. But now we have almost complete AMD Cezanne support which initial patches were issued last year. There was also the AMD Majugola reference board support update and everything took a little bit of time because of the groundbreaking changes to the architecture. I am specifically referring to the RAM training which is done by the AMD PSP now. The course which actually leave out the reset with the RAM already available. So the today's status is that the Picasso and Cezanne are complete and usable although the Cezanne FSP is not yet published. There are also some other patches that for example implement BIOS and B partition recovery and an AMD FW tool or PSP firmware extraction and AMD FW tool. The similar functionality is provided by the PSP tool which was developed over one year ago by PSP reverse team on GitHub and published and announced on Chaos Computing Conference. There are also some first patches for Sabrina as I mentioned which you may find under the links. The past year was rather more on negative side than on positive regarding the older AMD platforms. You may see corporate mailing lists threats or leadership meeting minutes for some evidence. I will also be covering this topic in next slides. The AMD server status. In 2021 on open source firmware conference, Ron Wienig from Google presented an open source firmware on AMD Epic Chrome server board which were running Orbot in Rust and he managed to boot links kernel using this implementation. And of course we had some rumors that there is a chance that AMD servers will also get some open source firmware support. However, there is no updates about it up to date unfortunately, neither on the Orbot's implementation done by Ron. The last issue was that the IO devices were not initialized correctly so it was unable to boot from any storage media and of course it has not been resolved yet. You may also visit the open source firmware sectionals and you can find there some concerning information about the open source firmware support and servers. How the future will shape the AMD open source firmware. In 2021 we had pretty much negative attitude to the old AMD platforms. Many platforms have been dropped from the tree. There are also a lot of complaints on the code quality. There are many copy paste code in the repository. The official explanation of Orbot leadership why the code ended up in such state is that this code was landed in without much review and AMD was supposed to clean up this code base. However, these promises haven't been fulfilled up to date so this is why it ended up in such state. And nowadays new code boot releases come with new feature and options deprecation announcements. These announcements just say which Orbot interfaces will be deprecated, which will be removed from the main tree. And many older AMD platforms which did not implement such new interface for platform civilization or options as a result are of course getting dropped as well. But thanks to the companies like PC Engines who support the open source firmware development through FremDep some of the platforms still keep living in Corbot. For example we have a family 14 which supports APU1 devices and the support for the new interfaces in review. And for family 16 binary PI which is used for APU2 the support is already upstream and the platform won't be dropped for over half a year from now. The Trinity and KBini which is a family 15 and 16 open source AGSA platforms they still lack support for these interfaces and we welcome any donations if you want to have them supported. Donations I mean maybe material, maybe hands, testing or development, anything. We can also help with review if you upload some patches. The future of modern CPUs also is quite dark because recently we have sightings and reports that newest firmware on the AMD processors is enforcing the CPU lock. The CPU lock is related to enabling platform secure boot which is an equivalent of Intel boot guard but on AMD processors and it binds a certain platform key to the CPU. Because of that such CPU cannot be used in another platform with different firmware key if it was already used. Because it's a serious vendor of lock-in which steals the user freedom of firmware modifications and stuff. For example if one want to patch some firmware modules that would change the CPU allow list or any other hardware allow list or freely play CPUs it is no longer possible because you may end up with a locked CPU or just buy a locked CPU it cannot simply put it. This situation is much different from Intel because Intel boot guard uses the chipset so the CPU is still replaceable but you cannot simply run other firmware. For example such a sighting you may find on the link that some Lenovo machines automatically lock the CPUs and they display a screen to lock the CPU on each boot until you agree. However there is some ray of hope with Doshara. Doshara is a pre-emptive open source firmware distribution where we prefer some clean and simple code and long term maintenance also for older platforms. You want to respect privacy, liberty of the owners and trustworthiness of all. And as a sample of such implementation is the KGP D16 revival which has been sponsored by Immunify. It is one of the most performant and most recent truly blobless and library hardware which was certified with Resoftra Foundation Respect Your Freedom. The hardware was donated to us by Vikings which were also distributing this hardware for some time already and our main goal of Doshara on this platform is to provide some ready to flash binaries for various configurations of the platform. The core boot on this platform is based on middle between 4.15 and 4.14 release. It currently complies to all most recent core boot requirements and has a good note to be dropped because of these requirements. We plan to upstream the code soon to the main tree. So a little bit about the sponsor, Immunify is a leading back bounty and security service platform for web 3. They will go with KGPs to have a secure and trustworthy machine for the blockchain developers. This machine is widely used by Immunify and Resoftra Foundation as well. In short what we did for this platform was to rebase the old code onto the newest core boot source that were available on main branch and make it boot. Furthermore, we improved the security by implementing Vboot support and TPM 2.0 support for the board. The scope of the project also involved additional work related to flash write protection support in Flashroom so that we can, for example, using user space applications such as Flashroom to configure the block protection on the spy flash and set some write protection for the status register. For example, for platforms that may use some write protection pins. We also did some small modifications to the flash because by default this platform uses the IP8 flash which is a 2MB flash. For nowadays it is pretty small and we decided to provide a means to use a bigger flash with like 8 for example socket. So we provide some adapter that will have a 8 flash soldered on the adapter and we put this adapter into the deep 8 socket. We also modified the adapter in such a way that it exposes two pins for a write protection support pin jumper so that one may provision a static filter of trust or measurement using an immutable piece of code inside Flash. This is for KGP but there are also other platforms that are pretty similar in terms of used code and architecture and I mean specifically the ACS-KCMA-D8 and SuperMicro H8-SGM. They use the same common siliconization code as KGP D16 and they are also blobless platforms. We have not implemented the support for them because we do not own any hardware so if you want to get the support for these platforms please feel free to donate. It may not only be some financial donations but also hardware or hands to work or tests as well. We will present the sharehold plan for the long term stable and sustainable support folder platforms soon. If you want to know more about the recent news and information about the supported platforms please sign up to our the sharehold newsletter. Also I invite you to our after hours party which will be held right after the end of this dev room. We will discuss more about the open source firmware and its ecosystem in general. Also we plan to hold the sharehold V-PAP fourth edition on the 17th of February. We will be discussing also open source firmware topics and other stuff as well. So please book your time and come discuss with us. And time for questions. Thank you.
source firmware status on AMD platforms 2022 on in open source firmware advanced hardware and source firmware ecosystem. Who are you exactly? history please refer to our presentation from the new platform support in Corbett. There were now. The course which actually leave out the code base. However, these promises haven't been releases come with new feature and options tree. And many older AMD platforms which did not civilization or options as a result are of course companies like PC Engines who support the open any donations if you want to have them supported. newest firmware on the AMD processors is simply put it. This situation is much different open source firmware distribution where we prefer maintenance also for older platforms. You want to implementation is the KGP D16 revival which has been sponsored by Immunify. It is one of the most because of these requirements. We plan to you want to get the support for these platforms please feel free to donate. It may not only be some financial donations but also hardware or the sharehold plan for the long term stable and sustainable support folder platforms soon. If you want to know more about the recent news and will discuss more about the open source firmware