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 Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id A29E1C43217 for ; Mon, 28 Nov 2022 11:12:59 +0000 (UTC) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by mx.groups.io with SMTP id smtpd.web11.115210.1669633969161219322 for ; Mon, 28 Nov 2022 03:12:49 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=TuXp1Di0; spf=pass (domain: linaro.org, ip: 209.85.167.53, mailfrom: mikko.rapeli@linaro.org) Received: by mail-lf1-f53.google.com with SMTP id p8so16767528lfu.11 for ; Mon, 28 Nov 2022 03:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=MwmSl9z01HcAbo2g2Ayv9Jfnj8NLFTDSLUqS1CSZfzg=; b=TuXp1Di0mBvXZWMyHbUCYOPEMExtlm/owP/B2LqT+9DK8uZItJe2sOorA59BhPeIl4 KV9G5clQZhFz/Gg7xVpqTzm5IWJHdrd4mL1wcQ3C+CI4mdnQTX9Rpbee0He0erdqnVTe PdB4lVP2tfhcJ+qSXDpGly0bVYe4YJuuQXIKNIHiCHecbMG6i0uBQnqXorWEryu0QX2T K0BfriXogyFacYTjVdb7V1S0zi43R49af1OAA4xxnqnKF/hnCkAMWovXB5joA/4z4EdS pXcpmCVxuUp+lTLPpVh2mkWJHQoJt/wE5pEyAZ1hOwjVSnMdDd9Ws95es7kKTmJkgVoo gzCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=MwmSl9z01HcAbo2g2Ayv9Jfnj8NLFTDSLUqS1CSZfzg=; b=qW/E4NFoNu/UGEdhZwSE6qG7UcszFy/L6w7MhTXg2J2mdlquibit1azG6EcVb++u5v ZV6knGrDaAkHNJYuKcp9ehNLP437VVgwqCwpLICHLcGNzkpz2gHipCNEARraOmK5u6xx KbDUgYmdkeZQ0H8Kkh6TXKBdDI4EEcwFQ06yJa8M39+oz2wYY9HYrj4Uzd1sueAtbUV4 Q/9u3gVlzZdMm6DTqlcXVHIgbZlvm/c3WIwGt42lfhQ6dp8uQEzSI4lyGKy4msE338DL e6MYJ+xDE/5y3n0HGO7cKUZBcxPMqMXI0wISQipng/v80uNUMFEftQruxKZxFxc5Lvw6 dh0A== X-Gm-Message-State: ANoB5plU1FLnqA+tUsfbnrtA9cZ8p00jGTSA4iXPgEoQqOpTvic7BvEd BkayeR3cKm2EzIX0G94uN1QcHQ== X-Google-Smtp-Source: AA0mqf7Kd8zrtKXvzo1jCPkh33E+HHuQcQ8TnK4gIw47B0L5fy2AldLjzX3m2iSi8lhWSJzpRYGgOQ== X-Received: by 2002:a05:6512:1505:b0:4af:b5d0:695e with SMTP id bq5-20020a056512150500b004afb5d0695emr17497868lfb.6.1669633967331; Mon, 28 Nov 2022 03:12:47 -0800 (PST) Received: from nuoska (dsl-olubng11-54f814-94.dhcp.inet.fi. [84.248.20.94]) by smtp.gmail.com with ESMTPSA id o18-20020a05651205d200b004b4fefacd89sm1402142lfo.139.2022.11.28.03.12.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Nov 2022 03:12:46 -0800 (PST) Date: Mon, 28 Nov 2022 13:12:44 +0200 From: Mikko Rapeli To: Jack Mitchell Cc: Bruce Ashfield , openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] linux-yocto: enable strict kernel module signing by default Message-ID: References: <20221125155412.1119701-1-mikko.rapeli@linaro.org> <95775d91-4c85-2681-d902-d84e37aeef77@embed.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95775d91-4c85-2681-d902-d84e37aeef77@embed.me.uk> List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Mon, 28 Nov 2022 11:12:59 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/173905 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 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