On 11/11/18 12:41 AM, Mike Banon wrote:
There is no evidence that there is such a thing for Intel systems with AMT disabled, either.
But it is easier not to have any AMT/ME/PSP at all: no need to clean anything and nothing to worry about.
I could secure it with a hyper-visor, I guess, but what if I just want to run Linux?
Possible to run Linux under a hypervisor as well, by using something like QubesOS (which contains Xen).
When I said `just want to run Linux` I meant exactly the opposite of what you propose: just/only Linux. Doesn't matter.
- AtomDis of AtomBIOS is clear enough to make sure there aren't any
backdoors ( https://pastebin.com/xKW9FV58 ),
You have made (up?) that claim before. If it is clear to you and you have the knowledge to implement a free graphics driver for the G505s, please do it
I could be a car mechanic without being able to build a new car from scratch. When I looked under this car's hood (AtomDis) I saw just a bunch of command tables like SetMemoryClock / AdjustDisplayPll / EnableVGA_Render and data tables like LVDS_Info / VRAM_UsageByFirmware. Haven't seen anything suspicious that could have indicated some potential backdoors there.
Well, I wouldn't expect AtomDis to output something like EvilFunction. What would you expect is suspicious? For me, VRAM_UsageByFirmware is definitely something I'd look into before I could tell. VRAM in the integrated graphics case, might be your system RAM. Maybe this could be used to give accidental access to some RAM that isn't supposed to be used as VRAM?
But if you don't want to run this blob even under a hypervisor like Xen in QubesOS, there's always an option to avoid this blob entirely by running your PC in a headless mode.
We were talking about the G505s, right?
Meanwhile you can't avoid the closed source Intel FSP the same way.
There's no board in coreboot that uses FSP and would compare to the G505s.
The support for pre-ME/FSP Intel boards shows that maintaining 10y+ old platforms can be fun and works out very well.
But they could still be removed from coreboot just because of "EOL and old"/"no-one is using them". From coreboot 4.3 release notes: " 20 mainboards were removed that aren't on the market for years (and even hard to get on Ebay) ". Stuff like this could happen to any board that is old, or am I wrong here?
I don't think so. Maybe nobody even asked to keep these boards.
The (AMD) platforms are not the problem. Maybe the problem is that their fans got lazy and rested on AGESA, idk.
Its understandable that it could look like we are lazy and resting on AGESA. But maybe we are busy using our coreboot'ed AMD computers for various freedom-related projects - as the tools to create something great? And having to rewrite AGESA would mean we're suddenly working much more on the tools than on the stuff we're creating with them - without any obvious benefit to the not-hardcore-programmers-but-security-conscious people who see that AGESA is open source already
I'm not sure what to say. Do you imply that open source makes anything more secure? There are some benefits in open-source development that seem to result in rather secure code. For instance, reviewing processes, that you get more people look at the code etc. But I don't see that for AGESA (maybe because I didn't try to read it). I don't know if it has ever been audited with security in mind or even reviewed. Most of the AGESA related work in coreboot is about wrapping it, so nobody has to look into it. For me, using open-source AGESA is no more secure than using FSP (until I read its code).
That's also why I never ask silicon vendors for code but for documen- tation instead. If the code isn't written/reviewed/maintained by an open-source community, what's the point of open source? (I know I know, freedom to adapt it, but that doesn't make it secure per se.)
Nico