3:30 p.m.
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,39…
Any thoughts?
Cheers
4:27 p.m.
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(a)rbox.co>
À: coreboot(a)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,39…
Any thoughts?
Cheers
_______________________________________________
coreboot mailing list -- coreboot(a)coreboot.org
To unsubscribe send an email to coreboot-leave(a)coreboot.org
12:28 p.m.
On 22 Jun 2019 21:30, Anac <anac(a)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,39…
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.
5:17 p.m.
On Mon, Jun 24, 2019 at 7:20 AM Hubert Ruch <ruch(a)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
7:25 p.m.
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
7:35 p.m.
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
8:16 p.m.
On 6/24/19 10:17 PM, ron minnich wrote:
On Mon, Jun 24, 2019 at 7:20 AM Hubert Ruch
<ruch(a)runbox.com> wrote:
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 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.
10:18 p.m.
Thanks for clearing that up 😀
On Mon, Jun 24, 2019, 11:16 AM Hubert Ruch <ruch(a)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(a)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(a)coreboot.org
To unsubscribe send an email to coreboot-leave(a)coreboot.org
12:42 a.m.
On Mon, 24 Jun 2019 08:17:14 -0700
ron minnich <rminnich(a)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.
2:28 a.m.
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.
3:10 a.m.
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(a)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.
7 p.m.
On 23.06.19 12:04, Hubert Ruch wrote:
On 6/23/19 12:00 PM, Stefan Reinauer via coreboot
wrote:
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.
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.
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
2:14 p.m.
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
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info(a)metux.net -- +49-151-27565287
345
days inactive
350
days old
14 comments
10 participants
participants (10)
-
Anac -
David Hendricks -
Denis 'GNUtoo' Carikli -
echelon＠free.fr -
Enrico Weigelt, metux IT consult -
Hubert Ruch -
Julius Werner -
Nico Huber -
ron minnich -
Stefan Reinauer