FSP switches SAI
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 20/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- c
- 领域
- embedded-iot, security
调研方向
首先定位 FSP 将 SAI 更改为 POSTBOOT_SAI 的位置，并将该行为与 EDS 寄存器表进行比较；未指定具体的源文件或测试。完成这项工作需要就更改或记录 SAI 切换的范围达成一致，并验证其对 bootloader 访问和安全性的影响。
由索引模型根据 Issue 内容生成。
描述
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?
- 主要语言
- C
- 星标
- 366
- 派生
- 143
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
intel/FSP 的其他 Issue
-
ArrowLakeS FSP: TmeEnable = 1 leaves TME inactive on Core Ultra 9 285K (single-key TME, no TME-MK)未关闭
难度 5/5 一周以上 新手友好度 24/100
-
难度 4/5 3-5 天 新手友好度 42/100
-
难度 4/5 3-5 天 新手友好度 42/100
-
难度 3/5 1-2 天 新手友好度 68/100
-
难度 5/5 一周以上 新手友好度 35/100
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复
-
SPIDevice selects an active-high device as soon as it is created可能已有人在做 @mikeysklar 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 73/100
adafruit/circuitpython#11869 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 78/100
gnif/LookingGlass#1352 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 72/100
kovidgoyal/kitty#10862 ·
维护者通常 1 天内回复