Dear all,
Is it true that there's code provided by the NSA implemented in Coreboot?
https://www.tomshardware.com/news/nsa-contributes-low-level-stm-coreboot,397...
Any thoughts?
Cheers
Welcome NSA! .. if you come with good intentions and all you commit is thoroughly documented and with very clean code .. Regards, Florentin
PS : this is NOT a troll, this is my sincere thought..
----- Mail d'origine ----- De: Anac anac@rbox.co À: coreboot@coreboot.org Envoyé: Sat, 22 Jun 2019 15:30:54 +0200 (CEST) Objet: [coreboot] Does NSA contribute to Coreboot?
Dear all,
Is it true that there's code provided by the NSA implemented in Coreboot?
https://www.tomshardware.com/news/nsa-contributes-low-level-stm-coreboot,397...
Any thoughts?
Cheers _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Sat, Jun 22, 2019 at 7:06 AM Anac anac@rbox.co wrote:
Any thoughts?
Seems fine to me. I'm a lot more concerned about contributions by state actors to firmware that's NOT open.
On 22 Jun 2019 21:30, Anac anac@rbox.co wrote:
Dear all, Is it true that there's code provided by the NSA implemented in Coreboot? https://www.tomshardware.com/news/nsa-contributes-low-level-stm-coreboot,39704.html Any thoughts? Cheers
On 6/23/19 12:00 PM, Stefan Reinauer via coreboot wrote:
Remember that the project was started by Los Alamos National Labs (LANL), the guys that also brought you the Manhattan Project. Contributions have also been made by the BSI (German version of the NSA) and their contractors.
Thanks for the info. Didn't know that. Now, one has to wonder how many skilled developers actually do read and understand their code. IIRC Leah Rowe paid someone $90.000 for adding some code to LibreBoot. I'm mentioning this because it leads to the assumption that boot coding must be a pretty difficult task.
On Mon, Jun 24, 2019 at 7:20 AM Hubert Ruch ruch@runbox.com wrote:
Thanks for the info. Didn't know that. Now, one has to wonder how many skilled developers actually do read and understand their code. IIRC Leah Rowe paid someone $90.000 for adding some code to LibreBoot. I'm mentioning this because it leads to the assumption that boot coding must be a pretty difficult task.
Speculation preceded by IIRC is not helpful. Lots of people read this list and you can now expect to see your IIRC bounce around the world as fact, and we have no idea if it's true or not.
As Stefan points out, the project started at LANL in 1999 and ran there for over five years, so USG involvement is hardly new. DOE Labs spent well over $10M on systems running LinuxBIOS over a 6 year period, and if we count the full cost of the DOE Lab FTEs contributing to LinuxBIOS, the total commitment from 1999-2006 edges up to about $20M. I know this because I oversaw the purchase of most of those systems, and the funding of those FTEs (including me).
It's probably not well remembered at this point but the NSA also contributed a lot to early Linux. Go back far enough, look at some of Don Becker's ethernet drivers, and you will find National Security Agency copyrights. This is because at the time Don wrote those drivers he worked at the Supercomputing Research Center in Bowie, MD, USA. I know this because I was there at that time too. Don was very active in the creation of the early Linux networking stack, not just drivers. NSA contributions to open source code goes back almost 30 years.
We're reviewing the STM code, of course. If you're going to worry about something, worry about FSP 2.0 still being closed source. FSP is not optional and we have no idea of all the things it does/can do.
Finally, boot coding is a pretty difficult task. You don't see how hard it is on x86 any more because x86 now depends on binary blobs to work (I'm still very sad about that) and the really hard parts are in the blobs. But it is intricate, difficult code, even on simple ARM SOCs. That has not changed.
ron
On 24.06.19 17:17, ron minnich wrote:
We're reviewing the STM code, of course. If you're going to worry about something, worry about FSP 2.0 still being closed source. FSP is not optional and we have no idea of all the things it does/can do.
You are saying this as if it would be magically better if it were open source. It's not legible code at all. Without a rewrite of its cherries, we would still have no idea about it. Its integration into coreboot is open source, btw. And even supposed to be reviewed. But it looks like hell. Parts of it never made any sense and most of the rest is copy- paste degraded. So much for reviewed code. I bet the integration of FSP-S has already outgrown the amount of code of an FSP-S rewrite.
Oh, and I'm rather sure FSP is optional. If it weren't, selling coreboot products with it would seem like a GPL violation, at least to me.
Finally, boot coding is a pretty difficult task. You don't see how hard it is on x86 any more because x86 now depends on binary blobs to work (I'm still very sad about that) and the really hard parts are in the blobs. But it is intricate, difficult code, even on simple ARM SOCs. That has not changed.
Well, I experience this very differently. Reviews aside, I spent most of my time with bug fixing. And most of the bugs I encounter are either due to unnecessary software complexity or because somebody ignored the little documentation that exists. Those aren't boot-coding problems.
Nico
Well, I experience this very differently. Reviews aside, I spent most of my time with bug fixing. And most of the bugs I encounter are either due to unnecessary software complexity or because somebody ignored the little documentation that exists. Those aren't boot-coding problems.
re whether firmware is hard: I used to think it was not so bad. But I've changed my mind.
What I learned, when I came back to coreboot in 2012 after a few years off, is that it can be pretty hard, esp. around stuff like memory training. I was shocked by how much I'd forgotten and how hard I found it to get started up again. Another change is that every bus seems to need training. Another observation: I've been told that it can take a few years, on newer complex chipsets, to get the DRAM code working -- one reason it's nice we can update the romstage in chromebooks. Final datapoint: a supercomputer vendor shipped a big machine, ca. 2007, and it was over a year before they chased down some memory issues -- and they *started* with a working port (I tried to help them with that and failed). I think firmware is hard.
Nico, I accuse you of being extremely good at this kind of work; it only looks easy to you :-)
ron
On 6/24/19 10:17 PM, ron minnich wrote:
On Mon, Jun 24, 2019 at 7:20 AM Hubert Ruch ruch@runbox.com wrote:
Thanks for the info. Didn't know that. Now, one has to wonder how many skilled developers actually do read and understand their code. IIRC Leah Rowe paid someone $90.000 for adding some code to LibreBoot. I'm mentioning this because it leads to the assumption that boot coding must be a pretty difficult task.
Speculation preceded by IIRC is not helpful. Lots of people read this list and you can now expect to see your IIRC bounce around the world as fact, and we have no idea if it's true or not.
Here's the source. Leah Rove writes that she "paid 90,000 USD to Raptor Engineering to port the ASUS KGPE-D16 and KCMA-D8 to Libreboot". https://libreboot.org/news/leah-fundraiser.html
Thanks for clearing that up 😀
On Mon, Jun 24, 2019, 11:16 AM Hubert Ruch ruch@runbox.com wrote:
On 6/24/19 10:17 PM, ron minnich wrote:
On Mon, Jun 24, 2019 at 7:20 AM Hubert Ruch ruch@runbox.com wrote:
Thanks for the info. Didn't know that. Now, one has to wonder how many
skilled developers actually do read and understand their code. IIRC Leah Rowe paid someone $90.000 for adding some code to LibreBoot. I'm mentioning this because it leads to the assumption that boot coding must be a pretty difficult task.
Speculation preceded by IIRC is not helpful. Lots of people read this list and you can now expect to see your IIRC bounce around the world as fact, and we have no idea if it's true or not.
Here's the source. Leah Rove writes that she "paid 90,000 USD to Raptor Engineering to port the ASUS KGPE-D16 and KCMA-D8 to Libreboot". https://libreboot.org/news/leah-fundraiser.html _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Mon, 24 Jun 2019 08:17:14 -0700 ron minnich rminnich@gmail.com wrote:
We're reviewing the STM code, of course. If you're going to worry about something, worry about FSP 2.0 still being closed source. FSP is not optional and we have no idea of all the things it does/can do.
Not only that.
For people that don't run any nonfree code somewhere else, the main thing to worry in that context should rather be all the nonfree software that is used during boot (FSP, Management Engine OS, PSP, SMU, etc), or at the lowest levels, and the CPU microcode.
On the hardware supported by Libreboot, it's possible to get rid of most of the issues as they make sure that what they ship is fully free software.
However, even with Libreboot, some very minor issues, compared to the rest, still need to be solved: - The Management Engine has a ROM that might still do unknown things once the computer is booted. For the computers with a GM45 chipset. - The Thinkpads have nonfree code on the embedded controller, this could be abused as a keylogger or could inject commands. This looks less a concern as it would need to be triggered in some way. - All x86 computers have a microcode, and so it may contain a similar backdoor than the one shown in the "Reverse Engineering x86 Processor Microcode". The microcode updates may also contain a backdoor so that won't solve the issue either.
The ARM laptops supported by Libreboot are not affected. The supported AMD computers could also be not affected if/when their microcode are fully understood and that there are free software microcode patches to fix the most problematic issues.
There is also some minor packaging work to be done on ARM, for instance there is no tor-browser release for ARM GNU/Linux yet, but I heard that some people are working on that.
However for people that also run other nonfree software, including JavaScript in web pages, there is way too much things to care about to make sure that this software cannot somehow gain more privileges.
This could still be improved by whitelisting some known free JavaScript programs (LibreJS does some of that), and/or making the websites work without Javascript. This could be worked on in the popular free and open source software web frameworks, and in the programs that block Javascript (like noscript, libreJs, etc).
There is probably a long way to go for that, even if some minor improvements could have major usability improvements at the beginning.
Denis.
We're reviewing the STM code, of course.
While we're on the topic, can someone please ask the NSA to honor our coding style? ;) I don't want to get involved because it's really not my area, but it looks pretty terrible at the moment (full of camelCase and ALL_CAPS identifiers, C99 comments, typedefs to non-coreboot types, commented-out code, incorrect or missing license headers, #pragma pack() instead of __packed, etc.). If they just want to copy&paste wholesale UEFI files to coreboot, they should dump them in vendorcode instead.
Julius, good point. You're right.
I was about to talk to the author and ask if he would mind some help. I'd like to see this code get in.
On Mon, Jun 24, 2019 at 5:28 PM Julius Werner jwerner@chromium.org wrote:
We're reviewing the STM code, of course.
While we're on the topic, can someone please ask the NSA to honor our coding style? ;) I don't want to get involved because it's really not my area, but it looks pretty terrible at the moment (full of camelCase and ALL_CAPS identifiers, C99 comments, typedefs to non-coreboot types, commented-out code, incorrect or missing license headers, #pragma pack() instead of __packed, etc.). If they just want to copy&paste wholesale UEFI files to coreboot, they should dump them in vendorcode instead.
On 23.06.19 12:04, Hubert Ruch wrote:
On 6/23/19 12:00 PM, Stefan Reinauer via coreboot wrote:
Remember that the project was started by Los Alamos National Labs (LANL), the guys that also brought you the Manhattan Project. Contributions have also been made by the BSI (German version of the NSA) and their contractors.
Thanks for the info. Didn't know that. Now, one has to wonder how many skilled developers actually do read and understand their code.
Very few I assume. But for this particular contribution I can say that it will be an optional feature. Actually, an optional security feature for an optional feature (SMM). If you use your boot firmware to boot and not to hide secrets or to provide any other added "security", you are most likely safe :)
But due to this "optional" nature, I guess, there won't be many people reading the code.
IIRC Leah Rowe paid someone $90.000 for adding some code to LibreBoot. I'm mentioning this because it leads to the assumption that boot coding must be a pretty difficult task.
I do remember that too (roughly same number), but it wasn't about ad- ding code but about releasing it under the GPL. Nobody was paid for the review nor for improving the code during review. So it ended up as probably the worst code in our repository, IMO.
However, I don't understand your conclusion. If somebody works for one or two years on some code, they got to be paid. For the amount of code, that number seemed reasonable to me.
Also, my very personal opinion: "boot coding" is not a difficult task. Some vendors may try to make you think that it is, so nobody learns how they do it. Others may make it hard by not providing the necessary docu- mentation. Imagine you would want to write a compiler for x86 but its instructions weren't documented? Does that make compiler development hard per se? I don't think so.
Nico
On 23.06.19 12:04, Hubert Ruch wrote:
IIRC Leah Rowe paid someone $90.000 for adding some code to LibreBoot. I'm mentioning this because it leads to the assumption that boot coding must be a pretty difficult task.
roughly 80 days of work for board bringup w/ such a complex and badly documented hw platform doesn't seem unusual. ARM is *much* easier here.
--mtx
-
Anac -
David Hendricks -
Denis 'GNUtoo' Carikli -
echelon＠free.fr -
Enrico Weigelt, metux IT consult -
Hubert Ruch -
Julius Werner -
Nico Huber -
ron minnich -
Stefan Reinauer