+1 Me too, I strongly support the point of view of Mike. Freedom, be it in software or hardware is not negotiable!.. But on the other hand the point of view of Nico is also very legitimate. Having had to deal in my professional life with legacy code which was badly written and unmaintained (or unsupported) by the original issuer, I know what a nightmare can arise in this situation!.. So by force of circumstances, unfortunately, we can expect that the g505s (of other agesa based boards) will indeed be dropped from the coreboot master in the near future.. We (the owners of agesa based boards) need to prepare for this eventuality, and maybe if we want to keep coreboot alive (and evolving) on our platforms we should consider a fork... Please don't insult me for this for this reasoning (it is not even a proposal..), but we must face the reality.. One problem I notice is that almost all the experts in the coreboot comunity are focusing on Intel platforms nowadays (for professional reasons I suppose..). So when "the push come to shove", it will be hard for us newbs (yes Im an eternal newb in coreboot.. ;-)) to get advice and support in our maintaining efforts.. Anyway I think that it is stupid to get offensive and confrontational with the coreboot comunity even if it gets more and more Intel oriented..
My 2 satoshis, Florentin
----- Mail d'origine ----- De: kinky_nekoboi kinky_nekoboi@bluetardis.de À: coreboot@coreboot.org, Mike Banon mikebdp2@gmail.com, Nico Huber nico.h@gmx.de, coreboot coreboot@coreboot.org Envoyé: Sun, 11 Nov 2018 04:09:31 +0100 (CET) Objet: Re: [coreboot] Supported Motherboards
I strongly agree to what Mike said. thats maybe the "i want a cheap but yet powerfull and as Free as possible" point of view.
Also with the recent AMDGPU driver for linux. amd hardware is a good option to have a somewhat powerful and free graphics solution. And i am personaly much less worried about some vgabios or gpu microcode than an backdoor processor on my main cpu.
If i will hopeful get mad C-skillz and better unterstanding about lowlevel hardware processes in the future, i really would like to contribute to those amd 15th gen Ports of coreboot.
Am 11. November 2018 00:41:37 MEZ schrieb Mike Banon mikebdp2@gmail.com:
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).
- 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. 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. Meanwhile you can't avoid the closed source Intel FSP the same way.
In addition, there is YABEL option in coreboot to prevent the undocumented access of OptionROMs to other PCI devices - which also helps to reduce the concerns regarding this AtomBIOS blob. I'm not sure there is any equivalent for FSP.
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?
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
Best regards, Mike Banon
On Fri, Nov 9, 2018 at 9:27 PM Nico Huber nico.h@gmx.de wrote:
On 11/9/18 2:22 PM, Mike Banon wrote:
There might be neither ME nor PSP, but that just means the
controllers
that are known and researched are absent (it doesn't tell you
anything
about less researched ones).
There is no evidence that AMD processors contained any "remote management" controllers before late 16h family (Puma). Even the
early
16h (Jaguar) is okay in this relation, and G505S CPU is 15h
(Richland) -
so, unlike the recent Intels, it does not contain any "remote management" controllers that might be exploited as a hardware
backdoor> via some vulnerability.
There is no evidence that there is such a thing for Intel systems
with
AMT disabled, either.
AMD graphics driver developers force you to put a usually
proprietary
AtomBIOS into your firmware.
- You can move AtomBIOS from the firmware to GRUB/Linux kernel
stage.
Putting it into your firmware is more convenient - but it's not the
only
solution and could be avoided (e.g. by following some of these instructions - https://bugs.freedesktop.org/show_bug.cgi?id=26891 )
So you can shift the problem? Point is? I could secure it with a hyper-visor, I guess, but what if I just want to run Linux?
- 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! If not, I suppose you lie deliberately.
This list is about open-source firmware, if you want to make random claims about proprietary firmware, please do it somewhere else.
The G505s still uses AGESA (a hard to maintain AMD reference
code).
This (and actually the native coreboot AMD code too) might get
moved
away from our master branch after any release.
You are correct, it could be that one day coreboot will go full
Intel.
That's not what I said. Actually, there is actively maintained AMD
code
in our repo. I was talking about unmaintained code.
But that is more likely to happen simply because the corporations participating in the development of coreboot aren't interested at
any
AMD boards.
Nope, it's because the unmaintained code is no fun at all to work
with.
If I (as a non-corporate contributor) want to clean something up
across
the whole tree, there are sub-trees where I instantly see what I have to do, see how beautiful things turn out... there are also sub-trees that give me a bad time, delay a few hour job for days and as such lower the potential of non-corporate contributors. The code that runs on G505s lives in the latter sub-trees.
So the future coreboot indeed might support only some Google/Purism computers together with Intel/Facebook/etc. in-house proprietary boards, and there will not be any coreboot-supported
boards
without Intel ME + full complex set of their blobs (FSP etc.)
That's unlikely. The support for pre-ME/FSP Intel boards shows that maintaining 10y+ old platforms can be fun and works out very well.
The
(AMD) platforms are not the problem. Maybe the problem is that their fans got lazy and rested on AGESA, idk.
The last time I worked on a bigger patch set in my spare time, I
nearly
gave up after some nights of work because of the unmaintainable
mess
around {cpu,nb,sb}/amd/
If its difficult to write the crossplatform code in some cases or
if you
aren't interested at AMD boards (understandable if you don't have
any),
you could use something like "ifdef INTEL_BOARD then
Enable_Feature_X
else Dont_Enable". Better to live without some not-essential
features
than removing the boards, especially since there really aren't a
lot of
coreboot-supported motherboards.
That makes no sense at all. Either you want to have new features, up
to
date support etc., then we have to maintain it on the master branch.
If
we "ifdef" things out, it's the same as having it on a separate
branch.
I believe it's only a question of time until coreboot maintainers
are
finally fed up with it.
The majority of platform-specific problems discussed at the mailing lists are directly related to Intel. Sometimes I'm seeing so many
of
them flooding my inbox, I'm wondering how the coreboot maintainers aren't fed up with Intel mess.
Your statistics are biased by the fact that almost nobody uses
coreboot
for AMD (in production) compared to Intel. But to be honest, Intel
does
a mess indeed, but it's not half as bad as the unmaintained (even the native) AMD code.
Here are some long thread examples:
*) "How to get correct memory params for FSP" *) "[skylake] Can not
turn
monitor on" *) "Kabylake unable to boot with post code 0x71" +
could dig
out much more if required.
Even from a bystander's point of view it is quite obvious that many
of
these Intel-specific problems have been caused by the improper
software
design and insufficient source code quality. Luckily you seem to recognize these problems, as I could see from some of your messages
like
this one -
https://mail.coreboot.org/pipermail/coreboot/2018-November/087722.html .
Whether this has been caused by Intel outsourcing to developing countries, or "quantity-over-quality" approach, I don't know.
However:
despite the Intel source code being as messy as AMD (if not more
messy)
you don't see any serious discussions regarding the removal/rewrite
of
Intel, and we all know why.
Nope, as said above, the unmaintained AMD is a hell a lot messier.
A good solution would be to write native coreboot code for this platform from scratch. Something at least of the quality of
intel/x4x
(and the compatible southbridges) would be much appreciated and
would
likely maintain itself for some years.
But that will not protect AMD code from removal. When someone will
want
to remove it, in any case they will find a reason: either "EOL and
old"
(could happen to intel/x4x regardless of its' source code quality)
or
"no feature/property X we've introduced and absolutely require" (something like "late vs early init") or simply "why should we care about AMD boards if we work with/at Intel". Maybe then the coreboot project will be forked and there will be two coreboots: one for the people, and another for corporations.
Well, I'm with the people. And if I would fork coreboot for the
people,
the unmaintained AMD code would be high up on the list of what to
drop
to be able to support the rest better. You seem to be absolutely con- fused about coreboot development. There are a lot active
non-corporate
developers in the community. You are asking them to maintain the
crappy
code too, for less fun and no money. How should that ever work out?
Sorry, but it seemed more like "Please avoid AMD if possible, its'
going
to be removed". Problem that its hard to avoid AMD without going
Intel,
and there are a lot more reasons to avoid Intel than AMD: in
addition to
the earlier introduction of remote management controllers and being
a
monopoly, there are serious Intel-only security vulnerabilities
like
Meltdown which requires a 5%-30% performance degrading patch and
Intel
hyperthreading will be disabled soon (
https://www.theregister.co.uk/2018/11/02/portsmash_intel_security_attack/).
Perhaps it makes more sense to say
" Please avoid Intel if possible "
but I don't want to start "Intel vs AMD" holy war there, especially since it seems we are greatly outnumbered by Intel-employed/partnered/sympathetic folks (how could one be
sincerely
sympathetic to Intel is a big question though).
Yeah, it's weird. I'm absolutely not on the Intel side. I just can't stand your biased bullshit. So I'm looking for arguments against AMD when I see your unfounded arguments against Intel. Not because I
don't
like AMD but because I don't like this list to look dubious, i.e.
that
we would accept biased arguments without correcting them.
Nico
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot