It has a number of gaps, but it is mostly there. It doesn't build, it doesn't have source for some of the service calls iirc (SVC_.*), and the AGESA source isn't open (though a replacement is in progress, openSIL).
Good post on troubleshooting the failure to boot, but from the title I was kind of hoping for something like decryption and analysis of the blobs' contents, rather than just metadata. Very "cool" that 3 megabytes of unauditable malware (the public blobs) are still not enough to even boot the platform...
I can't wait for a modern system with an open firmware. Just so that there would be any hope for bugfixes outside "works for (default configuration) Windows".
It's all about incentives. My laptop spends good five seconds after each power-on (or resume from suspend-to-disk), showing me giant vendor's logo and doing nothing else.
Surely, open firmware could skip that and boot faster - if vendor would allow an escape hatch from the "secure boot" hell. But why would they expend effort on something 99.9% of users don't care about, and give up free ads in the process, too?
It is not so easy on servers. The AMD servers platforms perform RAM training on each boot, even before the CPU starts execution the firmware. So no matter of your BIOS/coreboot performance, you have a guaranteed 2min++ boot time (depending on amount of RAM and CPU sockets), because of memory training... There is no concept of fastboot from the cold boot like on Intel silicon.
The blog post describes the analysis of PSP blobs on Gigabyte. MZ33-AR1. The analysis covers various aspects of stitching AMD firmware BIOS images and how support for stitching Turin blobs was developed in coreboot.
This is a ridiculously cool blogpost. Thanks for sharing. Lots of detail.
Since you've looked at the firmware there quite a lot would you be able to share if you noticed if ES/QS CPUs have different configurations in the firmware or if it's just a matter of duplicating and renaming so that they're recognized?
I did not have any encounters with ES CPUs from AMD. I just remember my experience with Intel ES CPUs, which used a different set of keys for blob signing. I connected the dots and assumed that this is also true for AMD.
It is not about the configuration but rather a key burned into the CPU silicon that is used to verify the key used in blobs and the signatures of the blobs.
Source for the ASP firmware is at https://github.com/amd/AMD-ASPFW.
It has a number of gaps, but it is mostly there. It doesn't build, it doesn't have source for some of the service calls iirc (SVC_.*), and the AGESA source isn't open (though a replacement is in progress, openSIL).
This is the source of only a single application (out of 30 or 40?). :)
Good post on troubleshooting the failure to boot, but from the title I was kind of hoping for something like decryption and analysis of the blobs' contents, rather than just metadata. Very "cool" that 3 megabytes of unauditable malware (the public blobs) are still not enough to even boot the platform...
I can't wait for a modern system with an open firmware. Just so that there would be any hope for bugfixes outside "works for (default configuration) Windows".
It's all about incentives. My laptop spends good five seconds after each power-on (or resume from suspend-to-disk), showing me giant vendor's logo and doing nothing else.
Surely, open firmware could skip that and boot faster - if vendor would allow an escape hatch from the "secure boot" hell. But why would they expend effort on something 99.9% of users don't care about, and give up free ads in the process, too?
It is not so easy on servers. The AMD servers platforms perform RAM training on each boot, even before the CPU starts execution the firmware. So no matter of your BIOS/coreboot performance, you have a guaranteed 2min++ boot time (depending on amount of RAM and CPU sockets), because of memory training... There is no concept of fastboot from the cold boot like on Intel silicon.
The blog post describes the analysis of PSP blobs on Gigabyte. MZ33-AR1. The analysis covers various aspects of stitching AMD firmware BIOS images and how support for stitching Turin blobs was developed in coreboot.
This is a ridiculously cool blogpost. Thanks for sharing. Lots of detail.
Since you've looked at the firmware there quite a lot would you be able to share if you noticed if ES/QS CPUs have different configurations in the firmware or if it's just a matter of duplicating and renaming so that they're recognized?
I did not have any encounters with ES CPUs from AMD. I just remember my experience with Intel ES CPUs, which used a different set of keys for blob signing. I connected the dots and assumed that this is also true for AMD.
It is not about the configuration but rather a key burned into the CPU silicon that is used to verify the key used in blobs and the signatures of the blobs.