signing support for (in-tree and external) kernel modules

[yue...@gmail.com]

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

[Jan Kiszka]

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

[Mustafa Yücel]

I checked again, sign-file is included in linux-headers package:

~myproject/out/build/tmp/deploy/isar-apt/apt/debian-buster/pool/main/l/linux-cip$ dpkg -c linux-headers-cip_4.19.113-cip23+r0_amd64.deb | grep sign-file

-rw-r--r-- root/root      7047 2020-04-29 16:56 ./usr/src/linux-headers-4.19.113-cip23/scripts/.sign-file.cmd

-rwxr-xr-x root/root     14624 2020-04-29 16:56 ./usr/src/linux-headers-4.19.113-cip23/scripts/sign-file

-rw-r--r-- root/root      9994 2020-03-28 01:06 ./usr/src/linux-headers-4.19.113-cip23/scripts/sign-file.c

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

Musti

[Jan Kiszka]

On 29.04.20 18:51, Mustafa Yücel wrote:
> I checked again, sign-file is included in linux-headers package:
>
> ~myproject/out/build/tmp/deploy/isar-apt/apt/debian-buster/pool/main/l/linux-cip$
> dpkg -c linux-headers-cip_4.19.113-cip23+r0_amd64.deb | grep sign-file
> -rw-r--r-- root/root      7047 2020-04-29 16:56
> ./usr/src/linux-headers-4.19.113-cip23/scripts/.sign-file.cmd
> -rwxr-xr-x root/root     14624 2020-04-29 16:56
> ./usr/src/linux-headers-4.19.113-cip23/scripts/sign-file
> -rw-r--r-- root/root      9994 2020-03-28 01:06
> ./usr/src/linux-headers-4.19.113-cip23/scripts/sign-file.c
>

OK, that's good.

> 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.

Jan

> Musti
>
> On Wednesday, April 29, 2020 at 5:35:15 PM UTC+2, Jan Kiszka wrote:
>

> --
> 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+...@googlegroups.com
> <mailto:isar-users+...@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>.

[Mustafa Yücel]

>> 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)?

[Henning Schild]

Am Wed, 29 Apr 2020 20:57:39 +0200
schrieb Mustafa Yücel <yue...@gmail.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)?

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

[Mustafa Yücel]

> >> 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)?

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.

ok my misunderstanding, because "isar-apt" resides in the deploy subdirectory, I was assuming it may get published at some point (openembedded/poky had also an ipk subdirectory in deploy which could serve as an external ipk repo).

means this "base-apt" gets only generated when I was using "-c cache_base_repo"? about this directory I am not afraid, it contains no self-built packages.

kernel-headers-cip resides in "isar-apt", so I was more worried about this apt repo.

[Henning Schild]

Am Wed, 29 Apr 2020 14:04:38 -0700 (PDT)
schrieb Mustafa Yücel <yue...@gmail.com>:

Well you can still publish it and "bootstrap" a debian out of it,
together with base-apt. Let us just say nothing is ever published
without you knowing it.

Some people abuse Isar as a build system for debian packages only, they
never even generate an image and they might copy "isar-apt" around and
expect it to be in deploy.
I think that is not "abuse" but in fact a really cool feature that
still needs more users and documentation ;).

> means this "base-apt" gets only generated when I was using "-c
> cache_base_repo"? about this directory I am not afraid, it contains
> no self-built packages.

That changed between master and next. It used to be an explicit step.
Now this happens along-side and serves as a download-cache for
everything debian fetches.

> kernel-headers-cip resides in "isar-apt", so I was more worried about
> this apt repo.

This contains every debian package we build in isar. The other one is a
partial mirror of upstream.

Henning