[coreboot] Supported Motherboards

[Nico Huber]

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.

>>> 2) 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