From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53EF9C48BE5 for ; Wed, 16 Jun 2021 08:06:13 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9ADC76054E for ; Wed, 16 Jun 2021 08:06:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9ADC76054E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kroah.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1ltQYP-0002G5-9c; Wed, 16 Jun 2021 04:05:41 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ltQYL-0002Ed-Kt for kernelnewbies@kernelnewbies.org; Wed, 16 Jun 2021 04:05:37 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 96A795C00E0; Wed, 16 Jun 2021 04:05:33 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 16 Jun 2021 04:05:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=zrrV6LiFZTTwquhSk1TvT7EONc2 vHKdcuzSSanG0JHg=; b=kPf5zr0gDIQiqjUTbLMH+reOziOa30ucpqlpwu+gugt Z3dftQXLXj8BWhhFTNvMh6oQ7NVeEvLUmBDSoQppk90ad6dzquyKE1i/p/shFlc5 PkaDM4z/7QMBCqTWqtU4zFFa6YDUOLrYw4FrYiSJCJO8g4IYN6xuiOCFcKwYL/VQ Zd7GkYf+suQjDXfuktxEelxIS9fxQONbLjgrXbc5S7m31EHH5IOfN52O4qkxjiJu oIJ99uHu+UqLAecs7mQ2AV4Sj8rlwG7PYLhF9NNS8Xn6IBiYHhW0H3XAEpH3qKog vY1nywjSEJjC/54cxNwq7F/AO37BAJGpvnZ1RdvdydQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=zrrV6L iFZTTwquhSk1TvT7EONc2vHKdcuzSSanG0JHg=; b=p+o/7vH1R2JbGsMM0Rdqub GPeJweRT4Apn3e2BezRKA8f+0rR1ZlNOFzgLqKdmB3oQrLF3janrR1Ec0JmE2PHL amVTRNkIyiThCgdbbnY31pzsZxrt9LxdPwCvKZEOm42PiNk1G2cZa2YtRwkYTENL rTbM8tQTmf+vkMH6Doyqe8OfUoYvkf9hFmFfT+29L9SwekkVCttu6hodaXq5tDJR EciuLg3puCqEv0tAc8Xk64Pi6Y07XtCH5k/3gcFgug+hIP/EZpBXOBFZyyxZWEhg ytAUMaivzaDFw54E1Il2KcYi+9DozVP9LyjT4X3SswAZL6eCiLaPRfgO9BV6b9/Q == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvlecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttdortddttd dvnecuhfhrohhmpefirhgvghcumffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucgg tffrrghtthgvrhhnpeevhefgjeeitdfffefhvdegleeigeejgeeiffekieffjeeflefhie egtefhudejueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehgrhgvgheskhhrohgrhhdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Jun 2021 04:05:32 -0400 (EDT) Date: Wed, 16 Jun 2021 10:05:30 +0200 From: Greg KH To: jim.cromie@gmail.com Subject: Re: why does an in-tree loadable module taint the kernel Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kernelnewbies X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Tue, Jun 15, 2021 at 12:26:19PM -0600, jim.cromie@gmail.com wrote: > On Tue, Jun 15, 2021 at 10:24 AM Greg KH wrote: > > > > On Tue, Jun 15, 2021 at 10:06:08AM -0600, jim.cromie@gmail.com wrote: > > > On Mon, Jun 14, 2021 at 1:20 AM Greg KH wrote: > > > > > > > > On Mon, Jun 14, 2021 at 01:09:25AM -0600, jim.cromie@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@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 > 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 > 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. Is the md5sum the same for these modules? > > If you rebuild modules for a kernel without having the key, yes, you > > will get this warning. You have to have the same key here. > > heres how Ive configured: > - copy distro .config from /boot (Fedora) > - make localmodconfig (to drop building parts I wont need) > - virtme-configkernel --update (to get support for 9P, virtio etc to > mount host disks) > > all the SECURITY stuff came from the distro config, > I havent yet tried to unconfigure it. > > I havent done anything specific with keys, I dont know why whatever > key is involved > is not available for both scenarios. > here's the relevant (I hope) config items: Look at the CONFIG_MODULE_SIG* items, that's the relevant ones. Here's what I use in my custom kernels for my systems: $ zcat /proc/config.gz | grep MODULE_SIG CONFIG_MODULE_SIG_FORMAT=y CONFIG_MODULE_SIG=y CONFIG_MODULE_SIG_FORCE=y CONFIG_MODULE_SIG_ALL=y # CONFIG_MODULE_SIG_SHA1 is not set # CONFIG_MODULE_SIG_SHA224 is not set # CONFIG_MODULE_SIG_SHA256 is not set # CONFIG_MODULE_SIG_SHA384 is not set CONFIG_MODULE_SIG_SHA512=y CONFIG_MODULE_SIG_HASH="sha512" CONFIG_MODULE_SIG_KEY="certs/signing_key.pem" Watch out when using MODULE_SIG_FORCE, that requires you to sign all modules. If you want to keep a keyset around when building custom kernels, that's fine, but I delete mine instantly after signing the kernel so that it's impossible (well harder) to load modules that were not signed as part of my local build process. I do that by doing: rm certs/signing_key.* after installing the kernel. Hope this helps, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies