[coreboot] Documentation change needs review
Hi, I'm looking for a reviewer for a small documentation update: https://review.coreboot.org/c/coreboot/+/32540 Alan ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Votes on copyright lines, line lengths and automatic formatting
> On Tue, May 14, 2019 at 12:49:17PM -0700, Julius Werner wrote: > > One thing I'm missing is an option to maintain clang-format as an > > optional pre-submit hook that people can choose run over only the > > lines their patch is touching if they want to, like I suggested in > > that thread above. > Since everybody is free to do that without project coordination, we > don't need to ask for that to be project policy, no? Well, we could still maintain a default .clang-format file and prepare a ready-to-install commit hook so that people don't have to figure out the details of clang-format-diff theirselves. I think it presents a valid third way of "how do we want to deal with auto-formatting". > I don't think there's anything bad enough to warrant calling off the > current round though, which would only create additional confusion. Yes, I didn't want to suggest that. I guess people who agree that formatting should be optional can vote against it here and then we could discuss details later if the option wins. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Votes on copyright lines, line lengths and automatic formatting
On Tue, May 14, 2019 at 12:49:17PM -0700, Julius Werner wrote: > One thing I'm missing is an option to maintain clang-format as an > optional pre-submit hook that people can choose run over only the > lines their patch is touching if they want to, like I suggested in > that thread above. Since everybody is free to do that without project coordination, we don't need to ask for that to be project policy, no? > Maybe next time we can post the draft questions and give people a > chance to comment first. I think there was a mishap in that Martin posted the draft questions in last week's leadership meeting and was meaning to publish the minutes. So these questions were reviewed, not just the result of a spur of the moment, but I admit that things could have gone a bit better. I don't think there's anything bad enough to warrant calling off the current round though, which would only create additional confusion. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado signature.asc Description: PGP signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gpg keys for coreboot distribution
On Tue, May 14, 2019 at 03:50:18PM -0400, Chris Laprise wrote: > When I look at review.coreboot.org and the patches have logged commits > (ostensibly, these are at least hashed) and I see "Patrick Georgi" as > reviewer... there is no assurance of fidelity from those records? So what is it you're missing that you require signatures for patches? FWIW Gerrit (the software driving review.coreboot.org) supported signed pushes, but I don't think many people are aware of that or use the feature. It's also of somewhat limited use as Gerrit cherry-picks into master which loses the signature again. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado signature.asc Description: PGP signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Lenovo G505S : USB issues at Qubes OS
Mike Banon: It's strange that you got a variable degree of this USB issue at different laptops, it should've been the same regardless of your dGPU type. Seems to be a Qubes-only problem, a bit random, and might be possible to fix if you'd read a note here - http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#TODO_list . Here's a copy-paste : " 2) Both XHCI options in Coreboot menu should be disabled (unless you'd like to add the XHCI firmware) or the left side ports won't work at all. These options are already disabled by default and all the ports are functioning as USB 2.0. awokd tells: "You may have to use irqpoll in sys-usb kernel options with Qubes OS. USB interrupts don't seem to be routing correctly in Coreboot, and the only way to use them in Qubes is with irqpoll in the kernel options." " Perhaps awokd knows more about this issue, you could try to e-mail him directly. Not much more than I wrote there. When I look at log messages, I see the VM trying to send interrupt #s that don't exist. Not sure how to troubleshoot further (am open to suggestions!), but irqpoll worked well enough. Maybe different GPUs have different interrupt tables, and the one supplied doesn't fit all? They each have slightly different revisions of the G505s board. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gpg keys for coreboot distribution
On 5/14/19 3:57 PM, awokd via coreboot wrote: Chris Laprise: I might put firmware code analysis on my bucket list for the next life, if I convert to Buddhism. :) FWIW, those AMD CPU microcode updates are encrypted, so you should also include cryptanalysis on your bucket list. Don't believe the video ones are, though. To be fair, I think Patrick meant "compare" the patch with what AMD distributed. If they are the same verbatim – and the authors (AMD etc) have a verification method – then that may be do-able. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gpg keys for coreboot distribution
Chris Laprise: I might put firmware code analysis on my bucket list for the next life, if I convert to Buddhism. :) FWIW, those AMD CPU microcode updates are encrypted, so you should also include cryptanalysis on your bucket list. Don't believe the video ones are, though. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gpg keys for coreboot distribution
On 5/14/19 3:17 PM, Patrick Georgi via coreboot wrote: On 5/14/19 Chris Laprise wrote: There are also several (apparently out-of-tree) patches referenced on the G505s howto: http://dangerousprototypes.com/docs/Lenovo_G505S_hacking I'll have to get signatures or similar type of verification for these as well. Any help in this regard would be appreciated. I can understand the value in having releases signed as they are somewhat officially attached to a project. But for random patches your best bet will be to analyze their content, not their origin. I might put firmware code analysis on my bucket list for the next life, if I convert to Buddhism. :) When I look at review.coreboot.org and the patches have logged commits (ostensibly, these are at least hashed) and I see "Patrick Georgi" as reviewer... there is no assurance of fidelity from those records? -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Votes on copyright lines, line lengths and automatic formatting
Hi Patrick, Thanks for setting this up! I think it's very important that we give everyone a voice in these matters. Let me link some old discussions in case people want more context: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/4FAD25MJPI2XSSWHDDI5CSJR6SKCRFWW/#FDPB2PVVV7AB2CPJSGX4S2SFA4WNURN4 https://review.coreboot.org/c/coreboot/+/27533 https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/DXEYNXR37SW4H5QLREDFTOZRUUBJ4QLW/#3ZLYUYAP6WMXIPADPR5WUSBRASIKODD3 One thing I'm missing is an option to maintain clang-format as an optional pre-submit hook that people can choose run over only the lines their patch is touching if they want to, like I suggested in that thread above. I think if we have so many options per question anyway, that one would have been nice to add. Maybe next time we can post the draft questions and give people a chance to comment first. But the most important thing is that we're doing it at all. From: Patrick Georgi via coreboot Date: Tue, May 14, 2019 at 11:11 AM To: coreboot > Hi everybody, > > The project leadership asked me to get the developer community's > opinion on a couple of coding style related issues that were under > discussion for a long time without clear resolution. > > To that end I just setup three elections on > https://civs.cs.cornell.edu. They're ranked votes using the Condorcet > method with a single winner per question. Voting ends on end of May 21 > AoE (https://en.wikipedia.org/wiki/Anywhere_on_Earth). > > The voting population was determined by Martin and covers everybody > who made 10 contributions (changes, review flags) on > review.coreboot.org over the last 2 years. > > These eligible developers should have received an email from me last > week to introduce the process and three emails today with their > personalized link to the elections, one for each question. If you > think you're eligible but didn't get these emails, please reach out to > me directly. > > For reference (but there won't be a vote here on this list!), the > questions posed are: > > # How to handle copyright notices > The coreboot project has had issues with copyright notices for a long > time, and we’d like to start to address it. We currently don’t have > any guide on when it’s ok to add a copyright, and when it isn’t. This > and other issues like refactoring patches in gerrit lead to things > like: > * Copyright on blank files > * Adding a copyright line when deleting code > * Adding a copyright line for trivial changes such as spelling fixes > > The copyright laws around the world differ, but it seems like most of > them agree that copyright is specifically for acts of creativity. > None of the above examples are creative, so that would exclude them > from copyright protection. > > Another issue is that we’d rather not have an ever-growing list of > copyright notices at the top of each file. This has been addressed in > other projects by having an AUTHORS file, and it’s been suggested that > coreboot should follow this. > > The AUTHORS file would contain the list of copyright holders, based on > the existing copyright lines. > > # This is the list of coreboot authors for copyright purposes. > # > # This does not necessarily list everyone who has contributed code, since in > # some cases, their employer may be the copyright holder. To see the full > list > # of contributors, see the revision history in source control. > Ronald G. Minnich > Kyösti Mälkki > SUSE LINUX AG > coresystems GmbH > > All existing copyright notices would be replaced with text “Copyright > 2019 The coreboot project Authors.” > > Arguments for replacing existing copyright lines with the AUTHORS file: > * This resolves many of the current issues with copyright notices. > * Without copyright notices in each individual file, once a name is > in the AUTHORS file, the copyright holder doesn’t have to update it > again. > * The headers won’t grow because there’s just one static line. > * Copyright dates won’t have to be updated in multiple files anymore > > Arguments for leaving the copyright lines: > * A single AUTHORS file doesn’t capture the amount of work that people > have put into the codebase. The copyright line allows people to see > their contributions to coreboot. > > Please rank these choices: > * Create an authors file and remove all existing copyright lines > * Create an authors file but leave existing copyright lines > * Don’t create an authors file or change existing copyright lines > > > # Line length > There have been arguments recently that the line length is a bit too > restrictive and we should change the coding style to allow for longer > lines. > > We currently have line length exceptions for comments and print format > strings. > > Arguments for longer line lengths: > * We have large monitors and can easily see more than 80 characters now. > * It’s better to just make the code look good than to worry about > breaking the line up because it’s
[coreboot] Re: Gpg keys for coreboot distribution
On 5/14/19 Chris Laprise wrote: > There are also several (apparently out-of-tree) patches referenced on > the G505s howto: > > http://dangerousprototypes.com/docs/Lenovo_G505S_hacking > > I'll have to get signatures or similar type of verification for these as > well. Any help in this regard would be appreciated. I can understand the value in having releases signed as they are somewhat officially attached to a project. But for random patches your best bet will be to analyze their content, not their origin. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gpg keys for coreboot distribution
Hi, > These appear in only one place, on the coreboot.org Downloads page, and > are signed with the key: > > D861AB74FB933260193399696B249D77269C04E1 > > The only problem is there is apparently no mention of the signing key > anywhere else on the coreboot website. I usually look for some explicit, > official reference (preferably in multiple contexts) to a person or > org's key ID before downloading it from a keyserver. Taking the key ID > from an object signature doesn't satisfy that requirement. For whatever it's worth: that's my key (for my non-corporate email addresses) and I'm the legit (and to my knowledge) only holder of its private key. I guess I could add it to the site but then again that's the same server as the one you're download the archive and signature from, so if somebody manages to tamper with the archive they could also put their own key there. I'll make sure to get a few signatures onto the key so it's hooked up with the web of trust, but that won't happen very soon. Patrick Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gpg keys for coreboot distribution
Hi Chris, I'll get my public key uploaded to the website shortly. Thanks for pointing out the issue. Martin On Tue, May 14, 2019 at 12:34 PM Chris Laprise wrote: > Hi all, > > I'm about to embark on a coreboot build+flash per Mike Banon's G505s > page, but before building I want to verify signatures for the source. > These appear in only one place, on the coreboot.org Downloads page, and > are signed with the key: > > D861AB74FB933260193399696B249D77269C04E1 > > The only problem is there is apparently no mention of the signing key > anywhere else on the coreboot website. I usually look for some explicit, > official reference (preferably in multiple contexts) to a person or > org's key ID before downloading it from a keyserver. Taking the key ID > from an object signature doesn't satisfy that requirement. > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gpg keys for coreboot distribution
On 5/14/19 2:34 PM, Chris Laprise wrote: Hi all, I'm about to embark on a coreboot build+flash per Mike Banon's G505s page, but before building I want to verify signatures for the source. These appear in only one place, on the coreboot.org Downloads page, and are signed with the key: D861AB74FB933260193399696B249D77269C04E1 The only problem is there is apparently no mention of the signing key anywhere else on the coreboot website. I usually look for some explicit, official reference (preferably in multiple contexts) to a person or org's key ID before downloading it from a keyserver. Taking the key ID from an object signature doesn't satisfy that requirement. There are also several (apparently out-of-tree) patches referenced on the G505s howto: http://dangerousprototypes.com/docs/Lenovo_G505S_hacking I'll have to get signatures or similar type of verification for these as well. Any help in this regard would be appreciated. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Gpg keys for coreboot distribution
Hi all, I'm about to embark on a coreboot build+flash per Mike Banon's G505s page, but before building I want to verify signatures for the source. These appear in only one place, on the coreboot.org Downloads page, and are signed with the key: D861AB74FB933260193399696B249D77269C04E1 The only problem is there is apparently no mention of the signing key anywhere else on the coreboot website. I usually look for some explicit, official reference (preferably in multiple contexts) to a person or org's key ID before downloading it from a keyserver. Taking the key ID from an object signature doesn't satisfy that requirement. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Votes on copyright lines, line lengths and automatic formatting
Hi everybody, The project leadership asked me to get the developer community's opinion on a couple of coding style related issues that were under discussion for a long time without clear resolution. To that end I just setup three elections on https://civs.cs.cornell.edu. They're ranked votes using the Condorcet method with a single winner per question. Voting ends on end of May 21 AoE (https://en.wikipedia.org/wiki/Anywhere_on_Earth). The voting population was determined by Martin and covers everybody who made 10 contributions (changes, review flags) on review.coreboot.org over the last 2 years. These eligible developers should have received an email from me last week to introduce the process and three emails today with their personalized link to the elections, one for each question. If you think you're eligible but didn't get these emails, please reach out to me directly. For reference (but there won't be a vote here on this list!), the questions posed are: # How to handle copyright notices The coreboot project has had issues with copyright notices for a long time, and we’d like to start to address it. We currently don’t have any guide on when it’s ok to add a copyright, and when it isn’t. This and other issues like refactoring patches in gerrit lead to things like: * Copyright on blank files * Adding a copyright line when deleting code * Adding a copyright line for trivial changes such as spelling fixes The copyright laws around the world differ, but it seems like most of them agree that copyright is specifically for acts of creativity. None of the above examples are creative, so that would exclude them from copyright protection. Another issue is that we’d rather not have an ever-growing list of copyright notices at the top of each file. This has been addressed in other projects by having an AUTHORS file, and it’s been suggested that coreboot should follow this. The AUTHORS file would contain the list of copyright holders, based on the existing copyright lines. # This is the list of coreboot authors for copyright purposes. # # This does not necessarily list everyone who has contributed code, since in # some cases, their employer may be the copyright holder. To see the full list # of contributors, see the revision history in source control. Ronald G. Minnich Kyösti Mälkki SUSE LINUX AG coresystems GmbH All existing copyright notices would be replaced with text “Copyright 2019 The coreboot project Authors.” Arguments for replacing existing copyright lines with the AUTHORS file: * This resolves many of the current issues with copyright notices. * Without copyright notices in each individual file, once a name is in the AUTHORS file, the copyright holder doesn’t have to update it again. * The headers won’t grow because there’s just one static line. * Copyright dates won’t have to be updated in multiple files anymore Arguments for leaving the copyright lines: * A single AUTHORS file doesn’t capture the amount of work that people have put into the codebase. The copyright line allows people to see their contributions to coreboot. Please rank these choices: * Create an authors file and remove all existing copyright lines * Create an authors file but leave existing copyright lines * Don’t create an authors file or change existing copyright lines # Line length There have been arguments recently that the line length is a bit too restrictive and we should change the coding style to allow for longer lines. We currently have line length exceptions for comments and print format strings. Arguments for longer line lengths: * We have large monitors and can easily see more than 80 characters now. * It’s better to just make the code look good than to worry about breaking the line up because it’s 81 characters long. * With long Kconfig symbol names and longer, more descriptive variable names, lines have gotten longer without changing any code complexity. Arguments for keeping 80 characters: * If the code needs to go past 80 characters, the function is probably too complex. * The linux kernel has an 80 character limit, and we should maintain that. * With the existing line length exceptions, there shouldn’t be a problem. * People already have their editors set up for 80 characters and it would be a pain to change them just for coreboot’s new settings. Argument for 96 characters: * This is intended to be a compromise between 80 characters and even longer line lengths. The idea here is that it’s 2 tabstops + 80 text characters. Argument for no strict line length: * Nobody is actually advocating for super long lines - it’s just about making the code look good without actually having to worry about the line length. * We can trust coreboot developers to be reasonable and we can catch people doing stupid things in the code reviews when they’re not. Rank these options: * 80 character lines * 88 character lines * 96 character lines * 120 character lines * 132 character lines * No strict length limit #
[coreboot] Re: Lenovo G505S : USB issues at Qubes OS
Hi there Rogier, Why no tint? ;-) tint patch adds a checksum verification for the archive that will be downloaded later from Free Software Foundation during the compilation, so no security risk there. Perhaps the only downside of this tint tetris is that currently it's not compressed while being added to CBFS, so occupies about 90KB if I remember correctly, while that could be much less. Although there is a lot of free space at CBFS (>3 MB out of 4MB) while simply building a coreboot, if you'd like to add a lot of floppy-based OS later - even as few as 90KB might be an issue. It's strange that you got a variable degree of this USB issue at different laptops, it should've been the same regardless of your dGPU type. Seems to be a Qubes-only problem, a bit random, and might be possible to fix if you'd read a note here - http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#TODO_list . Here's a copy-paste : " 2) Both XHCI options in Coreboot menu should be disabled (unless you'd like to add the XHCI firmware) or the left side ports won't work at all. These options are already disabled by default and all the ports are functioning as USB 2.0. awokd tells: "You may have to use irqpoll in sys-usb kernel options with Qubes OS. USB interrupts don't seem to be routing correctly in Coreboot, and the only way to use them in Qubes is with irqpoll in the kernel options." " Perhaps awokd knows more about this issue, you could try to e-mail him directly. P.S. Hope you don't mind that I CC a coreboot mailing list, this troubleshooting knowledge may be useful to someone else so should be public On Tue, May 14, 2019 at 7:48 AM Rogier en Ingrid wrote: > > I got a few issues - mainly with Qubes 4.0.1. Not included the tint patch, > also changed the .config to not include tint. For the rest, included all your > nice patches. > > After installing Qubes 4.0.1, initialization of the OS, i noticed some errors > when starting (will include them later today in 2nd mail) and mainly some > weird USB port behavior: the laptop with dgpu R5-M230: none of the USB ports > work when running Qubes (though all work at boot). the laptop with dgpu > HD-8570M: usb 2.0 port does not work, both usb 3 on the left work. > Only again when running Qubes, not when booting a live Ubuntu for example. > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
