Github messages for voidlinux
 help / color / mirror / Atom feed
* [ISSUE] [RFC] signed kernel modules
@ 2021-01-07 10:29 dkwo
  2021-01-07 14:29 ` ericonr
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: dkwo @ 2021-01-07 10:29 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

New issue by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/27736

Description:
While trying to build Arch Linux kernel in Void using `xbps-src`, I noticed they use kernel module signature, see e.g. `CONFIG_MODULE_SIG=y` in [their config](https://github.com/archlinux/svntogit-packages/blob/packages/linux/trunk/config) while void does not, see also arch wiki [page](https://wiki.archlinux.org/index.php/Signed_kernel_modules).

While this is not an issue, I wonder whether it would be useful and possible to have this faature in Void Linux kernel as well.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC] signed kernel modules
  2021-01-07 10:29 [ISSUE] [RFC] signed kernel modules dkwo
@ 2021-01-07 14:29 ` ericonr
  2021-01-07 20:26 ` ahesford
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: ericonr @ 2021-01-07 14:29 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/27736#issuecomment-756150464

Comment:
I don't see what advantage this brings, since an attacker who has access to the kernel modules could just as well change programs, libraries, or possibly even the kernel itself, making any signing moot.

Furthermore, given that a lot of people might end up requiring one DKMS module or another (nvidia, zfs, ...), this would only be useful if they self built their own kernel with a custom config pointing to the additional key. And then they'd have to set up the whole infrastructure around actually signing the modules and such, plus somehow protect the key adequately.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC] signed kernel modules
  2021-01-07 10:29 [ISSUE] [RFC] signed kernel modules dkwo
  2021-01-07 14:29 ` ericonr
@ 2021-01-07 20:26 ` ahesford
  2021-01-14  6:58 ` fosslinux
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: ahesford @ 2021-01-07 20:26 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/27736#issuecomment-756363589

Comment:
DKMS is a fundamental part of the distribution of out-of-tree kernel modules in Void. As @ericonr notes, the fact that the kernel must be built to include public counterparts of all keys used to sign modules either forces us to distribute the private keys (which defeats the whole purpose of signing) or to shift the burden of custom compilation from those who want signed modules to those (almost certainly far greater in number) who use out-of-tree modules.

This seems like a bad trade.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC] signed kernel modules
  2021-01-07 10:29 [ISSUE] [RFC] signed kernel modules dkwo
  2021-01-07 14:29 ` ericonr
  2021-01-07 20:26 ` ahesford
@ 2021-01-14  6:58 ` fosslinux
  2021-01-16 15:46 ` dkwo
  2021-01-16 15:46 ` [ISSUE] [CLOSED] " dkwo
  4 siblings, 0 replies; 6+ messages in thread
From: fosslinux @ 2021-01-14  6:58 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

New comment by fosslinux on void-packages repository

https://github.com/void-linux/void-packages/issues/27736#issuecomment-759969571

Comment:
Furthermore, we can't distribute many of these these even if we did build and sign them.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC] signed kernel modules
  2021-01-07 10:29 [ISSUE] [RFC] signed kernel modules dkwo
                   ` (2 preceding siblings ...)
  2021-01-14  6:58 ` fosslinux
@ 2021-01-16 15:46 ` dkwo
  2021-01-16 15:46 ` [ISSUE] [CLOSED] " dkwo
  4 siblings, 0 replies; 6+ messages in thread
From: dkwo @ 2021-01-16 15:46 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/27736#issuecomment-761584716

Comment:
I see, thanks for clarifying.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [ISSUE] [CLOSED] [RFC] signed kernel modules
  2021-01-07 10:29 [ISSUE] [RFC] signed kernel modules dkwo
                   ` (3 preceding siblings ...)
  2021-01-16 15:46 ` dkwo
@ 2021-01-16 15:46 ` dkwo
  4 siblings, 0 replies; 6+ messages in thread
From: dkwo @ 2021-01-16 15:46 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

Closed issue by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/27736

Description:
While trying to build Arch Linux kernel in Void using `xbps-src`, I noticed they use kernel module signature, see e.g. `CONFIG_MODULE_SIG=y` in their [config](https://github.com/archlinux/svntogit-packages/blob/packages/linux/trunk/config), while Void does not, see also Arch wiki [page](https://wiki.archlinux.org/index.php/Signed_kernel_modules).

While this is not an issue, I wonder whether it would be useful to have this feature in Void Linux kernel as well.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-01-16 15:46 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-07 10:29 [ISSUE] [RFC] signed kernel modules dkwo
2021-01-07 14:29 ` ericonr
2021-01-07 20:26 ` ahesford
2021-01-14  6:58 ` fosslinux
2021-01-16 15:46 ` dkwo
2021-01-16 15:46 ` [ISSUE] [CLOSED] " dkwo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).