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

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

[yuecelm]

[-- Attachment #1.1: Type: text/plain, Size: 683 bytes --]

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



[-- Attachment #1.2: Type: text/html, Size: 772 bytes --]

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

[Jan Kiszka]

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

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

[Mustafa Yücel]

[-- Attachment #1.1: Type: text/plain, Size: 2199 bytes --]

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

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 
>

[-- Attachment #1.2: Type: text/html, Size: 2846 bytes --]

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

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

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

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

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


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

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

[Henning Schild]

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

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

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

[Mustafa Yücel]

[-- Attachment #1.1: Type: text/plain, Size: 2035 bytes --]


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


[-- Attachment #1.2: Type: text/html, Size: 2551 bytes --]

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

[Henning Schild]

Am Wed, 29 Apr 2020 14:04:38 -0700 (PDT)
schrieb Mustafa Yücel <yuecelm@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. 
> >  
> 
> 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).

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