<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Am So., 11. Nov. 2018 um 00:43 Uhr schrieb Mike Banon <<a href="mailto:mikebdp2@gmail.com">mikebdp2@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But it is easier not to have any AMT/ME/PSP at all: no need to clean<br>
anything and nothing to worry about.<br></blockquote><div>At least not to your knowledge. For all we know, POWER9 (to pick the ISA where you can even edit the microcode) could have another processor in there that they "forgot" to tell you about. It just so happens to remove all protection levels when triggered by some sequence is found in the caches, eg. because it arrived over the network.</div><div>Unless there's progress on projects like the sadly defunct Home CMOS[0], there's some level of trust required that the hardware isn't nefarious.</div><div><br></div><div>So, is there really "nothing to worry about"?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Meanwhile you can't avoid the closed source Intel FSP the same way [as AtomBIOS].<br></blockquote><div>FSP is also just software, and with no signatures. There have been successful efforts to replicate the functionality of very similar binaries (see Sandybridge/Ivybridge).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In addition, there is YABEL option in coreboot to prevent the<br>
undocumented access of OptionROMs to other PCI devices - which also<br>
helps to reduce the concerns regarding this AtomBIOS blob. </blockquote><div>The AtomBIOS blob is parsed out by the OS, YABEL is long gone at that point.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm not sure there is any equivalent for FSP.<br></blockquote><div>It might be possible to run FSP inside YABEL or x86emu. Sounds like an interesting experiment.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But they could still be removed from coreboot just because of "EOL and<br>
old"/"no-one is using them". From coreboot 4.3 release notes: " 20<br>
mainboards were removed that aren't on the market for years (and even<br>
hard to get on Ebay) ". </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Stuff like this could happen to any board that is old, or am I wrong here?</blockquote><div>There were additional factors, but release notes normally aren't novels.</div><div><br></div><div>For the sake of completeness:</div><div>1. Not on the market for years</div><div>2. Not on the secondary market</div><div>3. No recent report (< 1 year old) on board-status at that point</div><div>4. No activity in related code that indicated that anybody would maintain it</div><div>5. Some of that code in question was getting in the way of modernization of coreboot's code base.</div><div><br></div><div>We could have kept the code around, but it would be all but guaranteed to be broken. We considered it better to send people using those boards to 4.2 which at least had a chance of still working on them.</div><div>And if they're serious about that hardware, they're more than welcome to step up as maintainers and bring the code back to master: The best way to avoid a board's deprecation is to maintain it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> The (AMD) platforms are not the problem. Maybe the problem is that their fans got lazy and rested on AGESA, idk.<br>But maybe we are busy using our coreboot'ed AMD computers for<br>
various freedom-related projects - as the tools to create something<br>
great? And having to rewrite AGESA would mean we're suddenly working<br>
much more on the tools than on the stuff we're creating with them -<br>
without any obvious benefit to the<br>
not-hardcore-programmers-but-security-conscious people who see that<br>
AGESA is open source already<br></blockquote><div>If there will be a time where keeping support for AGESA in becomes a real burden on coreboot development, and there is no maintainer for the boards based on it, expect to have to chip in the effort to keep support for those mainboards.<br></div><div><br></div><div>Nico's arguments are from the coreboot developer's and maintainer's point of view, while yours represent a certain set of users' - and both are valid.</div><div>However coreboot developers have no obligation to cater to the interest of any coreboot user (just like coreboot users are free to go elsewhere).</div><div><br></div><div>Excusing yourself from working on coreboot, including cleaning up the less savory parts, pointing out "various freedom-related projects" means that you won't have a voice in coreboot's future direction.<br></div><div>You're lucky though, the coreboot version that you're using on your AGESA based system won't go away. And if in the future there should be a reason to modify it, the source is also still there: just maybe not on the master branch.</div><div><br></div><div><br></div><div>Regards,</div><div>Patrick</div><div><br></div><div>[0] <a href="http://web.archive.org/web/20150424121156/http://homecmos.drawersteak.com/wiki/Main_Page">http://web.archive.org/web/20150424121156/http://homecmos.drawersteak.com/wiki/Main_Page</a></div></div>-- <br><div dir="ltr" class="gmail_signature">Google Germany GmbH, ABC-Str. 19, 20354 Hamburg<br>Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg<br>Geschäftsführer: Paul Manicle, Halimah DeLaine Prado</div></div></div>