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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2045552 Title: nullboot 0.5.0: shim 15.7-0ubuntu1 update To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nullboot/+bug/2045552/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
