why does an in-tree loadable module taint the kernel

[jim.cromie at gmail.com]

On Wed, Jun 16, 2021 at 11:50 AM <jim.cromie at gmail.com> wrote:
>
> On Wed, Jun 16, 2021 at 2:05 AM Greg KH <greg at kroah.com> wrote:
> >
> > On Tue, Jun 15, 2021 at 12:26:19PM -0600, jim.cromie at gmail.com wrote:
> > > On Tue, Jun 15, 2021 at 10:24 AM Greg KH <greg at kroah.com> wrote:
> > > >
> > > > On Tue, Jun 15, 2021 at 10:06:08AM -0600, jim.cromie at gmail.com wrote:
> > > > > On Mon, Jun 14, 2021 at 1:20 AM Greg KH <greg at kroah.com> wrote:
> > > > > >
> > > > > > On Mon, Jun 14, 2021 at 01:09:25AM -0600, jim.cromie at gmail.com wrote:
> > > > > > > serio_raw is apparently tainting the kernel when its modprobed.
> > > > > > > why ?  other modules load properly, no code changes to this module
> > > > > > >
> > > > > > > bash-5.1# dmesg | grep -i taint
> > > > > > > [    6.517150] serio_raw: module verification failed: signature and/or
> > > > > > > required key missing - tainting kernel
> > > > > >
> > > > > > You did not build this with the correct module signing key that your
> > > > > > kernel was built with.  That is what this warning is showing you, try
> > > > > > building all modules with the same key as your kernel had and you should
> > > > > > be fine.
> > > > > >
> > > > >
> > > > > OK, I understand better now -
> > > > >
> > > > > its nothing wrong with serio_raw, its just the 1st module to load,
> > > > > and warning comes just once.
> > > > > kernel/module.c
> > > > > 3962: pr_notice_once("%s: module verification failed: signature "
> > > > >
> > > > > Whats odd is that the same module has a signature when modinfo'd in
> > > > > the kernel running the laptop, but not from the same kernel running inside a VM.
> > > > > Does this constitute a bug of some sort ?
> > > >
> > > > I do not understand, what is different here and what is not working
> > > > properly?
> > > >
> > >
> > > I have built and installed 5.13-rc6 onto my laptop, Im running it now.
> > > When I modinfo something, it shows a signature
> > >
> > > [jimc at frodo ~]$ modinfo pcspkr
> > > filename:
> > > /lib/modules/5.13.0-rc6-lm1-00004-g28dc6f490a7f/kernel/drivers/input/misc/pcspkr.ko
> > > alias:          platform:pcspkr
> > > license:        GPL
> > > description:    PC Speaker beeper driver
> > > author:         Vojtech Pavlik <vojtech at ucw.cz>
> > > depends:
> > > retpoline:      Y
> > > intree:         Y
> > > name:           pcspkr
> > > vermagic:       5.13.0-rc6-lm1-00004-g28dc6f490a7f SMP mod_unload
> > > sig_id:         PKCS#7
> > > signer:         Build time autogenerated kernel key
> > > sig_key:        73:9F:4D:24:D7:05:0A:55:AE:5C:B1:F6:52:B1:BA:E0:5C:68:32:36
> > > sig_hashalgo:   sha512
> > > signature:      47:10:D7:A0:79:BE:B5:24:B1:BE:7F:53:8D:EF:4E:73:BD:39:5C:B4:
> > > CB:7A:CD:3F:C8:96:E4:7A:72:17:A0:2B:42:63:5A:0F:F6:8B:70:7E:
> > > ...
> > >
> > > when I run precisely the same kernel inside a virtme/kvm/qemu VM,
> > > the same modinfo lacks that sig stuff
> > > Note that vermagic matches exactly
> > >
> > > bash-5.1# modinfo pcspkr
> > > filename:
> > > /lib/modules/5.13.0-rc6-lm1-00004-g28dc6f490a7f/kernel/drivers/input/misc/pcspkr.ko
> > > alias:          platform:pcspkr
> > > license:        GPL
> > > description:    PC Speaker beeper driver
> > > author:         Vojtech Pavlik <vojtech at ucw.cz>
> > > depends:
> > > retpoline:      Y
> > > intree:         Y
> > > name:           pcspkr
> > > vermagic:       5.13.0-rc6-lm1-00004-g28dc6f490a7f SMP mod_unload
> > > bash-5.1#
> >
> >
> > Are you sure the modinfo you are running inside the vm knows to read the
> > signature information?  Odds are a busybox/toybox modinfo does not know
> > this type of thing.  Let me check:
> >
> > $ ./busybox modinfo visor | grep signature
> > $ modinfo visor | grep signature
> > signature:      51:F5:13:E1:F9:49:FA:20:68:45:F8:32:67:E2:4D:9C:DD:B6:55:EA:
> >
> > Yup, busybox does not know about these things.
> >
>
> that is interesting.   Its not the reason here, IIUC.
>
> Im using virtme for my VM,
> its big advantage is that it remounts the host system disks,
> so you get your whole home/host environment unchanged.
> Theres also no need to install a kernel to run it in the VM,
> I just happen to have installed the same kernel to run the whole laptop,
> (more to test my patches than to chase down this particular weirdness)
>


virtme-init: basic initialization done
virtme-init: running systemd-tmpfiles
Failed to create directory or subvolume "/var/spool/cups/tmp": Permission denied
Failed to open directory 'portables': Permission denied
Failed to open directory 'machines': Permission denied
Failed to open directory 'private': Permission denied
Failed to open directory 'private': Permission denied
systemd-tmpfile (184) used greatest stack depth: 26448 bytes left
virtme-init: starting udevd
Starting version v248.3-1.fc34

Im gonna handwave a key visibilty problem causing my wierdness