You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FSP switches to POSTBOOT_SAI, there are several issues with that. TL;DR while it probably tries to achieve the opposite, it undermines firmware quality and security.
In some bootloaders FSP may run long before EOP, this means most of the bootloader runs with POSTBOOT_SAI.
In the EDS, implications of the SAI switch are not documented. Virtually for every register, it is unknown if it is still accessible after the SAI switch.
The SAI switch seems to force the bootloader to do some things in SMM. AFAIK, the use of SMM as a more privileged execution mode is generally discouraged, even internally at Intel. This means FSP forces bootloader development to go backwards.
Generally, security may be undermined if FSP locks something to early, i.e. in a state that doesn't play well with the security concept of the bootloader.
Especially the lack of documentation leads to many bugs in firmware. Even Intel developers working on bootloaders such as coreboot don't seem to know the implications of the SAI switch or lack the resources to re-evaluate all bootloader code wrt. the SAI switch. I fear there is currently a race to the bottom of firmware quality going on: the need to fix bugs eats too many resources which leads to more bugs for future products, eating even more resources. Plus, these resources are limited because of the lack of public documentation.
Two possible solutions come to mind:
Do the SAI switch in the very last phase of FSP (or maybe even add an additional phase to lock things down?) and comprehensively document all the implications of the switch. For instance, in all the register tables, there could be column that mentions the applicable SAIs.
Make the SAI switch optional in FSP and document how the boot loader can take care of it. This would not only prevent all SAI-switch related bugs but also leave the security concept in a single place, the bootloader. That the configuration of security mechanisms and their locking are currently split between bootloader and FSP makes it very hard to configure an Intel platform reasonably secure (unless you rely on additional security chips in your platform, which is not always affordable).
I think 1. is only feasible in the long run. But maybe it's not too late to set up 2. for all the FSPs that do the SAI switch yet?
The text was updated successfully, but these errors were encountered:
POSTBOOT_SAI isn't documented. Please open your documentation and explain what it does.
How should firmware developers use FSP in a secure manner if the interface/UPDs are unknown?
FSP switches to POSTBOOT_SAI, there are several issues with that. TL;DR while it probably tries to achieve the opposite, it undermines firmware quality and security.
Especially the lack of documentation leads to many bugs in firmware. Even Intel developers working on bootloaders such as coreboot don't seem to know the implications of the SAI switch or lack the resources to re-evaluate all bootloader code wrt. the SAI switch. I fear there is currently a race to the bottom of firmware quality going on: the need to fix bugs eats too many resources which leads to more bugs for future products, eating even more resources. Plus, these resources are limited because of the lack of public documentation.
Two possible solutions come to mind:
I think 1. is only feasible in the long run. But maybe it's not too late to set up 2. for all the FSPs that do the SAI switch yet?
The text was updated successfully, but these errors were encountered: