Building grub2-unsigned from sources on bionic

[Vishwanath Pai]

On 3/14/2023 7:10 PM, Dimitri John Ledkov wrote:
> Hi,
>
> On Tue, 14 Mar 2023 at 22:52, Vishwanath Pai <vpai at akamai.com> 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://urldefense.com/v3/__https://launchpad.net/ubuntu/*source/grub2-unsigned/2.06-2ubuntu14.1__;Kw!!GjvTz_vk!RjW8AcSZemW-Z7-d_LxLhLWL__BMji4z7lfamWxNaygZL0E9Lf3CQ-E29X_hIJZYOfrMbf4BznY2wWbHEiFs9Fs$ 
> 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.
>
Hi Dimitri,

Thank you for the quick and detailed response, this was very helpful. I understand that having one
src package and one build toolchain makes it easier to maintain in terms of limiting security
issues. We're currently building both the grub packages for all LTS versions separately, but we may
try to do what Ubuntu does and stick to one build for grub2-unsigned.

> you will see that it was compiled in Kineitc once, and published in
> all the suites identically bionic; focal; jammy; kinetic.

We only have build environments for the LTS releases, currently this builds fine on focal but for
future updates it would be nice if you can make sure the package builds with at least one major LTS
release.

W.r.t to secureboot, we have our own implementation of secureboot and this is handled outside of the
build system. We did think about using the grub2 package to generate the binaries like before but it
would be easier for us to maintain if we do what Ubuntu does and the unsigned package being much
newer than the grub2 package also helps.

We'll continue to use the unsigned package, for now I can build this in focal and push it to our
bionic repo.

While we're here, I see that there are a couple of updates to grub2 that are currently in the
-proposed repos in focal and bionic, what is the policy on when this gets pushed to -updates?

Thanks,
Vishwanath