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 <[email protected]>: >> 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). > >> > >> > 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. 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 <[email protected]> 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. >> > >> > 1) 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? >> >> > >> > 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! 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: [email protected] >https://mail.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
