Hi,
On Tue, 14 Mar 2023 at 22:52, Vishwanath Pai wrote:
>
> Hi All,
>
> I noticed that with the latest update to grub2-unsigned, one of the build
> dependencies is gcc-10.
> But gcc-10 is not available on bionic. We build ubuntu packages in our build
> system from source but
> unfortunately we have no way to build the new grub2-unsigned package in our
> bionic build
> environment.
>
> Also another dependent package: libfuse3-dev is similarly not available on
> bionic. How is
> grub2-unsigned being built for the official ubuntu repositories?
src:grub2 provided in a given suite is currently buildable in a given
suite. It was changed to exclude building EFI platform code, which is
now built by src:grub2-unsigned, once on one series with one
toolchain, and reused in all ubuntu releases.
Due to multiple recent EFI only vulnerabilties, to reduce security
review and maintenance and debugging/compatiblity checking costs, it
was decided to split src:grub2 into src:grub2 (with all the unsigned
platforms) and src:grub2-unsigned which only contain EFI platform
bootloader without any userspace binaries or dependencies.
If you observe the builds on launchpad, you will notice that
src:grub2-unsigned is built once, and is packaged to ensure that it is
a free standing package without any hard runtime dependencies on the
host system. I.e. open pad.lv/u/grub2-unsigned, click on a desired
version and observe the build
https://launchpad.net/ubuntu/+source/grub2-unsigned/2.06-2ubuntu14.1
you will see that it was compiled in Kineitc once, and published in
all the suites identically bionic; focal; jammy; kinetic. The build
log for each architecture, clearly states that kinetic build-shcroot
was used, and that produced binaries can be published and install in
both older, same and newer series, due to unique engineering we did in
the build process of only that pacakge.
The result of that is signed by Canonical Secureboot keys, and
published from src:grub2-signed package which in turn has per-series
runtime dependencies and versions, but vendors the same identical
build of the signed EFI package.
It is on our plans to provide a gcc-10 toolchain backport, such that
each suite can rebuild the binary package again. However, this will
not reproduce the same result, and may introduce security
vulnerabilities that rely on the toolchain features provided during
build. To reproduce what we have done in the Ubuntu archive, imho it
best to redo what we did - stand up Kinetic builder, build the source
package in Kinetic chroot, sign it with your own keys, rebuild
grub2-signed from scratch pointng at your signed binaries.
Note, rebuilding grub2-unsigned alone is not very useful, as it is not
used on installed systems at all. As the binaries it produces in the
signing tarball, have to be signed (for example we use Launchpad
Signing Service provided in the PPA and Archive builders), and then
revendored back inside grub2-signed. I am assuming you have your own
secureboot signatures, and you rebuild -signed packages yourself with
your own signatures.
If you do not rebuild signed binaries, and do not resign them with
your own secureboot keys, and instead rely on industry wide CA
certificates and using Canonical signed secureboot signatures - then
you probably already skip rebuilding packages such shim / shim-signed,
grub2 / grub2-signed, linux / linux-signed' and thus should also skip
grub2-unsigned.
Please note, this is the same thing we have been doing with shim /
shim-signed packages previously. So please check what you have been
internally doing with shim / shim-signed packages.
If you do not use Secureboot at all, and the split of platform code
that is built by src:grub2 & src:grub2-unsigned of different version
is not useful to you, you could patch those to either use a stock
toolchain, or revert to making src:grub2 package to generate all
bootloader platforms. Depending on what you do, this might be a
reasonable approach, however that will not include fixes for all
publically known vulnerabilities affecting EFI builds.
Please let me know publicly or privately, if this helps, or if you
have any further questions.
--
okurrr,
Dimitri
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
