On Wed, Feb 9, 2022 at 1:13 AM Julian Andres Klode <julian.klode@xxxxxxxxxxxxx> wrote: > > On Tue, Feb 08, 2022 at 01:10:34PM +0000, Matthew Wilcox wrote: > > On Tue, Feb 08, 2022 at 12:01:22PM +0100, Julian Andres Klode wrote: > > > It's worth pointing out that in Ubuntu, the generated MOK key > > > is for module signing only (extended key usage 1.3.6.1.4.1.2312.16.1.2), > > > kernels signed with it will NOT be bootable. > > > > Why should these be separate keys? There's no meaningful security > > boundary between a kernel module and the ernel itself; a kernel > > modulecan, for example, write to CR3, and that's game over for > > any pretence at separation. > > I don't really _know_, but I believe the difference is that the > kernel binaries runs in boot services, and calls ExitBootServices, > whereas modules are loaded after ExitBootServices. > > But I don't know the full rationale why (a) the feature exists in > the first place and (b) why the Ubuntu security team chose to require > that constraint. > > My goal is just to make people aware of that so they can make > informed decisions :) > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en So, this is the restriction only for Ubuntu. If it works for Debian, I am fine with adding the kernel signing to scripts/package/builddeb. If it is annoying for some people, maybe we can add some switch like KDEB_SIGN_KERNEL to conditionally sign the kernel. -- Best Regards Masahiro Yamada
