说真的，Hardware Attestation这玩意当初说是为你好，防篡改、保安全，听着跟暖心小棉袄似的。可如今再看，这棉袄里缝的分明是手铐。可以可以你砸钱买的笔记本，想刷个Coreboot？想跑没签名的自由发行版？门儿没有。
无语
开源社区在这事上简直像撞南墙。OpenBMC想解放服务器固件，LibreBoot想还用户一个干净的启动链，结果呢？专有TPM和安全启动一挥手，全给拦在门外。服了更离谱的是，有些平台干脆把认证链写死，连你自己生成的密钥都不认——这哪是安全，分明是平台税改了个名头。
好家伙
行吧要是硬件的信任根永远攥在巨头手里，GPL再漂亮也只是空中楼阁。我们需要的是用户可掌控的开放验证，而不是大厂隔空发许可证。自由软件如果连主板都跑不上去，那还谈什么自由。

有没有老哥成功绕过这堵墙？来交流交流。

这个帖子让我想起去年在温哥华修一门嵌入式系统课时的经历。我们lab用的是某品牌ARM开发板，教授想让我们理解secure boot chain的底层逻辑，结果第一节课就卡住了——厂商把JTAG调试接口锁得死死的，理由是"防止供应链攻击"。literally，我们连自己写的裸机程序都烧不进去，最后只能在他们签过名的BL1上叠加自己的代码，像个俄罗斯套娃。

这其实触及了你说的核心矛盾：硬件认证的初衷和实际效果之间出现了严重的漂移。

从技术史角度看，TPM和Secure Boot的设计白皮书里确实有合理的威胁模型。2010年前后，bootkit攻击（比如Mebromi）确实能在OS加载前植入恶意代码，传统AV根本检测不到。TPM 1.2规范里提出的静态信任根（SRTM）方案，理论上让用户能验证启动链的完整性——这本身是neutral的技术，就像一把刀，可以切菜也可以伤人。严格来说

问题出在实现层。我读过Chromium OS开发者关于verified boot的设计文档，他们其实做了个有趣的折中：开发者模式允许用户加载自签名内核，但会通过物理指示（比如开机时的警告屏幕）告知"当前处于非验证状态"。这个方案在2013年的Chromebook Pixel上就实现了，说明技术上"用户可控的认证"是可行的。

但大部分消费级x86平台的固件实现走了另一条路。UEFI Secure Boot的默认配置里，Platform Key（PK）和Key Exchange Key（KEK）的控制权完全在OEM手里。更麻烦的是，Intel Boot Guard（从Haswell开始）把初始启动代码的哈希直接烧进芯片fuse，这个值一旦写入就无法更改。我查过Coreboot的邮件列表，2017年有开发者尝试在ThinkPad X230上绕过Boot Guard，结论是需要物理替换SPI flash芯片——这对普通用户来说门槛太高了。

你提到的"平台税"这个说法很精准。从经济学角度，这确实构成了某种形式的vendor lock-in。微软在2012年要求Windows 8认证机器必须默认开启Secure Boot，虽然他们后来澄清说x86平台必须允许用户关闭或管理密钥，但ARM平台的Windows RT设备直接禁止了这些操作。这个先例很糟糕，因为它证明了"安全"可以作为限制用户控制权的合法借口。
严格来说
不过我想补充一点：这个问题的解决方案可能不在技术层面，而在供应链治理。Raptor Computing Systems的Talos II工作站是个值得研究的案例。他们用的是POWER9处理器，完全开源固件，从bootloader到BMC都是用户可审计的。但代价是什么？一台基础配置的Talos II要$5,000+，而且生态支持极其有限。这说明开放硬件不是做不到，而是市场没有形成足够的需求压力。
严格来说
还有个角度值得商榷：我们讨论"自由软件跑上主板"时，需要区分两类场景。一类是开发者/爱好者需要完全控制硬件（比如你的用例）；另一类是普通用户需要reasonable assurance that their device hasn’t been tampered with。后者的需求是真实存在的——FBI在2019年报告过一起供应链攻击，攻击者在运输途中替换了某公司订购的路由器固件。对于这类威胁，硬件信任根确实是有效的防御手段。

严格来说所以问题不是"要不要认证"，而是"认证的控制权在谁手里"。技术上完全可能实现一种模型：用户在首次开机时通过物理存在（比如按住某个按键）将自己的公钥烧进fuse，之后所有固件更新都需要该私钥签名。这样既保证了安全链的完整性，又把控制权交还给硬件所有者。Purism的Librem系列笔记本就在尝试类似方案，虽然他们的实现目前还比较粗糙。

最后说个我最近在GitHub上看到的项目：Heads（基于Coreboot的开源固件），它用TPM做measured boot而非verified boot——也就是不阻止未签名代码运行，但会记录所有哈希值供用户事后审计。这个思路挺有意思，相当于把"认证"从门禁系统变成了监控摄像头。用户既能跑自编译内核，又能在怀疑被篡改时对比TPM中的PCR值。

温哥华这边有个本地黑客空间（Vancouver Hack Space），里面几个搞固件逆向的老哥经常讨论这些。上个月他们演示了在树莓派4上实现基于TrustZone的用户控制认证，虽然只是个原型，但至少证明了alternative path是存在的。关键还是看社区能不能持续施加压力，让OEM至少提供"高级用户选项"

我年轻的时候也遇到过类似的事。那会儿记得有一次去武汉东湖边的电子市场淘一块开发板，卖家说这板子“安全启动”做得特别好，连Linux内核都得签名才能跑。结果我一插线，发现烧写工具连个“烧写模式”都进不去——说是“为了防止用户刷入恶意固件”。我当时就想，这哪是保护用户，分明是把用户当韭菜。

你说的“俄罗斯套娃”那段，我特别有共鸣。我以前在实验室里也遇到过类似情况，老师让我们用某家ARM板做实验，结果发现JTAG接口被锁死了，连最基础的调试都做不了。最后只能在厂商提供的“签名固件”上加壳，像你描述的那样，一层套一层，像个俄罗斯套娃。这种体验真的很憋屈，明明是学习，结果却被厂商的“安全”给绑架了。

你提到的“用户可控的认证”方案，我觉得是个不错的折中。那会儿像Chromium OS那样，在开发者模式下允许用户加载自签名内核，虽然会有警告提示，但至少给了用户一个选择的权利。这种设计思路其实挺聪明的，既保证了基本的安全性，又给了用户一定的自由度。

不过，现实中的消费级平台往往更倾向于一刀切。他们觉得“安全”就是“不许动”，而不是“你可以动，但要小心”。这种思维模式，其实和当年的“防火墙”有点像——表面上是为了保护用户，实际上却限制了用户的探索和创新。

说到这里，我想到一个有趣的现象。现在很多厂商在宣传自己的“安全启动”时，都会强调“用户数据安全”和“防病毒”，但很少有人问他们：“如果用户想自己改固件，怎么办？我觉得吧”这种问题，往往会被他们绕过去，或者给出一个模棱两可的回答。
话不能这么说
我觉得，真正的安全，应该是让用户有选择的权利，而不是让用户只能在厂商划定的范围内活动。就像你提到的“硬件认证的初衷和实际效果之间出现了严重的漂移”，这种漂移，其实反映了厂商对“安全”的理解，很多时候是偏执的，甚至是短视的。

说到这里，我突然想到一个冷门预测：未来可能会出现一种“开源固件认证”机制，类似于“开源许可证”，但专门针对固件和硬件。这种机制，可能会让厂商在“安全”和“开放”之间找到一个平衡点。当然，这需要整个行业共同努力，而不是靠某个厂商单方面决定。
坦白讲
最后，我想说的是，技术的进步，往往伴随着用户的觉醒。就像你提到的“用户可控的认证”方案，其实已经走在了前面。我们这些用户，也应该保持警惕，不要被厂商的“安全”给忽悠了。毕竟，真正的安全，应该是让用户有选择的权利，而不是让用户只能在厂商划定的范围内活动。

俄罗斯套娃这个比喻绝了

我之前在工地用树莓派搭个监控，也是锁这锁那，最后刷了个社区固件才搞定~你说这玩意到底是防黑客还是防用户啊

以及你们lab教授当时脸绿了吗( ･ω･)

老兄，温哥华那段经历让我想起我年轻的时候——那时候还没现在这么老成，在一家创业公司折腾智能硬件，也是ARM板子，也是JTAG锁死，最后愣是靠一根飞线从UART旁路绕进去的。老板以为我是什么硬件天才，其实我就是穷，请不起原厂技术支持。那会儿

你说到Chromebook Pixel那个开发者模式，我倒是想起另一茬。2014年吧，我托人从香港带回来一台，就为了折腾那套verified boot。确实，按个组合键就能进开发者模式，屏幕变个橙色警告，挺人性化的。但你知道后来怎么着？我那台机器的TPM固件更新了一次，签名链里多了个我没见过的证书，查了半天，是Google自己加的中间CA。技术上完全合规，用户也"可控"，可那感觉就像你租了间房子，房东说钥匙给你，结果换了把打不开的锁。我觉得吧

你提到"用户可控的认证"技术上可行，这我认。但问题在于，可控的边界是谁画的？我那个创业公司后来接了个项目，给某品牌做ODM，甲方明确要求secure boot的密钥必须由他们托管。我们问能不能留个用户可替换的入口，对方法务直接甩过来一页保密协议，说可以，但替换后的设备保修自动作废，且"可能触发安全事件的法律追溯"。这谁还敢动？

我那个合伙人，就是后来赔进去三十万的那位，当时拍桌子说这不就是数字时代的地契吗？你买了房，墙里砌的是别人的钢筋。我当时还笑他阴谋论。现在想想，他看得比我透。

不过你说得对，技术本身是中性的。我到现在还留着那台Pixel，偶尔开机看看，橙色警告亮起来的时候，竟有点怀念那个还愿意给用户留一扇后窗的年代。现在？现在连后窗都改通风口了…，美其名曰"优化气流结构"。
嗯…
你那个俄罗斯套娃的比喻，我倒是想借来用用。套娃的问题不是一层包一层，是你永远不知道最里面那个是不是空的。我们当年在BL1上叠代码，叠着叠着发现原厂留了个调试后门没清干净，笑死，防供应链攻击防了个寂寞。这事我没敢跟甲方说，说了项目黄得更快。

所以啊，我现在的态度是，该用用，该骂骂，但别真把自己当主人。这房子从来就不是卖给你的，是长租。合同上写得清楚，只是字太小。你那门嵌入式课，教授让你们理解底层逻辑，结果先上了一课什么叫"此路不通"——这课其实更值钱，真的。我年轻的时候要是有人这么教，不至于后来栽那么大跟头。

怎么说呢对了，你那块ARM板子，最后套娃套出来没？我这边还有几根没烧完的飞线，寄你玩玩？

笑死，这不就是当年我在非洲修电脑时遇到的翻版嘛！6那时候给村里小学装系统，结果发现他们的主板都锁死了，连个U盘都插不进去。诶最后只能用老式软盘+BIOS跳线的方式，像个老古董一样折腾了半天。硬件认证这玩意儿，说到底还是得让用户自己说了算才行。

楼主这个比喻挺有意思，“棉袄里缝手铐”。从辨证的角度看，硬件认证这事的病机，倒不是技术本身有问题，而是证候已经转了。
嗯
Security by attestation的本意，有点像我们经方里讲的“治未病”——在boot chain每个环节设卡，防止邪气（恶意代码）从腠理入侵。这个思路本身是合理的。问题出在哪里呢？出在谁掌握辨证权。厂商标榜的“安全”，其实偷换了概念：他们把“平台完整性”和“厂商控制权”做了个合方，两味药混在一起开，患者（用户）就分不清哪味是治病的，哪味是添乱的。

我去年帮一个搞嵌入式的小伙子调身体，闲聊时他说在折腾RISC-V的板子，因为那个平台的信任根可以自建。这倒让我想到，硬件认证这个“证”，关键不在证本身，而在认证权的归属。经方治病讲究“观其脉证，知犯何逆，随证治之”，用户如果连脉都摸不到（看不到验证链），谈何随证治之？

至于绕过方案，楼上几位讲的俄罗斯套娃式叠加是个路子，但终究是治标。嗯根不在用户手里，迟早还得犯。