Hi,
As part of my work on GNU Boot, I found nonfree software in vboot[1] in tests/futility/data. The same binaries also probably have free software with missing corresponding source code but I didn't take the time to confirm that yet.
We'll take bios_link_mp.bin as an example. As many people know, is used in the first Chromebook pixel, and it's easy to extract things like the Management Engine firmware (with ifdtool -x) and to verify it with me_cleaner (though I'm unsure how to print which partitions it has and print that they are verified). It's also possible to extract things like the MRC binary as well with cbfstool (with cbfstool layout and then using the BOOT_STUB region of fmap).
Several distributions ended up using vboot source code to make some vboot-utils packages. It includes distributions like Debian, Fedora, Guix, Trisquel, etc. So these distributions ended up redistributing the mrc.bin for instance when they published the source version of the vboot-utils package.
Since all these distributions have repositories where redistributing nonfree software is forbidden, they automatically have a bug to solve here so I started bug reporting to them.
The distributions could also workaround and somehow remove the binaries from the source they publish but this then brings a question of maintenance over time, so this is what bring me here.
Questions on vboot: ------------------- Who is the vboot upstream, is it Coreboot or is it Google? Who should we discuss with when trying to understand if it's possible to find a solution.
Does anyone redistributing the vboot source code also has the right to distribute the binaries as-is (including things like Intel Microcode)? Since they come with no licenses there is also nothing that forbids reverse engineering, right?
Would it be possible to somehow remove or move the binaries somewhere else like in a separate git repository and make them optional in the tests? Or should we create free binaries somehow? Though I fear that the later somehow defeat the intent of the tests.
References: ----------- [1]https://review.coreboot.org/vboot.git
Denis.
Hi Denis,
Apologies that this has caused problems for you. This is just some old test data used to confirm that the parser in the command line utility works, and I don't think anyone thought about the redistribution legality implications of putting those images into the repo. I agree that it's not a good situation and we should try to fix it.
vboot upstream is Google. I am not a lawyer but I believe that Google has a license to redistribute these firmware images in binary form, but I'm not sure about specifics for further re-redistribution. I would definitely not recommend taking this as an invitation to reverse engineer anything that you otherwise don't have the right to.
There is no real reason for these binaries to be in those test fixtures — the point of the tests is just to verify parsing for vboot data structures, the actual contents of the file are not really relevant. So I think the easiest solution here is to just delete the offending contents from the images. I have opened a bug for this in Google's public tracker that you can follow here if you want: https://issuetracker.google.com/issues/374385985 . However, changing this will require some effort since the images need to be re-signed after modification and probably require some massaging to ensure the tests still work as intended afterwards, so we may need some time to find someone who has the time to take care of this (personally, I'm unfortunately a bit too busy at the moment).
On Sat, Oct 12, 2024 at 8:09 AM Denis 'GNUtoo' Carikli GNUtoo@cyberdimension.org wrote:
Hi,
As part of my work on GNU Boot, I found nonfree software in vboot[1] in tests/futility/data. The same binaries also probably have free software with missing corresponding source code but I didn't take the time to confirm that yet.
We'll take bios_link_mp.bin as an example. As many people know, is used in the first Chromebook pixel, and it's easy to extract things like the Management Engine firmware (with ifdtool -x) and to verify it with me_cleaner (though I'm unsure how to print which partitions it has and print that they are verified). It's also possible to extract things like the MRC binary as well with cbfstool (with cbfstool layout and then using the BOOT_STUB region of fmap).
Several distributions ended up using vboot source code to make some vboot-utils packages. It includes distributions like Debian, Fedora, Guix, Trisquel, etc. So these distributions ended up redistributing the mrc.bin for instance when they published the source version of the vboot-utils package.
Since all these distributions have repositories where redistributing nonfree software is forbidden, they automatically have a bug to solve here so I started bug reporting to them.
The distributions could also workaround and somehow remove the binaries from the source they publish but this then brings a question of maintenance over time, so this is what bring me here.
Questions on vboot:
Who is the vboot upstream, is it Coreboot or is it Google? Who should we discuss with when trying to understand if it's possible to find a solution.
Does anyone redistributing the vboot source code also has the right to distribute the binaries as-is (including things like Intel Microcode)? Since they come with no licenses there is also nothing that forbids reverse engineering, right?
Would it be possible to somehow remove or move the binaries somewhere else like in a separate git repository and make them optional in the tests? Or should we create free binaries somehow? Though I fear that the later somehow defeat the intent of the tests.
References:
[1]https://review.coreboot.org/vboot.git
Denis. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Fri, 18 Oct 2024 17:08:56 -0700 Julius Werner jwerner@chromium.org wrote:
Hi Denis,
Hi,
There is no real reason for these binaries to be in those test fixtures — the point of the tests is just to verify parsing for vboot data structures, the actual contents of the file are not really relevant. So I think the easiest solution here is to just delete the offending contents from the images. I have opened a bug for this in Google's public tracker that you can follow here if you want: https://issuetracker.google.com/issues/374385985 .
Thanks a lot for doing that.
Your bug report mainly talks about binaries in CBFS, but there is most probably also Management firmwares in the images (which are less likely to be redistributable than MRC/FSP or microcode updates).
I managed to verify signatures with me_cleaner from the latest Coreboot revision (c21bed6de9):
$ ifdtool -x tests/futility/data/bios_link_mp.bin File tests/futility/data/bios_link_mp.bin is 8388608 bytes Flash Region 0 (Flash Descriptor): 00000000 - 00000fff Flash Region 1 (BIOS): 00200000 - 007fffff Flash Region 2 (Intel ME): 00001000 - 001fffff Flash Region 3 (GbE): 00fff000 - 00000fff (unused) Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused) $ me_cleaner.py -c flashregion_2_intel_me.bin ME/TXE image detected Found FPT header at 0x10 Found 15 partition(s) Found FTPR header: FTPR partition spans from 0x93000 to 0x108000 ME/TXE firmware version 8.0.20.1513 Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x Checking the FTPR RSA signature... VALID
But above I said 'probably' because here I manage to verify the Management engine partitions signatures but me_cleaner doesn't print the names of the partitions, so in theory it could be also just a header and it's harder to verify that it doesn't contain nonfee and/or non-resitributable code, especially because some versions were encoded with huffman compressions.
Though given that the images were signed with the release keys for the Chromebooks, I assume this is the real Management Engine firmware that's in there.
Denis.
Your bug report mainly talks about binaries in CBFS, but there is most probably also Management firmwares in the images (which are less likely to be redistributable than MRC/FSP or microcode updates).
Yes, those are stored in the FMAP regions SI_ALL, ME_RW_A and ME_RW_B that I mentioned in the bug. We're planning to replace them with zeroes as well. (For those it's actually easier since they are not directly signed by vboot.)
FMAP and CBFS are two layers of organization structures in our images, with FMAP being the top one. You can see the offsets for which FMAP section covers what with `futility dump_fmap -h <image file>`. This will show you that offsets 0x93000 and 0x108000 lie in the SI_ME section (a subsection of SI_ALL) for bios_link_mp.bin.
-
Denis 'GNUtoo' Carikli -
Julius Werner