coreboot June 2018

coreboot@coreboot.org

40 participants
105 discussions

Re: [coreboot] [RFH] Native AMD fam10-15 support
by Taiidan＠gmx.com 14 Jun '18

14 Jun '18

On 06/13/2018 04:12 PM, Kyösti Mälkki wrote: > Hi > > Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards. What exactly do you mean by wiped out? > > Couple questions for board owners: > > First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3 > support? I remember rumours they originally worked at some point, but > regressed during the rebase / upstream process. Anyone willing to > bisect/fix it if necessary? > I have a D16 with v4.6 that I regularly use suspend with and it works absolutely fine - I can also suspend a host featuring a guest with IOMMU graphics and then resume that host later on and continue playing video games on the guest. > I am asking, because these are the last two remaining boards with > combination of HAVE_ACPI_RESUME=y and RELOCATABLE_RAMSTAGE=n, and we > have to drag along some back-and-forth memory copy code to keep OS > memory intact for these two. > > Second, I would like to move forwards with AMD fam10 to have > RELOCATABE_RAMSTAGE=y, that would also solve above-mentioned issue and > open up doors for some new features. > > If it was my decision, RELOCATABLE_RAMSTAGE for x86 would be one > criteria to survive the next (October 2018?) release. POSTCAR_STAGE > for May 2019. I am probably too late to make such wishes, but I hope > these will happen in the next two years nevertheless. I again state my for-some-reason controversial opinion that at this rate there will soon be no non-development boards in coreboot due to the choices of the current leadership in determining standards. Removing something from master is in fact removal from coreboot - one of the reasons is as over time the older versions of software required to compile older versions of coreboot will become un-obtainable already to compile master critical old GPL code is only obtainable from one obscure non-US site.

2 1

[RFH] Native AMD fam10-15 support
by Kyösti Mälkki 13 Jun '18

13 Jun '18

Hi Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards. Couple questions for board owners: First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3 support? I remember rumours they originally worked at some point, but regressed during the rebase / upstream process. Anyone willing to bisect/fix it if necessary? I am asking, because these are the last two remaining boards with combination of HAVE_ACPI_RESUME=y and RELOCATABLE_RAMSTAGE=n, and we have to drag along some back-and-forth memory copy code to keep OS memory intact for these two. Second, I would like to move forwards with AMD fam10 to have RELOCATABE_RAMSTAGE=y, that would also solve above-mentioned issue and open up doors for some new features. If it was my decision, RELOCATABLE_RAMSTAGE for x86 would be one criteria to survive the next (October 2018?) release. POSTCAR_STAGE for May 2019. I am probably too late to make such wishes, but I hope these will happen in the next two years nevertheless. Kyösti

1 0

Re: [coreboot] proposal: coreboot docs in separate repo
by Leah Rowe 13 Jun '18

13 Jun '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 13/06/18 01:07, ron minnich wrote: > On Tue, Jun 12, 2018 at 4:56 PM Leah Rowe <info(a)gluglug.org.uk> > wrote: > >> >> >> Wait a few years when more pages are added to the docs. Add >> images. The repo will start becoming gigabytes in size. >> >> > > will do. We'll wait a few years :-) Very well. I was just giving you a warning. Because this has happened with libreboot.git. I'm strongly considering splitting the repo into several smaller repos, with docs separated. I just thought I'd give you a heads up, several years in advance. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlsgx5IACgkQ/0W3TPnR z5T0sQf/dX9SqOyqVUHznoQpruR2pAdl4GJR3cDM4sXF2nzdHRvvr+Xfc7BDcNG9 ZjcRQAmdjxtq3lGKrFhfk0DwZ+SIDXOWPqC4EoQbo8kIAcesqW2NR/mix7wDA6y4 Ar/aMf63+KnMgYnGP3gtM6Xzu9P+nMvhRxF0+rUyAWGfSGL2dEXK93/GzY2LhXhv s6KCyJpetRToQZFuirjbTUio10PRdZ3L02FS0gHMDU8CBvnahOf/Gs/wVf14HX0k qyL9HA8nCSksIt1/0ZDwWxfgT09n1s4X4C5vrOWUitUs2wU9mzilKZaNgNO1aFGw /dH/6ke72mAQA+xOpegsSsEVKGNYzw== =WIYm -----END PGP SIGNATURE-----

1 0

Re: [coreboot] proposal: coreboot docs in separate repo
by Leah Rowe 13 Jun '18

13 Jun '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/06/18 23:23, ron minnich wrote: > On Tue, Jun 12, 2018 at 3:17 PM Leah Rowe <info(a)gluglug.org.uk> > wrote: > >> >> >> That's going to weigh down the repository and make it huge, over >> the years. It means that adding images etc is going to be a pain >> too. >> > > Let's get a number here. > > Define 'huge'. I just did a quick check and that directory is a > tiny fraction of the repo size. > > So, again, let's get a number, consider that the number was reached > over 19 years, and have a discussion based on that number. I'm > unable to see a problem. > > ron Wait a few years when more pages are added to the docs. Add images. The repo will start becoming gigabytes in size. - -- Leah Rowe Please help me fund my Gender Reassignment Surgery! https://vimuser.org/surgery/ Libreboot developer and project founder. Use free software. Free as in freedom. https://www.gnu.org/philosophy/free-sw.html Use a free BIOS - https://libreboot.org/ Use a free operating system, GNU+Linux. Support computer user freedom https://sfconservancy.org/ https://fsf.org/ - https://gnu.org/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: https://minifree.org/ -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlsgXbcACgkQ/0W3TPnR z5T44gf/QwlO/5/UT2Y0k6R8WhtFXvyVyT/zMvNijf5E+eO6NrBDxxrDwZ7Oa2S6 hZhj7w3EFAuCc3ayZonUnvqICebLQqJOPJ50OjazBGyya33ooJTiYM9geq/PUnLV POTvScXnrc+b7HjQ9yKjEMyQf/c6AFcSBHmjDIq8O4Gq7f2JDmCKfUSrdtwgvR5t TxSHz8bp0WnXTMqHZk5DRrvXmVh3xYq78MGlY6kK/LSGpeKE0mm3k8COwkrmxYPX exwyfJP8WyGEdQXx6l/T47PCNN3fLP0jWO+huXOeXipHOAygij6oLCDg7MtnEkJ0 DQY9xfYwLFDzz4OyG0sQD4ceNxYebA== =3scW -----END PGP SIGNATURE-----

2 1

proposal: coreboot docs in separate repo
by Leah Rowe 13 Jun '18

13 Jun '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 So... Why is the coreboot documentation in the main git repository? That's going to weigh down the repository and make it huge, over the years. It means that adding images etc is going to be a pain too. What do people think about having the docs as a separate repository? This way people who want to work on code but not docs don't have to download docs. And images using some kind of hosting site (by coreboot) e.g. images.coreboot.org (since putting images in a git repository isn't really a good idea) -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlsgRkEACgkQ/0W3TPnR z5Sazwf9GTJyl7CUTMbbVW1lBw1tu3edltQ0CSN7VOD6T8ZGnuV+e0/iHcCNv9ZL DfUCDN9K9g6xrTJOYAu+beTIT4hohXHFipoLloKkbFioDb2urdpo44wtQtIzwNdk Nmjt8hJYfX8IV9G0zGzWQdbLHVq3DhMZ6qFV5MoZ5qkG4P3JkvXQzJDoPm0sgcst 7rSIieOefpAB6MEdkOcf587aj61x/xBAmtZw/CemsNRrYKUZVQPYbilrfceIkgMw jNqiIEMn5p9HC5pQ/cOIe5oJmo/pcYS+8K2kcw1Lp11Tb+duJODlpbu2Nx9M6HqV tD5yoJ/bkGeXhhrkpzwEInNmaWnCfg== =NF2n -----END PGP SIGNATURE-----

2 1

static site generator for coreboot documentation in git repository
by Leah Rowe 13 Jun '18

13 Jun '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I recently heard of the plan to retire the wiki. Personally, I think that's a great idea. Move it all into coreboot.git instead. I notice that Documentation/ has .md files in it in coreboot.git. So I wonder, is there a static site generator in coreboot.git for generating the documentation into a website? If not, is one being developed? That would make the documentation accessible to the public via web browser. The Libreboot documentation has done this for quite a while now. The whole website and documentation on the site is actually in libreboot.git as Markdown files. We have a static site generator in the repository (written by us) which uses Pandoc to convert Markdown files into html files, which generates the site. If this isn't yet implemented or being worked on in coreboot, I'd be happy to work on it. - -- Leah Rowe Please help me fund my Gender Reassignment Surgery! https://vimuser.org/surgery/ Libreboot developer and project founder. Use free software. Free as in freedom. https://www.gnu.org/philosophy/free-sw.html Use a free BIOS - https://libreboot.org/ Use a free operating system, GNU+Linux. Support computer user freedom https://sfconservancy.org/ https://fsf.org/ - https://gnu.org/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: https://minifree.org/ -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlsgRA0ACgkQ/0W3TPnR z5QIBQf+KivoquipSz+0hhFYOO9VSFPUDbmCCo/zqZ4J2y/8t9UKZes9BMJdCzlt reQm0sB9dThuvtANtXtLHZWYIp4Rx6m7+mLWRjoB1dbZPOMCC86U/TZ60xZfgdNo EdY0Y59LnPNHiNNq4/9VT986cg/ggsaSPOvhXLbkCAV7e8C/Yuso5e8lqaGvc6PM rzLPx+wkx26nUKbMx/YETbpI70cpf37FitIALECnYwIzCEO/0It09qw97abbbX08 OVIQLIydrHh+VXvAiIPK2RBbV0jIqt2opRpTRaf+7oLRROnBOrOaLkoVbxsqAiSR OWapHRsA8GG4JPUuuqKcpZPhueAk+Q== =CBCQ -----END PGP SIGNATURE-----

1 1

Re: [coreboot] wiki backup
by Leah Rowe 12 Jun '18

12 Jun '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/06/18 19:48, Patrick Georgi wrote: > Leah Rowe <info(a)gluglug.org.uk> schrieb am Di., 12. Juni 2018, > 20:16: > >> Now that the wiki is being retired, is there a backup of the >> wiki (database, files etc) so that someone else can host it >> elsewhere? For archival purposes. >> > > Various formats are available at https://www.coreboot.org/wikidump > Is this updated regularly? (the fact that the wiki is RO means this is probably a stupid question, but I ask it nonetheless in case I need to update my backups regularly) -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlsgQZIACgkQ/0W3TPnR z5Q8aAf+PMPj1cifQTRlwv8BZxNyK3gSVTSBzPlupQKhqaGoXbB5Cl66KJkX1YV+ jJmLAIryy55KiftKd2gHxp5NVTNPHH2HpTARFgukG4KpP+AaRplmHqPkqmRv7pe8 4UWfB/fNttKgGCgkh+9ke5v/5IhO5HwjiMf0yQ9VkVIUC7RhzSI9tCaUw8igfW6o 6FyRWyVzN/WrYtwBDf743BDhHyMmu8uEJHo99OlIZX+1Jg84dX+p8JgJ5LLB/ntK Fj7loCMTCd3oRKUN/93j7/Ch8ESbvOaQYvvMzsJgKpTJevAPE4Ut0AHNoCovNWJR g+9XZyA6wurLQKAZjb4Phktk+PRH8g== =XBeY -----END PGP SIGNATURE-----

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 12 Jun '18

12 Jun '18

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1393341: Control flow issues (DEADCODE) /3rdparty/arm-trusted-firmware/lib/extensions/amu/aarch64/amu.c: 173 in amu_context_restore() ________________________________________________________________________________________________________ *** CID 1393341: Control flow issues (DEADCODE) /3rdparty/arm-trusted-firmware/lib/extensions/amu/aarch64/amu.c: 173 in amu_context_restore() 167 for (i = 0; i < AMU_GROUP0_NR_COUNTERS; i++) 168 if (AMU_GROUP0_COUNTERS_MASK & (1U << i)) 169 amu_group0_cnt_write(i, ctx->group0_cnts[i]); 170 171 /* Restore group 1 counters */ 172 for (i = 0; i < AMU_GROUP1_NR_COUNTERS; i++) >>> CID 1393341: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "if (0U & (1U << i)) amu_g...". 173 if (AMU_GROUP1_COUNTERS_MASK & (1U << i)) 174 amu_group1_cnt_write(i, ctx->group1_cnts[i]); 175 isb(); 176 177 /* Restore group 0/1 counter configuration */ 178 write_amcntenset0_el0(AMU_GROUP0_COUNTERS_MASK); ** CID 1393340: Control flow issues (DEADCODE) /3rdparty/arm-trusted-firmware/lib/extensions/amu/aarch64/amu.c: 147 in amu_context_save() ________________________________________________________________________________________________________ *** CID 1393340: Control flow issues (DEADCODE) /3rdparty/arm-trusted-firmware/lib/extensions/amu/aarch64/amu.c: 147 in amu_context_save() 141 /* Save group 0 counters */ 142 for (i = 0; i < AMU_GROUP0_NR_COUNTERS; i++) 143 ctx->group0_cnts[i] = amu_group0_cnt_read(i); 144 145 /* Save group 1 counters */ 146 for (i = 0; i < AMU_GROUP1_NR_COUNTERS; i++) >>> CID 1393340: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "ctx->group1_cnts[i] = amu_g...". 147 ctx->group1_cnts[i] = amu_group1_cnt_read(i); 148 149 return 0; 150 } 151 152 static void *amu_context_restore(const void *arg) ** CID 1393339: Integer handling issues (NO_EFFECT) /3rdparty/arm-trusted-firmware/lib/extensions/amu/aarch64/amu.c: 130 in amu_context_save() ________________________________________________________________________________________________________ *** CID 1393339: Integer handling issues (NO_EFFECT) /3rdparty/arm-trusted-firmware/lib/extensions/amu/aarch64/amu.c: 130 in amu_context_save() 124 return (void *)-1; 125 126 /* Assert that group 0/1 counter configuration is what we expect */ 127 assert(read_amcntenset0_el0() == AMU_GROUP0_COUNTERS_MASK && 128 read_amcntenset1_el0() == AMU_GROUP1_COUNTERS_MASK); 129 >>> CID 1393339: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "0UL <= 0UL". 130 assert((sizeof(int) * 8) - __builtin_clz(AMU_GROUP1_COUNTERS_MASK) 131 <= AMU_GROUP1_NR_COUNTERS); 132 133 /* 134 * Disable group 0/1 counters to avoid other observers like SCP sampling 135 * counter values from the future via the memory mapped view. ** CID 1393338: Integer handling issues (NO_EFFECT) /3rdparty/arm-trusted-firmware/lib/extensions/amu/aarch64/amu.c: 163 in amu_context_restore() ________________________________________________________________________________________________________ *** CID 1393338: Integer handling issues (NO_EFFECT) /3rdparty/arm-trusted-firmware/lib/extensions/amu/aarch64/amu.c: 163 in amu_context_restore() 157 if (!amu_supported()) 158 return (void *)-1; 159 160 /* Counters were disabled in `amu_context_save()` */ 161 assert(read_amcntenset0_el0() == 0 && read_amcntenset1_el0() == 0); 162 >>> CID 1393338: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "0UL <= 0UL". 163 assert((sizeof(int) * 8) - __builtin_clz(AMU_GROUP1_COUNTERS_MASK) 164 <= AMU_GROUP1_NR_COUNTERS); 165 166 /* Restore group 0 counters */ 167 for (i = 0; i < AMU_GROUP0_NR_COUNTERS; i++) 168 if (AMU_GROUP0_COUNTERS_MASK & (1U << i)) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] Building coreboot for Apollo Lake: missing 'IFWI' region
by Nico Huber 10 Jun '18

10 Jun '18

Hello Hal, On 28.05.2018 08:06, Hal Martin wrote: > Name Offset Type Size Comp > ... > cpu_microcode_blob.bin 0x6f00 microcode 0 none The size looks troubling, I think you really need the correct microcode binary to get into coreboot. Make 100% sure it matches your SKU. > Is it expected that ifwitool will not work on the coreboot generated image? > Or does this indicate I've made a mistake somewhere? I'm not sure. I'd extract the bios/ifwi region using ifdtool and try to run ifwitool on that. Nico

2 1

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?
by Matt B 09 Jun '18

09 Jun '18

Hi, My deepest apologies if this doesn't show up in the right spot, despite editing the subject. I'm a dummy and I'm switching off digest mode right now. I'm no expert on microcode but I'll share my personal stance which I think is pretty reasonable and practical. As the saying goes, the best way to ask a question on the Internet is to give the wrong answer. :) For some context, see: https://lwn.net/Articles/744818/ My understanding of microcode, both from what I've read and what I've studied is that it is or is more analogous to the contents of one or more state tables, for state machinery in the CPU, and most useful for handling complicated functionality (like a multi-word copy). (the actual details are probably a hugely proprietary secret) I seems to me that most people hear the 'code' part of 'microcode' and assume it's a huge compiled binary blob running on a general-purpose processor, and can do just about anything and attacker could possibly want. I wrote this sentence, then then realized that everyone knows that's what the IME is for. ;D Do I expect you could introduce a very subtle security vulnerability with it? Absolutely. The spectre microcode patches effectively do the reverse of that. Do I worry about that too much? Not really. My reasoning is that it would be equivalent to introducing it in the in-silicon architecture of the CPU, and that's already something we *assume* Intel/AMD/ect don't (or shouldn't, for practical/legal/moral reasons) do. We can talk about silicon poisoning later over (preferably alcoholic) beverages. Do I think that this has any bearing on whether you should install microcode patches? Not really, no. Microcode patches are (typically) created to fix some specific errata. You could make some argument that they also provide the opportunity introduce/remove some vulnerability, since they can't really be inspected that well (or at all), but I refer you to #2. Since they typically exist to fix some (sometimes serious) errata I install them as a matter of "best security practice" like I do for innumerable software updates. Note that all of the above is purely from a practical stability/security perspective. Proprietary IP (code and otherwise) permeating everything we use at a deep level is also a huge moral issue (or so I am repeatedly told :D), it's just that I tend to focus on the practical aspects/implications. That said, even if you have stronger free-software moral fortitude than me [1], I can't fathom why you wouldn't install a microcode patch. You're free to abstain, but I would *mostly* equate running a CPU with unpatched microcode with running one that's patched. I say mostly, because I consider the patching to be small potatoes, especially compared with, say, not infecting your friends with a virus that exploits a significant errata. (I won't say more on this though, since I've probably already just ensured a "lively" ethics debate. I just want the option to load the damn things.) Don't get me wrong, for both moral and practical reasons I would love more than anything to be using a 100% open computer. But I would have to not ignore hardware in that, especially if we count microcode. I don't think we can expect Intel/AMD/ect to release the complete design of *any* CPU since at least the Z80, and that still may not do anyone any good if they're the only ones making them. I think the best we can look forward to on that front right now right now is RISC-V hitting silicon from a variety of manufacturers. I recently saw their dev board running youtube videos, so that looks promising. [1] I will, on occasion, use N-F software *Gasp!* that's convenient *Gasp!* and from sources I sufficiently trust in contexts where that trust is sufficient. Sincerely, -Matt On Thu, May 24, 2018 at 6:00 AM, <coreboot-request(a)coreboot.org> wrote: > Message: 8 > Date: Wed, 23 May 2018 22:37:47 +0100 > From: Andrew Luke Nesbit <ullbeking(a)andrewnesbit.org> > To: coreboot(a)coreboot.org > Subject: Re: [coreboot] When does AMD release the fam15 spectre > microcode updates? > Message-ID: <f840a373-0169-ec59-11f6-4f5d25219784(a)andrewnesbit.org> > Content-Type: text/plain; charset=utf-8 > > On 23/05/2018 20:55, ron minnich wrote: > > > > > > On Wed, May 23, 2018 at 12:54 PM Rudolf Marek <r.marek(a)assembler.cz > > <mailto:r.marek@assembler.cz>> wrote: > > > > Hi all, > > > > Dne 22.5.2018 v 07:03 Taiidan(a)gmx.com <mailto:Taiidan@gmx.com> > > napsal(a): > > > > > > > don't they have those in this update? Would it be possible to > > easily add > > > the support flags without microcode for those who use libreboot? > > > > So libreboot guys don't want any fixes for a CPU? > > > > > > I've been wondering about this. IIRC the original motivation for the > > libreboot fork was microcode.? > > Is microcode still out of bounds for libreboot? > > I don't know if the original motivation still applies. This is an > important discussion to have. > > I've pinged the folks in #libreboot and #vikings on Freenode to alert > them to this discussion. There are probably other relevant channels > I've missed. > > Hopefully somebody with a wider and deeper understanding of the issue > than I have is reading this list. Hopefully they will chime in and > provide a more authoritative answer. If not I will keep pestering them > because I don't want to see this unresolved, but I would like to help > out however I can and learn whatever is needed to make a positive > contribution. > > Andrew > -- > OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2018