On Sat, Dec 10, 2022 at 02:27:12PM +0100, Bastian Blank wrote: > Hi > > Our documented, I think, policy is, that we don't support loading new > modules into an old kernel within the same ABI. This forces a reboot > after kernel installation. > > However in a lot of cases this just worked. You could update the kernel > package and continue loading most modules. > > Now we have BTF support enabled, which trashes this compatibility > mostly, as it requires a way more strict match between kernel image and > modules. > > We need to fix that somehow. Options are as far as I see > - remove BTF from modules, > - allow to load modules even on BTF mismatch, or > - reinforce that a user can't do that. > > If we go with the last option we would have also some direct advantages. > We could stop signing modules with the secure boot key, but use a > temporary key. This would for a system with signature checking enabled > effectively trash all possibilities to load modules for a different > kernel build. > > This would do directly for use: > - A way faster build, as we don't longer require multi-10k signatures, > but only a handfull, from the HSM. > - We might be forced by shim/UEFI to support SBAT if we load secure boot > signed stuff. If we just need to revoke the complete kernel, SBAT on > the kernel itself is enough. > - We can do pre-built initramfs and unified image without two rounds in > the signing service. > - We fix the current signatures without certificate chain, but which are > still chained to the Debian secure boot CA. (sign-file simply can't > handle cert chains, while the kernel itself can check them on loading.) > > What should we do? +1 on using the ephemeral key from me, those advantages seem to outweight the drawbacks. It should be possible, in theory, to teach diffoscope to ignore the embedded ephemeral public key in the kernel image when comparing builds? -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part