Integrating (temporarily) proprietary tooling into our build system (was Re: Intel CBnT tooling and dealing with NDA) - coreboot

10 Feb 2021

      Hi Arthur,
I appreciate that you took the matter to the mailing list. This gives
us the chance to really discuss it before we create yet another prece-
dent. I urge all of us to not demand or make any hasty decision.
Please understand that integration of any new proprietary component
naturally wakes heavy feelings. It doesn't seem like there is a gua-
rantee that Intel will allow you to release the source code of your
tool. So for now it's proprietary software. Putting the whole story
together, what you are asking for is
the integration of a proprietary tool to configure proprietary
  firmware parts around a proprietary version* of what used to be
  a free-software project.
  (*existing coreboot port is only usable with an NDA)
I don't say that's impossible. I just want you to understand what
thoughts you have to expect. Actually, I believe it is possible and
we should carefully assess a compromise as you suggested. However,
it seems possible that the effort required by this discussion will
outweigh the convenience you would buy yourself (and/or your customer)
with such a compromise. Also, the question `how` might be even more
delicate than `if` we should do this. Especially with a statically
linked binary, there is a lot more code involved compared to what
we'd pull in as source code.
On 09.02.21 11:02, Arthur Heymans wrote:
...
My question to the community is if it would be ok to allow for the build system
integration code for KM and BPM generation to be integrated into the
master branch
before the code to the tooling is made public.
CBnT is an optional feature on Intel hardware and is implemented as an
optional feature in
coreboot. The tool is standalone and coreboot can still be built fine
without it.
At the moment coreboot has code for xeon_sp in the master
branch without a public FSP too, with the promise that it will be
publicly released later
on by Intel. Compared to that the situation would be a little better:
I can't agree to any such comparison. The situation is completely
different. The risk of compromising the integrity of the whole build
environment can't be compared to the risk of compromising single
firmware builds.
One might say it's the lesser insult, though.
...
we propose to add a binary tool (it's written in go so it's
automatically build as a static binary) to the blobs repo under a
licence similar to the one used for Intel FSP and MCU (allows
redistribution). We hope to remove it ASAP from there and build it
from source from 3rdparty/intel-sec-tools.
We'd like to develop as close as possible to the coreboot master
branch, so we hope that this is an acceptable solution to the
community.
So TL;DR:

Is (temporarily) adding a tool to the blobs repo ok?

I would say yes. But prefer a separate repository.
...

Is integrating an (optional) not yet open tool into the build system ok?

I don't think so. That's just my opinion. However, in case we proceed,
I think there should be rules about it. Some things from the top of my
mind (alas, I don't have the time to provide a comprehensive list of
my thoughts):
It should be *optional* (don't know why you put it in parentheses).
There should be warnings about it in Kconfig at least. Probably even
something like a "Press enter to proceed" during the build.
Rationale: People need to know! Some people still care about security;
  others might have to, or even risk there status if they fail to. For
  instance at secunet, we build our software in a highly restricted
  environment. If we proceed here, secunet would likely stop mirroring
  the blobs repo just to be sure (it seems possible because we don't
  depend on it anymore).
All components used to produce the binary and the environment in which
it took place should be documented, also all further processing and
checking, e.g. which antivirus software was run.
Rationale: (ask somebody who used PCs in the '90s)
...
Let me know what you think.
One more thought: Get a lawyer. Be 100% sure about the license. Make
sure Intel agrees to it. FWIW, some people interpret the BSD license
when used for binaries as a free pass to reverse-engineering and
modifications (what I humbly presume Intel would not want for their
binaries).
Nico