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