From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6821118203682357248 X-Received: by 2002:a19:5510:: with SMTP id n16mr23067417lfe.58.1588174515075; Wed, 29 Apr 2020 08:35:15 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:55ba:: with SMTP id y26ls6144868lfg.11.gmail; Wed, 29 Apr 2020 08:35:14 -0700 (PDT) X-Google-Smtp-Source: APiQypKblk97M7MUWghwQcSBfzsjacmMF8YokZJLVPOJNOVKrd8AewMrxnUpv+N/8sm4PkxNcFWK X-Received: by 2002:a19:4883:: with SMTP id v125mr1825725lfa.95.1588174514228; Wed, 29 Apr 2020 08:35:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588174514; cv=none; d=google.com; s=arc-20160816; b=BHNLAMDdaG11g1inv6hcydjEWlBg5a8GRBUO8q2md3il6+GSvvOxZ3Vg6IGPUcAQOJ 7Ldw7g2N0owGyRzVuXxv53uH0aXOzmvyIOwLkmr9Wzu7EjSGnObcm7fq7YkAVK/BZ2S5 svfgfQi9Ko49J/oU0pVLR/v2eXKOweAJO/WKCP9+IyHbpTzVSIvl1xhTkH00T/FrQq0h KBIVYQW/vHS/glTerFsItUfeSeiNvdmsF4dNyPPBoOx0E7RoIbhWv/rXXZRDoe5GJgkB eaVt3ERnF7nl/DY6/E02PIFzNP/jKdl4KpTg+1aVf+/saAFgLzhbG5lek6nkGWe+Tt6V +Idg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=1Sn9gW9n8Ms1jYsrYLF+JzLdq6udAHwbh/k7S2tP6Xo=; b=oRbZY4uzEyW1/KM4F03gXRzndBMTqvOdavBSKRiHi3h1H9uhLLV9ZnI9/HaDP9bjSm WkM8/V6xO5Oe6s/QwSZ4gqGstfYgbAfhaQPTSHfhC4DIFxWLrGfVmx0nuZT2sd7nIAY/ NC54lqrZvsSPaDgimmfH12jtdX1kNaswQH7/VZMtjcSi9DHweccjObbYJ8RzTwT+1Nwu +OQ4PZCO1GuPnChh3nhf6yGvnHk51gU7PHh1SeRqI0fqC4+c2y/LPGCmV3YmyY6WcP2K QBi8kxIwPYh8LX3u28SCY2XhbRyMHH28h4cMN9u0Jl15FVSiGjs1TWBxZwd9oQk4AiV4 lTmA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id a21si193004lfr.4.2020.04.29.08.35.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 08:35:14 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@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 goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 03TFZCsn011727 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Apr 2020 17:35:12 +0200 Received: from [167.87.241.229] ([167.87.241.229]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 03TFZCkm007952; Wed, 29 Apr 2020 17:35:12 +0200 Subject: Re: signing support for (in-tree and external) kernel modules To: yuecelm@gmail.com, isar-users References: <9a590808-34da-493f-9ea2-219d17cd87c9@googlegroups.com> From: Jan Kiszka Message-ID: Date: Wed, 29 Apr 2020 17:35:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <9a590808-34da-493f-9ea2-219d17cd87c9@googlegroups.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: 14CjEFOK8Q3T On 29.04.20 15:00, yuecelm@gmail.com wrote: > In tree kernel modules gets signed with the CONFIG_MODULE_SIG_ALL kernel > option, but extra (resp. external) modules not. If you (resp. isar) not > provide an (external) signing key, the kernel build autogenerates a > private/public key pair. It would be nice if the isar build system > provide some support for signing kernel modules. > > I see currently 2 use cases: > 1) let the kernel build to autogenerate private/public key for kernel > module signing and kernel-module reuse the key for signing (evt. isar > deletes the private key after image generation) > 2) provide an (external) private and public key for kernel module > signing and will be used in kernel and kernel-module recipes > We likely want to go for path 2 because the first option 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. Did you happen to observe if kernel-headers will include at least the script/sign-file host tool when CONFIG_MODULE_SIG_FORMAT is enabled? That - together with the keys - would be needed in order to sign external modules already during their build. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux