Re: [OE-core] [PATCH] linux-yocto: enable strict kernel module signing by default

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

On Sun, Nov 27, 2022 at 06:47:30PM +0000, Jack Mitchell wrote:
> On 27/11/2022 03:34, Bruce Ashfield wrote:
> > On Fri, Nov 25, 2022 at 11:11 AM Jack Mitchell <ml@embed.me.uk> wrote:
> > > 
> > > On 25/11/2022 15:54, Mikko Rapeli wrote:
> > > > It's a good default and used in many Linux distributions.
> > > > Did not test out of tree modules if they do correct things but
> > > > any such failures should be fixed.
> > > > 
> > > > One way to verify that kernel module signing also works:
> > > > 
> > > > root@qemux86-64:~# dmesg|grep X.509
> > > > [    1.298936] Loading compiled-in X.509 certificates
> > > > [    1.328280] Loaded X.509 cert 'Build time autogenerated kernel key: ee1bed6d845358744c764683bf73b4404cc79287'
> > > > 
> > > > These logs in dmesg show that signing in kernel is enabled and
> > > > key is found. Then if any kernel modules load, they were
> > > > signed correctly. Additionally modinfo tool from kmod shows kernel module
> > > > signing details:
> > > 
> > > Hi Mikko,
> > > 
> > > Do the kernel modules get properly stripped, last time I was looking at
> > > this it was skipped when signed and as such root filesystem sizes
> > > ballooned with signed modules.
> > 
> > oe package.py still does skip stripping for signed modules.
> > 
> > I'm sure it is fixable, but we need someone to step up and have a closer look.
> > 
> > Richard can probably comment better than I can, but there's a variety
> > of use cases (from SDKs, to debug, to SBOM, etc) that all need to deal
> > with whether binaries are stripped and be able to find the
> > non-stripped executables in order to work properly.
> > 
> > So to answer the follow up suggestion of using the kernel's module
> > strip directly .. it also might be feasible, but we need to make sure
> > that all the other uses cases still work. My preference is to do the
> > work in package.py, so that we don't have to worry about the kernel
> > provider and any additional features have code in the same place as a
> > baseline.
> > 
> 
> I agree, if the kernel has the right arguments available for properly
> stripping the modules without stripping the signed portion then we can set
> those args manually rather than skipping the strip all together I believe.
> 
> I also had the same thought with having the kernel do it as I don't know
> where the stripped information goes and how that would then make it into
> debug packages.

https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html#signed-modules-and-stripping

"Signed modules are BRITTLE as the signature is outside of the defined
ELF container. Thus they MAY NOT be stripped once the signature is
computed and attached. Note the entire module is the signed payload,
including any and all debug information present at the time of signing."

linux/scripts/Makefile.modinst does in "make modules_install":

...
$(dst)/%.ko: $(extmod_prefix)%.ko FORCE
        $(call cmd,install)
        $(call cmd,strip)
        $(call cmd,sign)
...

Thus I don't think signed kernel modules can ever be stripped by
package.py or package.bbclass. It sounds like only option is to install
modules without stripping and signing to debug packages and then install
them stripped with and signed to real binary packages.

Cheers,

-Mikko