thesofproject
[FEATURE] enable loading alternate builds?
Since most hardware manufacturers require Intel signatures on SOF binaries, most people who have hardware that can run SOF can't modify, rebuild and reinstall SOF. In addition the distributions that package SOF can't build SOF from source and have users load their SOF binaries. It would be nice if both or either of these could happen.
I can think of three ways for that to happen:
Intel could require or otherwise incentivise hardware manufacturers that they allow unsigned SOF binaries to be loaded. Then Intel would publish a list of hardware manufacturers that comply with this.
Intel could regularly audit the distribution SOF source packages, check that the distro source matches the upstream source, us Reproducible Builds to prove that the source matches the binaries, offer detached signatures of the distro binaries and have the distros integrate those signatures. The signing of @rhboot shim binaries works in this way.
Intel ME could have a list of keys that are used to verify SOF binaries before use, that can be modified by UEFI, then the @rhboot shim project could automatically add distro keys and the Secure Boot machine owner keys to the list as well as allow modification of the list by a physically present user.
Are any of these ideas feasible for Intel to implement?
What is the reason that some hardware manufacturers require Intel signatures on SOF binaries but others do not?
@pabs3 thanks for the question, fwiw this is something we are trying to improve in the future for the community and it wont be an immediate fix.
Since most hardware manufacturers require Intel signatures on SOF binaries, most people who have hardware that can run SOF can't modify, rebuild and reinstall SOF. In addition the distributions that package SOF can't build SOF from source and have users load their SOF binaries. It would be nice if both or either of these could happen.
Signing is used by some Intel and AMD (and maybe other vendors too) based devices to provide a secure computing environment (alongside the OS signing) and is a certification requirement by some OS vendors.
The FW signing is bypassed on Chromebooks or on developer boards like the UP boards by using a public signing key.
I can think of three ways for that to happen:
Intel could require or otherwise incentivise hardware manufacturers that they allow unsigned SOF binaries to be loaded. Then Intel would publish a list of hardware manufacturers that comply with this.
Intel could regularly audit the distribution SOF source packages, check that the distro source matches the upstream source, us Reproducible Builds to prove that the source matches the binaries, offer detached signatures of the distro binaries and have the distros integrate those signatures. The signing of @rhboot shim binaries works in this way.
Intel ME could have a list of keys that are used to verify SOF binaries before use, that can be modified by UEFI, then the @rhboot shim project could automatically add distro keys and the Secure Boot machine owner keys to the list as well as allow modification of the list by a physically present user.
Are any of these ideas feasible for Intel to implement?
There are security and certification reasons why some of the above may not work well for everyone, but there are also other alternatives that may be possible in the future. e.g. it may be possible to use a similar solution to the BIOS OS secure boot menu.
What is the reason that some hardware manufacturers require Intel signatures on SOF binaries but others do not?
That's really up to each OEM.
@lgirdwood thanks for the response and it is great to hear that this is being worked on, I look forward to hearing any developments on this and encourage you to post updates here when they happen.
I'm curious why the Chromebooks in developer mode and developer boards require the public community key instead of allowing unsigned firmware? Signing with the public community key seems to add no value here.
I think it would be useful for the website to have hardware page with a comprehensive list of the hardware that supports SOF, broken down by which hardware supports unsigned binaries, which hardware requires the community key, which hardware requires the Intel key, which hardware requires the AMD key and which hardware has user-configurable keys.
Re your suggestion of a solution similar to the UEFI secure boot menu, that has some downsides, mostly the same ones that lead to the development of the @rhboot shim tool. Every UEFI firmware vendor will have a different UEFI UI, which means that distro documentation for the menu will have a lot of complexity since it will have to document the procedure for every vendor quirk. Then some vendors will accidentally or deliberately not allow disabling secure boot. Some other vendors won't allow adding keys to the list of trusted keys. Some other vendors won't allow removing keys from the list of trusted keys. Some UEFI vendors interfaces will be very buggy. The shim tool solves these issues, which is why I suggest placing the sound firmware key management into it. I think it is essential that the possibility of shim being able to manage the keys is allowed.
-- bye, pabs
https://bonedaddy.net/pabs3/
@lgirdwood thanks for the response and it is great to hear that this is being worked on, I look forward to hearing any developments on this and encourage you to post updates here when they happen. I'm curious why the Chromebooks in developer mode and developer boards require the public community key instead of allowing unsigned firmware? Signing with the public community key seems to add no value here.
There is a lot of infra that expects a signature here, so this is a workaround so that no other changes are needed in the other ingredients.
I think it would be useful for the website to have hardware page with a comprehensive list of the hardware that supports SOF, broken down by which hardware supports unsigned binaries, which hardware requires the community key, which hardware requires the Intel key, which hardware requires the AMD key and which hardware has user-configurable keys.
That could be a big list, we already have a platform list on sof docs, but in general Intel based Chromebooks and UP boards all use the public signing key. All other Intel platforms should use the private Intel key.
Re your suggestion of a solution similar to the UEFI secure boot menu, that has some downsides, mostly the same ones that lead to the development of the @rhboot shim tool. Every UEFI firmware vendor will have a different UEFI UI, which means that distro documentation for the menu will have a lot of complexity since it will have to document the procedure for every vendor quirk. Then some vendors will accidentally or deliberately not allow disabling secure boot. Some other vendors won't allow adding keys to the list of trusted keys. Some other vendors won't allow removing keys from the list of trusted keys. Some UEFI vendors interfaces will be very buggy. The shim tool solves these issues, which is why I suggest placing the sound firmware key management into it. I think it is essential that the possibility of shim being able to manage the keys is allowed. … -- bye, pabs https://bonedaddy.net/pabs3/
We need to live within the requirements of other OSes too and we need a full security review. Fwiw, there is a key manifest in the BIOS today (which can be used by OEMs) to add keys but this is locked at production by blowing fuses.
@lgirdwood Thanks for the details, that makes sense given current constraints.
Please do consider allowing shim to manage the keys too though.
-- bye, pabs
https://bonedaddy.net/pabs3/
Signing is used by some Intel and AMD (and maybe other vendors too) based devices to provide a secure computing environment (alongside the OS signing) and is a certification requirement by some OS vendors.
@lgirdwood Forgive me for the ignorance, but why would you need a secure computing environment for processing and playing back sound? I don't see how malicious code would be prevented from doing bad things by using such a "secure computing environment" for sound processing that they couldn't do anyway. Also why would signing sound processing firmware be a certification requirement? The OS vendor could choose to only load signed firmware if it wants to have quality assurance without forcing other OSes to use the same signed firmware, right?
It is what is is @bjorn3. Some OEMs such as Google (Chromebooks) and AEON (Up boards) removed the requirement and allowed community-signed code to run on the hardware they sell, others require a production key specific to their hardware. It's their decision.
@bjorn3 running FW can't be scanned by anti-virus and can DMA master on some HW.
The same argument can be made for the uefi firmware, right? That one isn't signed either except on server platforms as optional feature (and maybe mobile platforms) as far as I am aware. I don't know who loads the SOF firmware, but if the UEFI firmware does this, it can be responsible for checking the signature and if a driver loads it, so can this driver.
There are security and certification reasons why some of the above may not work well for everyone, but there are also other alternatives that may be possible in the future. e.g. it may be possible to use a similar solution to the BIOS OS secure boot menu.
What is the reason that some hardware manufacturers require Intel signatures on SOF binaries but others do not?
That's really up to each OEM.
As with Intel Boot Guard, this approach leads to the worst possible outcome. Intel normally doesn't shy away from just declaring standards and forcing them through against all odds, but when it comes to Verified Boot, suddently it's "up to each OEM".
Like with Intel Boot Guard, the proper solution is for SOF to provide Measured Boot (have the hardware send firmware properties to the TPM to seal secrets against). Once that exists, drop signature verification support. Have OEMs or whomever provide their we-don't-trust-our-users "secure" environment on top of the measurements (and remote attestation where needed).
That way, your end customers can decide not to trust the OEM (without being able to pretend that the system still satisfies the OEM's idea of trust), making it a mutual, equal relationship.
