nullboot 0.5.0: shim 15.7-0ubuntu1 update

This bug was fixed in the package nullboot - 0.5.0-0ubuntu1

---------------
nullboot (0.5.0-0ubuntu1) noble; urgency=medium

  [ Julian Andres Klode ]
  * Target Go 1.18 to allow newer dependencies with bug fixes
  * GitHub actions:
    - ci: Use pip to install pre-commit
    - Update coveralls for parallel builds
  * Rebuild against new shim 15.7-0ubuntu1 (LP: #2045552)
    - CVE-2022-28737

  [ Dimitri John Ledkov ]
  * Upgrade to snapd 2.61 and some of the other deps (#68) (LP: #2045552)

  [ dependabot[bot] ]
  * Various automated dependency bumps, no further changes required

 -- Julian Andres Klode <email address hidden> Mon, 04 Dec 2023 12:30:07 +0100

This is hard to review for an SRU. It looks like a code dump. What is it fixing? The impact section just says "security update for shim", shouldn't this go into the security pocket then?

Does this fall under any existing SRU exception?

@ahasenack

This must not go direct to security pocket, as it will require testing out of proposed by CPC & Azure Cloud partner, then it can be released into update and security.

Nullboot vendors in a copy of the shim, that it knows how to do TPM sealing for to support FDE feature on Azure CVM instances.

The shim that nullboot vendors-in right now in jammy is security vulnerable and has been revoked.

A no-change rebuild would update the copy of the shim inside the nullboot build - however that would regress resealing support, as the update shim has different TPM measurements which nullboot needs to know.

The kicker is, that there is no measurements specific code in nullboot, as all of it comes from snapd/secboot libraries. Thus these got updated to the exact same revisions as are used by the stable release of snapd (at the time the update was prepared and tested in Noble with Azure).

One thing one can verify is that the go.mod manifest matches the one in use in noble, and in https://github.com/canonical/encrypt-cloud-image and also was in use in snapd. As that's what is known to work with the upgraded shim.

Without this update, soon, it will become impossible to launch any Azure CVMs as they are about to upgrade dbx revocations, and thus revoke ability to boot the obsolete shim as currently shipped in Jammy.

https://github.com/canonical/encrypt-cloud-image is the tool used on the azure cloud side to provision the encrypted CVM instances which is used for the first seal.

nullboot side of code is used for ongoing upgrades and resealing, and more importantly shim upgrades.

Basically what you want to do is filterdiff -p1 -x vendor/ such that you only diff the nullboot stuff and the list of dependencies in go.mod.

Unfortunately policy requires us to vendorize the Go dependencies, and we need to keep those dependencies up to date such that security is happy. There is no way to backport individual fixes in dependencies. This is virtually the same for all Go projects.

But the entire vendor/ directory is automatically generated at git export time by go mod vendor (using a pre-export hook in debian/gbp.conf).

Least importantly: it seems you based this off 0.4.0-0ubuntu0.22.04.1 in jammy release rather than 0.4.0-0ubuntu0.22.04.2 in jammy-security, so it's missing that changelog entry. 0.4.0-0ubuntu0.22.04.2 was just a no-change rebuild against Go 1.18 though, so it doesn't matter much.

> The kicker is, that there is no measurements specific code in nullboot, as all of it comes from snapd/secboot libraries. Thus these got updated to the exact same revisions as are used by the stable release of snapd (at the time the update was prepared and tested in Noble with Azure).

This makes it seem like there could be a different SRU, vendoring versions of those libraries that *just* have the new measurement code, that would be drastically smaller. Has it been considered? If it's unreasonable effort that's OK, but it'd be much easier to review and more clearly SRU-policy-compliant if it included a minimal diff.

It's not entirely clear to me what the scope of possible failures is here - failure to boot is pleasantly obvious. Is this influenced by user configuration, or does it booting *anywhere* mean it will boot *everywhere*? My understanding of the TPM stack is limited, but my understanding is that if it boots *at all* then it must have booted an expected image - is this correct, or should we also be testing that the update correctly *fails* to boot unexpected images?

And to clarify:
> Double check bios_measurements_log to ensure that the newly update shim was used for boot (https://github.com/canonical/tcglog-parser/tree/master/tcglog-dump can be used to extract checksum of the shim binary used at boot and compared to the one shipped in nullboot
You'd be checking the checksum of /usr/lib/nullboot/shim/shimx64.efi.signed (using what checksum function?)

Feel free to ping me in #ubuntu-release with any answers :)

I believe that is what happened to some extend, but it certainly wasn't our goal. Our goal is to (be able to) uphold our commitment to the security team to keep our dependencies up-to-date, and there are no stable branches to pick from (often not even tags) nor do we want to fork hundreds of repos and add redirects to go.mod so that we can use them, so that means we need to regularly update to the latest upstream git branches.

We did not pick the latest versions for all the measurement code, but just the bare minimum to get it working. The dependabot bot did some updates of the golang.org utility libraries and the test suite helper, but those do not have stable branches, so we ultimately have no choice but to keep them updated when the bot tells us to.

From a SRU perspective this should be straightforward:

- Changes to the vendor/ directory are automatic and should be ignored, it is just an expansion of go.mod
- Check that go.mod contains the same (or newer) versions of the dependencies as snapd to ensure we don't miss security fixes.

> This makes it seem like there could be a different SRU, vendoring versions of those libraries that *just* have the new measurement code

This is what this actually is >_< and it's that big.

Ok. You've convinced me this is the minimal reasonable change :)

I've still got a couple of questions about the process of testing:

It's not entirely clear to me what the scope of possible failures is here:
* failure to boot is a pleasantly obvious failure mode, but is this influenced by user configuration, or does it booting *anywhere* mean it will boot *everywhere*?
* My understanding of the TPM stack is limited, but my understanding is that if it boots *at all* then it must have booted an expected image - is this correct, or should we also be testing that the update correctly *fails* to boot unexpected images?

And to clarify:
> Double check bios_measurements_log to ensure that the newly update shim was used for boot (https://github.com/canonical/tcglog-parser/tree/master/tcglog-dump can be used to extract checksum of the shim binary used at boot and compared to the one shipped in nullboot

From package contents I assume you'd be checking against the checksum of /usr/lib/nullboot/shim/shimx64.efi.signed, but what checksum algorithm?

It's not entirely clear to me what the scope of possible failures is here:
* failure to boot is a pleasantly obvious failure mode, but is this influenced by user configuration, or does it booting *anywhere* mean it will boot *everywhere*?

To the extent relevant here, being a regression, I don't see how it could fail to boot on some but not on others. The only user configuration you have is kernel commandline, if it boots with the old nullboot it boots with the new one.

> * My understanding of the TPM stack is limited, but my understanding is that if it boots *at all* then it must have booted an expected image - is this correct, or should we also be testing that the update correctly *fails* to boot unexpected images?

Well... it boots what it has sealed. But you could replace the image with a fresh one which hasn't been encrypted yet I suppose and that would boot. But you could not boot another encrypted fs. Trying to avoid image here.

And to clarify:
> Double check bios_measurements_log to ensure that the newly update shim was used for boot (https://github.com/canonical/tcglog-parser/tree/master/tcglog-dump can be used to extract checksum of the shim binary used at boot and compared to the one shipped in nullboot

> From package contents I assume you'd be checking against the checksum of /usr/lib/nullboot/shim/shimx64.efi.signed, but what checksum algorithm?

Whatever your tcglog says?

Hello Julian, or anyone else affected,

Accepted nullboot into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nullboot/0.5.0-0ubuntu0.22.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.