From: "Mustafa Yücel" <yuecelm@gmail.com>
To: Jan Kiszka <jan.kiszka@siemens.com>,
isar-users <isar-users@googlegroups.com>
Subject: Re: signing support for (in-tree and external) kernel modules
Date: Wed, 29 Apr 2020 20:57:39 +0200 [thread overview]
Message-ID: <3a5d776b-3cce-ba0f-cf37-f4e2a0afc65a@gmail.com> (raw)
In-Reply-To: <9d4818d5-e884-a600-0504-996042f31e3b@siemens.com>
>> from where you got CONFIG_MODULE_SIG_FORMAT? CONFIG_MODULE_SIG is the
>> trigger to create this binary:
>>
>> scripts/Makefile:hostprogs-$(CONFIG_MODULE_SIG)+= sign-file
>>
>
> I was looking at kernel 5.6.
>
> Then we likely need multiple condition when to run sign-file while
> building an external module.
>
> And we also need some idea how to deploy the shared keys to all
> 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.
maybe we can use a separate package? e.g. kernel-module-signkeys?
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")
next point: can we avoid somehow with isar that this package is showing
up in some apt repo (outside isar build system)?
On Wednesday, April 29, 2020 at 5:35:15 PM UTC+2, Jan Kiszka wrote:
>>
>> On 29.04.20 15:00, yue...@gmail.com <javascript:> 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
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "isar-users" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to isar-users+unsubscribe@googlegroups.com
>> <mailto:isar-users+unsubscribe@googlegroups.com>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/isar-users/a5a4a11a-9c3f-4367-b264-bba84bd2727c%40googlegroups.com
>> <https://groups.google.com/d/msgid/isar-users/a5a4a11a-9c3f-4367-b264-bba84bd2727c%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>
>
next prev parent reply other threads:[~2020-04-29 18:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 13:00 yuecelm
2020-04-29 15:35 ` Jan Kiszka
2020-04-29 16:51 ` Mustafa Yücel
2020-04-29 17:38 ` Jan Kiszka
2020-04-29 18:57 ` Mustafa Yücel [this message]
2020-04-29 20:15 ` Henning Schild
2020-04-29 21:04 ` Mustafa Yücel
2020-04-30 10:42 ` Henning Schild
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a5d776b-3cce-ba0f-cf37-f4e2a0afc65a@gmail.com \
--to=yuecelm@gmail.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox