From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6821118203682357248 X-Received: by 2002:a17:906:6856:: with SMTP id a22mr4440328ejs.115.1588191322446; Wed, 29 Apr 2020 13:15:22 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6402:1a58:: with SMTP id bf24ls283265edb.2.gmail; Wed, 29 Apr 2020 13:15:21 -0700 (PDT) X-Google-Smtp-Source: APiQypJPQ5xi7zWnRrcvdKqgof02QTOgf7ckwsvJzlzD3K9yBUcyf6/LScat1zllZK4hwoI7SuZH X-Received: by 2002:a1c:5403:: with SMTP id i3mr5436765wmb.10.1588191321616; Wed, 29 Apr 2020 13:15:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588191321; cv=none; d=google.com; s=arc-20160816; b=rWFz4yBCOBINPb7wGn8gp5+cNtUh0U2m8MP0pNRTpGIgpF826VllYO3CfFsjJTidWs Xs11HWQaWabpNx9RrwRalOtJslBIZC9W2WtQ5fCJGjWQmb7GrJUrJ9w22mS+0M+z1cor Y+GHWpTOzjU/SPUIGiYXZivMzN1R9k7nRqrPFEGeeV/JS9AnqdUWTf6Hhe1pryKhozxw Fs1SPABHHML+ZSRHinYaCgfEJEnmW6kQEMV3TKk/8Jw2os5JHoLFgVaCzgtIRx813Z+G v2PmFzXQY4qLUBEv4iNB2pKYGvnD49ilTOz2rt55sRribdwg72W0nO4mEg/FtCLepA9X ufOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=F7i7UBCRZA5BjrWOrVme1Ok1YWYVvvQHM85MCHoqqKA=; b=1CBH2sJ2Bqc3gbq1XVAK3JuB3CyAsk8hQFQc5PAVb/uDkL4rJGn8mF4MerNVqKypRz sEDBmL9fJlkmNf34X2EIs9BSqP2fcLFF3ccVOF9JyXvioJ5FOLJmV4EzFdPBsw378GlW kw65/BI68otnfhLfssg9a2gda4v8YuORDFcOjgMF0xE8WqZ0DOffoRkJVt+c53GXL17c ydEIz6u6kT6b0pTIazN+yI7ocpb4844MGV4jzJqeTE2FQcEv55+lMpd4s38RjfkSAadT 8L6hciSXp7/apHdxJA6SdJE5CXYZ8u1w4YbSDt/3gePaTlwneKlvCe2XMV5+IHb8EjB+ IIvA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id u16si434971wmd.2.2020.04.29.13.15.21 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 13:15:21 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 03TKFKJu030520 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Apr 2020 22:15:20 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.0.16]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 03TKFKl5023724; Wed, 29 Apr 2020 22:15:20 +0200 Date: Wed, 29 Apr 2020 22:15:17 +0200 From: Henning Schild To: Mustafa =?UTF-8?B?WcO8Y2Vs?= Cc: Jan Kiszka , isar-users Subject: Re: signing support for (in-tree and external) kernel modules Message-ID: <20200429221517.2187f4da@md1za8fc.ad001.siemens.net> In-Reply-To: <3a5d776b-3cce-ba0f-cf37-f4e2a0afc65a@gmail.com> References: <9a590808-34da-493f-9ea2-219d17cd87c9@googlegroups.com> <9d4818d5-e884-a600-0504-996042f31e3b@siemens.com> <3a5d776b-3cce-ba0f-cf37-f4e2a0afc65a@gmail.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: haKQjgK5mS87 Am Wed, 29 Apr 2020 20:57:39 +0200 schrieb Mustafa Y=C3=BCcel : > >> from where you got CONFIG_MODULE_SIG_FORMAT? CONFIG_MODULE_SIG is > >> the trigger to create this binary: > >> > >> scripts/Makefile:hostprogs-$(CONFIG_MODULE_SIG)+=3D sign-file > >> =20 > > > > I was looking at kernel 5.6. > > > > Then we likely need multiple condition when to run sign-file while=20 > > building an external module. > > > > And we also need some idea how to deploy the shared keys to all=20 > > recipes. If we only talk about two or three, the kernel recipe > > could carry the keys as artifacts, and other recipes would simply > > link them. But that is not really nice to maintain. We could, of > > course, package the keys into linux-headers. Downside: Someone may > > then accidentally ship them on a device. =20 >=20 > maybe we can use a separate package? e.g. kernel-module-signkeys? >=20 > normally this package will be only used for building, we can output > an error during isar build when someone installs this package to the > image (prevents "accidentally ship them on a device") >=20 > next point: can we avoid somehow with isar that this package is > showing up in some apt repo (outside isar build system)? All packages isar builds for an image show up in a repo called "isar-apt" that is strictly internal. If you choose to make use of the rebuild cache that will be another repo - "base-apt". "base-apt" can be published and used for consecutive (re-)builds. Isar does not publish anything on its own, nothing to be afraid of. Henning >=20 > On Wednesday, April 29, 2020 at 5:35:15 PM UTC+2, Jan Kiszka wrote: > >> > >> =C2=A0=C2=A0=C2=A0 On 29.04.20 15:00, yue...@gmail.com w= rote: > >> =C2=A0=C2=A0=C2=A0=C2=A0 > In tree kernel modules gets signed with the > >> CONFIG_MODULE_SIG_ALL kernel > >> =C2=A0=C2=A0=C2=A0=C2=A0 > option, but extra (resp. external) modules = not. If you > >> (resp. isar) not > >> =C2=A0=C2=A0=C2=A0=C2=A0 > provide an (external) signing key, the kern= el build=20 > >> autogenerates a > >> =C2=A0=C2=A0=C2=A0=C2=A0 > private/public key pair. It would be nice i= f the isar build=20 > >> system > >> =C2=A0=C2=A0=C2=A0=C2=A0 > provide some support for signing kernel mod= ules. > >> =C2=A0=C2=A0=C2=A0=C2=A0 > > >> =C2=A0=C2=A0=C2=A0=C2=A0 > I see currently 2 use cases: > >> =C2=A0=C2=A0=C2=A0=C2=A0 > 1) let the kernel build to autogenerate pri= vate/public key > >> for kernel > >> =C2=A0=C2=A0=C2=A0=C2=A0 > module signing and kernel-module reuse the = key for signing > >> (evt. isar > >> =C2=A0=C2=A0=C2=A0=C2=A0 > deletes the private key after image generat= ion) > >> =C2=A0=C2=A0=C2=A0=C2=A0 > 2) provide an (external) private and public= key for kernel > >> module > signing and will be used in kernel and kernel-module > >> recipes > > >> > >> =C2=A0=C2=A0=C2=A0 We likely want to go for path 2 because the first o= ption > >> prevents reproducibility. And that means we need to define a > >> channel how to provide those keys both to the kernel build as well > >> as the external module builds. > >> > >> =C2=A0=C2=A0=C2=A0 Did you happen to observe if kernel-headers will in= clude at > >> least the > >> =C2=A0=C2=A0=C2=A0 script/sign-file host tool when CONFIG_MODULE_SIG_F= ORMAT is > >> enabled? That - together with the keys - would be needed in order > >> to sign external modules already during their build. > >> > >> =C2=A0=C2=A0=C2=A0 Jan > >> > >> =C2=A0=C2=A0=C2=A0 -- =C2=A0=C2=A0=C2=A0 Siemens AG, Corporate Technol= ogy, CT RDA IOT SES-DE > >> =C2=A0=C2=A0=C2=A0 Corporate Competence Center Embedded Linux > >> > >> --=20 > >> You received this message because you are subscribed to the Google=20 > >> Groups "isar-users" group. > >> To unsubscribe from this group and stop receiving emails from it,=20 > >> send an email to isar-users+unsubscribe@googlegroups.com=20 > >> . > >> To view this discussion on the web visit=20 > >> https://groups.google.com/d/msgid/isar-users/a5a4a11a-9c3f-4367-b264-b= ba84bd2727c%40googlegroups.com=20 > >> .=20 > >> =20 > > =20 >=20