Re: kmods and Fedora

[Frank Ch. Eigler]

Bastien Nocera  writes:

>> > If you are creating a cert to sign the out-of-tree modules and expect
>> > it to be accepted by the kernel, it cannot be ephemeral.  A user would
>> > need someway to import it into their kernel or have it passed from
>> > grub.  [...]
>> 
>> That just proves that Restricted Boot and especially our implementation of
>> it (requiring kernel modules to be signed) is a very bad thing.
>
> How do you expect to be able to ensure that the kernel only loads "known good"
> modules if you can insert random modules that might subvert SecureBoot and
> all that it allows to secure?

For systemtap on secureboot systems, we rely on Machine Owner Keys.
These keys are generated once.  The public half is put into UEFI via
mokutil and a reboot.  The private half held at another trusted
machine.  Then that machine can sign modules with the MOK key and have
normal Fedora kernels/shims accept them.

- FChE
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Andrew Lutomirski]

On Feb 22, 2016 6:33 AM, "Bastien Nocera"  wrote:
>
>
>
> - Original Message -
> > Josh Boyer wrote:
> > > If you are creating a cert to sign the out-of-tree modules and expect
> > > it to be accepted by the kernel, it cannot be ephemeral.  A user would
> > > need someway to import it into their kernel or have it passed from
> > > grub.  The only way to do so is to have it embedded in shim or the
> > > kernel during the build of those binaries.  I do not foresee Fedora
> > > creating yet another persistent key to sign things with, which means
> > > you would need another tool that can use the existing key in the
> > > kernel builders.
> >
> > That just proves that Restricted Boot and especially our implementation
of
> > it (requiring kernel modules to be signed) is a very bad thing.
>
> How do you expect to be able to ensure that the kernel only loads "known
good"
> modules if you can insert random modules that might subvert SecureBoot and
> all that it allows to secure?

I still find it confusing that Fedora will let you do anything you want in
userspace but will not let you load your own kernel module.  This may or
may not be required by MS and/or UEFI Forum rules (I honestly have no idea,
and I recall that jejb was going to discuss this at some point but I don't
think it ever happened).  Regardless, I don't see a credible
widely-applicable threat model under which this is useful.

Would Fedora be permitted to simply drop the signed module requirement?

ISTM a genuinely useful approach might be to forcibly extend some PCR and
maybe blank out some keyrings if an unsigned module is loaded.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Bastien Nocera]

- Original Message -
> Josh Boyer wrote:
> > If you are creating a cert to sign the out-of-tree modules and expect
> > it to be accepted by the kernel, it cannot be ephemeral.  A user would
> > need someway to import it into their kernel or have it passed from
> > grub.  The only way to do so is to have it embedded in shim or the
> > kernel during the build of those binaries.  I do not foresee Fedora
> > creating yet another persistent key to sign things with, which means
> > you would need another tool that can use the existing key in the
> > kernel builders.
> 
> That just proves that Restricted Boot and especially our implementation of
> it (requiring kernel modules to be signed) is a very bad thing.

How do you expect to be able to ensure that the kernel only loads "known good"
modules if you can insert random modules that might subvert SecureBoot and
all that it allows to secure?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Kevin Kofler]

Josh Boyer wrote:
> If you are creating a cert to sign the out-of-tree modules and expect
> it to be accepted by the kernel, it cannot be ephemeral.  A user would
> need someway to import it into their kernel or have it passed from
> grub.  The only way to do so is to have it embedded in shim or the
> kernel during the build of those binaries.  I do not foresee Fedora
> creating yet another persistent key to sign things with, which means
> you would need another tool that can use the existing key in the
> kernel builders.

That just proves that Restricted Boot and especially our implementation of 
it (requiring kernel modules to be signed) is a very bad thing.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Kevin Kofler]

Josh Boyer wrote:
> This is a major part of why we disallowed them in the past and that
> was before any of the existing kernel team members were on the team
> yet.  Our stance has not changed over time or with the introduction of
> new team members.

And I still believe that it is wrong to reject modules under licenses 
compatible with the kernel's GPLv2 license just because they are released 
separately. We allow out-of-tree plugins for other packages too. (Imagine if 
all Python modules were required to be built as part of the main Python 
SRPM.)

That said, for the particular case of the ZFS module that originated this 
thread, licensing issues preclude shipping it anyway, so in that case, the 
discussion is moot.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 14.01.2016 um 16:56 schrieb Neal Gompa:

I've recently been wondering why we haven't allowed kernel module
packages in Fedora since Fedora 8. I've tried searching through our
wiki and the mailing list, but I haven't come up with any concrete
reasons for why we disallow them.

If it is perhaps the issue of keeping things in sync with kernels we
provide (that is, maintainers didn't/couldn't keep up with new kernels
being pushed during a release cycle), then I think the situation has
changed.

We have two tools that can help us in this regard: akmod and Koschei,
both came after our policy change to disallow kernel modules.


akmod is a dirty hack and fails often enough for rpmfusion stuff

additionally you should *never* need GCC and devel packages installed on 
a normal enduser system for a ton of reasons




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 14.01.2016 um 18:05 schrieb Neal Gompa:

On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald  wrote:


Am 14.01.2016 um 16:56 schrieb Neal Gompa:

We have two tools that can help us in this regard: akmod and Koschei,
both came after our policy change to disallow kernel modules.


akmod is a dirty hack and fails often enough for rpmfusion stuff

additionally you should *never* need GCC and devel packages installed on a
normal enduser system for a ton of reasons


The most common reason that akmod fails is the same reason dkms often
fails: the correct kernel-devel isn't installed. For whatever reason,
there's no logic in DNF to handle this case properly. Of course, to be
fair, this problem happens in Yum too, but since Yum isn't actively
supported in Fedora anymore, it's not as much of a concern.


no, the most common reason is that whatever should don't build aganinst 
a recent fedora kernel




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Nicolas Chauvet]

2016-01-14 18:05 GMT+01:00 Neal Gompa :

> On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald 
> wrote:
> >
> > Am 14.01.2016 um 16:56 schrieb Neal Gompa:
> >>
> >> I've recently been wondering why we haven't allowed kernel module
> >> packages in Fedora since Fedora 8. I've tried searching through our
> >> wiki and the mailing list, but I haven't come up with any concrete
> >> reasons for why we disallow them.
> >>
> >> If it is perhaps the issue of keeping things in sync with kernels we
> >> provide (that is, maintainers didn't/couldn't keep up with new kernels
> >> being pushed during a release cycle), then I think the situation has
> >> changed.
> >>
> >> We have two tools that can help us in this regard: akmod and Koschei,
> >> both came after our policy change to disallow kernel modules.
> >
> >
> > akmod is a dirty hack and fails often enough for rpmfusion stuff
> >
> > additionally you should *never* need GCC and devel packages installed on
> a
> > normal enduser system for a ton of reasons
>
> The most common reason that akmod fails is the same reason dkms often
> fails: the correct kernel-devel isn't installed. For whatever reason,
> there's no logic in DNF to handle this case properly. Of course, to be
> fair, this problem happens in Yum too, but since Yum isn't actively
> supported in Fedora anymore, it's not as much of a concern.
>

Maybe this particular concern can be addressed in DNF with a plugin ?

The way I've previously worded a possible solution is to have a yum/dnf
plugin for akmod.
This plugin will select the appropriate kernel-devel based on the kernel
that is currently installed.
( https://bugzilla.rpmfusion.org/show_bug.cgi?id=3386 ).

But this dnf plugin can be useful by default in fedora, since the
kernel-devel issue can rise when one user install a particular development
group where kernel-devel is needed.
(user typically ends with kernel-debug-devel instead of the one for their
kernel variant that can also be kernel-lpae or else).

-
Nicolas
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Neal Gompa]

On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald  wrote:
>
> Am 14.01.2016 um 16:56 schrieb Neal Gompa:
>>
>> I've recently been wondering why we haven't allowed kernel module
>> packages in Fedora since Fedora 8. I've tried searching through our
>> wiki and the mailing list, but I haven't come up with any concrete
>> reasons for why we disallow them.
>>
>> If it is perhaps the issue of keeping things in sync with kernels we
>> provide (that is, maintainers didn't/couldn't keep up with new kernels
>> being pushed during a release cycle), then I think the situation has
>> changed.
>>
>> We have two tools that can help us in this regard: akmod and Koschei,
>> both came after our policy change to disallow kernel modules.
>
>
> akmod is a dirty hack and fails often enough for rpmfusion stuff
>
> additionally you should *never* need GCC and devel packages installed on a
> normal enduser system for a ton of reasons

The most common reason that akmod fails is the same reason dkms often
fails: the correct kernel-devel isn't installed. For whatever reason,
there's no logic in DNF to handle this case properly. Of course, to be
fair, this problem happens in Yum too, but since Yum isn't actively
supported in Fedora anymore, it's not as much of a concern.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Ian Malone]

On 14 January 2016 at 19:29, Andrew Lutomirski  wrote:
>
> On Jan 14, 2016 9:34 AM, "Nicolas Chauvet"  wrote:
>>
>> 2016-01-14 18:05 GMT+01:00 Neal Gompa :
>>>
>>> On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald 
>>> wrote:
>>> >
>>> > Am 14.01.2016 um 16:56 schrieb Neal Gompa:
>>> >>
>>> >> I've recently been wondering why we haven't allowed kernel module
>>> >> packages in Fedora since Fedora 8. I've tried searching through our
>>> >> wiki and the mailing list, but I haven't come up with any concrete
>>> >> reasons for why we disallow them.
>>> >>
>>> >> If it is perhaps the issue of keeping things in sync with kernels we
>>> >> provide (that is, maintainers didn't/couldn't keep up with new kernels
>>> >> being pushed during a release cycle), then I think the situation has
>>> >> changed.
>>> >>
>>> >> We have two tools that can help us in this regard: akmod and Koschei,
>>> >> both came after our policy change to disallow kernel modules.
>>> >
>>> >
>>> > akmod is a dirty hack and fails often enough for rpmfusion stuff
>>> >
>>> > additionally you should *never* need GCC and devel packages installed
>>> > on a
>>> > normal enduser system for a ton of reasons
>>>
>>> The most common reason that akmod fails is the same reason dkms often
>>> fails: the correct kernel-devel isn't installed. For whatever reason,
>>> there's no logic in DNF to handle this case properly. Of course, to be
>>> fair, this problem happens in Yum too, but since Yum isn't actively
>>> supported in Fedora anymore, it's not as much of a concern.
>>
>>
>> Maybe this particular concern can be addressed in DNF with a plugin ?
>>
>> The way I've previously worded a possible solution is to have a yum/dnf
>> plugin for akmod.
>> This plugin will select the appropriate kernel-devel based on the kernel
>> that is currently installed.
>> ( https://bugzilla.rpmfusion.org/show_bug.cgi?id=3386 ).
>>
>> But this dnf plugin can be useful by default in fedora, since the
>> kernel-devel issue can rise when one user install a particular development
>> group where kernel-devel is needed.
>> (user typically ends with kernel-debug-devel instead of the one for their
>> kernel variant that can also be kernel-lpae or else).
>
> There are two issues here, I think:
>
> 1. Is Fedora okay, in principle, with shipping out-of-tree modules?
>
> I won't comment on #1.  (I also won't comment on Secure Boot issues.)
>
> 2. Assuming that shipping an out-of-tree module is okay, is akmod a good
> mechanism?
>
> I would argue strongly that akmod is *not* a good mechanism.
>
> Clearly any end-user-box-builds-modules system needs the package manager to
> pull in the right devel stuff.  This is clearly a solvable problem.
>
> But akmod in particular has a really nasty built-in assumption: it assumes
> that the running kernel came from an RPM at all.  For people who write
> kernels, this utterly sucks.  For example, I have no intention of rpm-ifying
> every test kernel I build for my laptop.  I install them according to the
> standard arrangement, which "make install" can do just fine.  There are
> symlinks in standard places that a kmod build system could find.  Akmod
> can't do that.  Akmod also can't figure out what to make its freshly-built
> rpm depend on because there is no correct answer.
>
> I think that, if Fedora were to adopt a kmod build system: it should have a
> QA requirement: if you "make modules_install && make install" a kernel and
> boot into it, the kmod system should work.  Akmod fails utterly in that
> scenario.
>

I don't quite get this one, if you build any package from a non-rpm
source it's not a given that rpm modules will work with it. Akmod is
really a convenience for people reliant on non-tree modules who are
also using the distribution rpm kernel, so they have a chance of
getting a working module whenever the kernel updates. If you're
building your own kernel you probably know when you've done it and how
to build the module.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Andrew Lutomirski]

On Thu, Jan 14, 2016 at 4:01 PM, Reindl Harald  wrote:
>
>
> Am 15.01.2016 um 00:36 schrieb Andrew Lutomirski:
>>
>> If, for example, it simply installed into
>> /lib/modules/VERSION/akmod/path/to/driver.ko, then rpm could be taught
>> to delete /lib/modules/VERSION when the corresponding kernel package
>> goes away (either using a scriptlet in the kernel package or an RPM
>> trigger, I imagine), and everything would work nicely without
>> injecting extra rpms into the system
>
>
> rpm's remove files and folders they installed
>
> if that folders are not empty because foreign files that files and the
> folders will stay afetr remove - there is no "but" - it is unacceptable when
> a package purges a whole folder due removal because you can't know what and
> why the user stored there
>
> any package doing such craft would need to be fixed
> so don't propose any package should start such black magic

I'll ask again: can you please think just a little bit before
arbitrarily objecting to things people suggest on this list?

Suppose that the removal of kernel-core-4.3.3-300.fc23.x86_64
automatically deleted everything in
/lib/modules/4.3.3-300.fc23.x86_64/akmods.  What, if anything, would
go wrong?  I'm serious.  That folder would exist for the /specific
purpose/ of being unlinked when the matching kernel goes away.  This
would be safe because (a) the contents are useless if the kernel isn't
there and (b) the contents can be autogenerated (by a hypothetical
better akmods or similar tool) if the kernel got reinstalled.


--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 15.01.2016 um 01:07 schrieb Andrew Lutomirski:

On Thu, Jan 14, 2016 at 4:01 PM, Reindl Harald  wrote:

Am 15.01.2016 um 00:36 schrieb Andrew Lutomirski:


If, for example, it simply installed into
/lib/modules/VERSION/akmod/path/to/driver.ko, then rpm could be taught
to delete /lib/modules/VERSION when the corresponding kernel package
goes away (either using a scriptlet in the kernel package or an RPM
trigger, I imagine), and everything would work nicely without
injecting extra rpms into the system



rpm's remove files and folders they installed

if that folders are not empty because foreign files that files and the
folders will stay afetr remove - there is no "but" - it is unacceptable when
a package purges a whole folder due removal because you can't know what and
why the user stored there

any package doing such craft would need to be fixed
so don't propose any package should start such black magic


I'll ask again: can you please think just a little bit before
arbitrarily objecting to things people suggest on this list?


i think more than just a little bit


Suppose that the removal of kernel-core-4.3.3-300.fc23.x86_64
automatically deleted everything in
/lib/modules/4.3.3-300.fc23.x86_64/akmods.  What, if anything, would
go wrong?  I'm serious.  That folder would exist for the /specific
purpose/ of being unlinked when the matching kernel goes away


it is not part of the kernel and there is no business to include 
*arbitrarily* fuzzy logic in a package because other 3rd party scripts 
could have stored something there which might be removed


*especially* not in the kernel package



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Andrew Lutomirski]

On Thu, Jan 14, 2016 at 3:04 PM, Ian Malone  wrote:
> On 14 January 2016 at 19:29, Andrew Lutomirski  wrote:
>> 2. Assuming that shipping an out-of-tree module is okay, is akmod a good
>> mechanism?
>>
>> I would argue strongly that akmod is *not* a good mechanism.
>>
>> Clearly any end-user-box-builds-modules system needs the package manager to
>> pull in the right devel stuff.  This is clearly a solvable problem.
>>
>> But akmod in particular has a really nasty built-in assumption: it assumes
>> that the running kernel came from an RPM at all.  For people who write
>> kernels, this utterly sucks.  For example, I have no intention of rpm-ifying
>> every test kernel I build for my laptop.  I install them according to the
>> standard arrangement, which "make install" can do just fine.  There are
>> symlinks in standard places that a kmod build system could find.  Akmod
>> can't do that.  Akmod also can't figure out what to make its freshly-built
>> rpm depend on because there is no correct answer.
>>
>> I think that, if Fedora were to adopt a kmod build system: it should have a
>> QA requirement: if you "make modules_install && make install" a kernel and
>> boot into it, the kmod system should work.  Akmod fails utterly in that
>> scenario.
>>
>
> I don't quite get this one, if you build any package from a non-rpm
> source it's not a given that rpm modules will work with it.

Of course there's no guarantee, but IMO it should at least try rather
than just failing utterly because the kernel doesn't come from an rpm.

> Akmod is
> really a convenience for people reliant on non-tree modules who are
> also using the distribution rpm kernel, so they have a chance of
> getting a working module whenever the kernel updates. If you're
> building your own kernel you probably know when you've done it and how
> to build the module.
>

I disagree here.

I use the nvidia binary module from rpmfusion on one machine because
its card isn't supported by nouveau yet.  I also sometimes prefer to
run my own kernels (to test, to develop, to benchmark, or to enable
new hardware -- I write kernel drivers on occasion).  But installing
the nvidia driver from the nvidia-provided script is a colossal mess
-- I have no reason to believe that it won't clobber something, that
it will uninstall correctly, etc.  The rpmfusion version is nicely
packaged, but the actual kernel module part simply refuses to try to
install.

If there was a good, concrete benefit to its refusal to install, I'd
be more understanding, but AFAICT it's just doing complicated things
with packaging for no particularly good reason.

If, for example, it simply installed into
/lib/modules/VERSION/akmod/path/to/driver.ko, then rpm could be taught
to delete /lib/modules/VERSION when the corresponding kernel package
goes away (either using a scriptlet in the kernel package or an RPM
trigger, I imagine), and everything would work nicely without
injecting extra rpms into the system.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 14.01.2016 um 19:54 schrieb Neal Gompa:

On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb  wrote:

On 01/14/2016 07:56 AM, Neal Gompa wrote:


Aside from the DNF issue, is there anything else I'm missing in
relation to kmods in Fedora?


If you have secure boot, you have to go through the process to sign the
kernel modules you build and register the key with the boot system.


That would be something our build system (Koji, etc.) would handle if
we allowed them again, right? After all, I believe Koji handles our
kernel signing, too.


how do you imagine in real life maintaining kmod's by different people 
and maintaining the kernel by others?


there are often timeframes where you get each week and in rare cases 
twice a week a kernel update - have fun to coordinate that!


and *no* hold back kernel updates for crap hardware not supported by the 
mainline kernel or burden the kernel package-maintainer the additional 
work is no solution


i don't want to get my kernel pushed with a delay because of other 
packages i don't care because a few users don#t think before by computers




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Josh Boyer]

On Thu, Jan 14, 2016 at 1:54 PM, Neal Gompa  wrote:
> On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb  wrote:
>> On 01/14/2016 07:56 AM, Neal Gompa wrote:
>>>
>>> Aside from the DNF issue, is there anything else I'm missing in
>>> relation to kmods in Fedora?
>>>
>> If you have secure boot, you have to go through the process to sign the
>> kernel modules you build and register the key with the boot system.
>
> That would be something our build system (Koji, etc.) would handle if
> we allowed them again, right? After all, I believe Koji handles our
> kernel signing, too.

No, it would not.

The kernel modules are signed with an ephemeral cert as part of the
kernel build process.  They are not signed with the Fedora cert used
for Secure Boot.  The vmlinuz and grub2 binaries are signed with the
Secure Boot cert.  The tool that does the signing only works with
PECoff binaries and the kernel modules are not PECoff.

So no, the build system does not support signing modules outside of
the normal kernel build.

josh
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Neal Gompa]

On Thu, Jan 14, 2016 at 2:00 PM, Josh Boyer  wrote:
> On Thu, Jan 14, 2016 at 1:54 PM, Neal Gompa  wrote:
>> On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb  wrote:
>>> On 01/14/2016 07:56 AM, Neal Gompa wrote:

 Aside from the DNF issue, is there anything else I'm missing in
 relation to kmods in Fedora?

>>> If you have secure boot, you have to go through the process to sign the
>>> kernel modules you build and register the key with the boot system.
>>
>> That would be something our build system (Koji, etc.) would handle if
>> we allowed them again, right? After all, I believe Koji handles our
>> kernel signing, too.
>
> No, it would not.
>
> The kernel modules are signed with an ephemeral cert as part of the
> kernel build process.  They are not signed with the Fedora cert used
> for Secure Boot.  The vmlinuz and grub2 binaries are signed with the
> Secure Boot cert.  The tool that does the signing only works with
> PECoff binaries and the kernel modules are not PECoff.
>
> So no, the build system does not support signing modules outside of
> the normal kernel build.
>

So that would mean in order to make kernel modules build to work
outside of the kernel build process, we would need a way to add more
certs that would be accepted by the kernel and grub, right? I assume
you'd want to do the ephemeral cert process for kmod builds too?



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Josh Boyer]

On Thu, Jan 14, 2016 at 10:56 AM, Neal Gompa  wrote:
> Hello all,
>
> I've recently been wondering why we haven't allowed kernel module
> packages in Fedora since Fedora 8. I've tried searching through our
> wiki and the mailing list, but I haven't come up with any concrete
> reasons for why we disallow them.
>
> If it is perhaps the issue of keeping things in sync with kernels we
> provide (that is, maintainers didn't/couldn't keep up with new kernels
> being pushed during a release cycle), then I think the situation has
> changed.
>
> We have two tools that can help us in this regard: akmod and Koschei,
> both came after our policy change to disallow kernel modules.
>
> akmod is essentially DKMS except that instead of just building the
> kernel module, it'll build a kernel module package that matches an
> exact kernel release. Some of the weird problems that happen with DKMS
> don't seem to happen with akmod because of this. There's an argument
> for the akmod functionality being part of RPM and perhaps that should
> be the case. In any case, I don't see any particular reason akmod
> couldn't be brought into Fedora.
>
> On the other end, we have Koschei, which tracks and rebuilds things
> automatically (but doesn't submit automatically). It should be
> possible to adapt what Koschei does to be able to automatically
> generate new kmod packages tied to a particular kernel release and
> make it easy for a maintainer to turn that into something that can be
> submitted as part of a kernel update bundle to Bodhi.
>
> The biggest blocker I know of with kmods (at least dkms and akmod
> style ones) is we have a bug where DNF picks the wrong kernel-devel
> package at depsolve time[0] (this also appears to affect installing
> kernel-modules-extras too).
>
> Aside from the DNF issue, is there anything else I'm missing in
> relation to kmods in Fedora?

The kernel team does not support their inclusion in Fedora.  In brief,
it is asking to allow an out-of-tree, non-upstream, unreviewed chunk
of code into potentially every Fedora install that has no restrictions
on what it can do and can easily crash a machine or worse.

If the code in question _was_ reviewed and headed into the upstream
kernel tree, the kernel team still would not support building it as a
separate stand-alone module.  There are buildsystem issues I mentioned
in another email, but the plain fact is that in that specific case it
simply wouldn't be worth packaging separately.  Something clearly on
its way upstream would get pulled into the kernel package itself as
patches and built with every other module we provide.

This is a major part of why we disallowed them in the past and that
was before any of the existing kernel team members were on the team
yet.  Our stance has not changed over time or with the introduction of
new team members.

josh
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Lubomir Rintel]

On Thu, 2016-01-14 at 10:56 -0500, Neal Gompa wrote:
> Hello all,
> 
> I've recently been wondering why we haven't allowed kernel module
> packages in Fedora since Fedora 8. I've tried searching through our
> wiki and the mailing list, but I haven't come up with any concrete
> reasons for why we disallow them.
> 
> If it is perhaps the issue of keeping things in sync with kernels we
> provide (that is, maintainers didn't/couldn't keep up with new
> kernels
> being pushed during a release cycle), then I think the situation has
> changed.
> 
> We have two tools that can help us in this regard: akmod and Koschei,
> both came after our policy change to disallow kernel modules.
> 
> akmod is essentially DKMS except that instead of just building the
> kernel module, it'll build a kernel module package that matches an
> exact kernel release. Some of the weird problems that happen with
> DKMS
> don't seem to happen with akmod because of this. There's an argument
> for the akmod functionality being part of RPM and perhaps that should
> be the case. In any case, I don't see any particular reason akmod
> couldn't be brought into Fedora.
> 
> On the other end, we have Koschei, which tracks and rebuilds things
> automatically (but doesn't submit automatically). It should be
> possible to adapt what Koschei does to be able to automatically
> generate new kmod packages tied to a particular kernel release and
> make it easy for a maintainer to turn that into something that can be
> submitted as part of a kernel update bundle to Bodhi.
> 
> The biggest blocker I know of with kmods (at least dkms and akmod
> style ones) is we have a bug where DNF picks the wrong kernel-devel
> package at depsolve time[0] (this also appears to affect installing
> kernel-modules-extras too).
> 
> Aside from the DNF issue, is there anything else I'm missing in
> relation to kmods in Fedora?

The kernel doesn't have a stable API. Nothing guarantees the kernel
module would work with newer kernel version. As is usually the case, it
doesn't and it either break user's system or leaves it outdated, both
of which are horrible user experience.

> Best regards,
> Neal
> 
> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1228897
> 
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Samuel Sieb]

On 01/14/2016 07:56 AM, Neal Gompa wrote:

Aside from the DNF issue, is there anything else I'm missing in
relation to kmods in Fedora?

If you have secure boot, you have to go through the process to sign the 
kernel modules you build and register the key with the boot system.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Neal Gompa]

On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb  wrote:
> On 01/14/2016 07:56 AM, Neal Gompa wrote:
>>
>> Aside from the DNF issue, is there anything else I'm missing in
>> relation to kmods in Fedora?
>>
> If you have secure boot, you have to go through the process to sign the
> kernel modules you build and register the key with the boot system.

That would be something our build system (Koji, etc.) would handle if
we allowed them again, right? After all, I believe Koji handles our
kernel signing, too.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 15.01.2016 um 00:36 schrieb Andrew Lutomirski:

If, for example, it simply installed into
/lib/modules/VERSION/akmod/path/to/driver.ko, then rpm could be taught
to delete /lib/modules/VERSION when the corresponding kernel package
goes away (either using a scriptlet in the kernel package or an RPM
trigger, I imagine), and everything would work nicely without
injecting extra rpms into the system


rpm's remove files and folders they installed

if that folders are not empty because foreign files that files and the 
folders will stay afetr remove - there is no "but" - it is unacceptable 
when a package purges a whole folder due removal because you can't know 
what and why the user stored there


any package doing such craft would need to be fixed
so don't propose any package should start such black magic

well, that affects me too because VMware workstation modules but it's my 
job and not the business of the kernel package




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Josh Boyer]

On Thu, Jan 14, 2016 at 2:09 PM, Neal Gompa  wrote:
> On Thu, Jan 14, 2016 at 2:00 PM, Josh Boyer  wrote:
>> On Thu, Jan 14, 2016 at 1:54 PM, Neal Gompa  wrote:
>>> On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb  wrote:
 On 01/14/2016 07:56 AM, Neal Gompa wrote:
>
> Aside from the DNF issue, is there anything else I'm missing in
> relation to kmods in Fedora?
>
 If you have secure boot, you have to go through the process to sign the
 kernel modules you build and register the key with the boot system.
>>>
>>> That would be something our build system (Koji, etc.) would handle if
>>> we allowed them again, right? After all, I believe Koji handles our
>>> kernel signing, too.
>>
>> No, it would not.
>>
>> The kernel modules are signed with an ephemeral cert as part of the
>> kernel build process.  They are not signed with the Fedora cert used
>> for Secure Boot.  The vmlinuz and grub2 binaries are signed with the
>> Secure Boot cert.  The tool that does the signing only works with
>> PECoff binaries and the kernel modules are not PECoff.
>>
>> So no, the build system does not support signing modules outside of
>> the normal kernel build.
>>
>
> So that would mean in order to make kernel modules build to work
> outside of the kernel build process, we would need a way to add more
> certs that would be accepted by the kernel and grub, right? I assume
> you'd want to do the ephemeral cert process for kmod builds too?

If you are creating a cert to sign the out-of-tree modules and expect
it to be accepted by the kernel, it cannot be ephemeral.  A user would
need someway to import it into their kernel or have it passed from
grub.  The only way to do so is to have it embedded in shim or the
kernel during the build of those binaries.  I do not foresee Fedora
creating yet another persistent key to sign things with, which means
you would need another tool that can use the existing key in the
kernel builders.

Except there are only 4 people that can submit builds to those
builders for security purposes (which is why scratch builds are
unsigned), and I don't see any of the existing maintainers signing up
to submit kmod builds.

So no, our buildsystem cannot sign kmods.

josh
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 14.01.2016 um 20:09 schrieb Neal Gompa:

On Thu, Jan 14, 2016 at 2:00 PM, Josh Boyer  wrote:

On Thu, Jan 14, 2016 at 1:54 PM, Neal Gompa  wrote:

On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb  wrote:

On 01/14/2016 07:56 AM, Neal Gompa wrote:


Aside from the DNF issue, is there anything else I'm missing in
relation to kmods in Fedora?


If you have secure boot, you have to go through the process to sign the
kernel modules you build and register the key with the boot system.


That would be something our build system (Koji, etc.) would handle if
we allowed them again, right? After all, I believe Koji handles our
kernel signing, too.


No, it would not.

The kernel modules are signed with an ephemeral cert as part of the
kernel build process.  They are not signed with the Fedora cert used
for Secure Boot.  The vmlinuz and grub2 binaries are signed with the
Secure Boot cert.  The tool that does the signing only works with
PECoff binaries and the kernel modules are not PECoff.

So no, the build system does not support signing modules outside of
the normal kernel build.


So that would mean in order to make kernel modules build to work
outside of the kernel build process, we would need a way to add more
certs that would be accepted by the kernel and grub, right? I assume
you'd want to do the ephemeral cert process for kmod builds too?


it is not supported by the kernel maintainers for a lot of reasons
accept it or become "the kernel maintainers"



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Andrew Lutomirski]

On Jan 14, 2016 9:34 AM, "Nicolas Chauvet"  wrote:
>
> 2016-01-14 18:05 GMT+01:00 Neal Gompa :
>>
>> On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald 
wrote:
>> >
>> > Am 14.01.2016 um 16:56 schrieb Neal Gompa:
>> >>
>> >> I've recently been wondering why we haven't allowed kernel module
>> >> packages in Fedora since Fedora 8. I've tried searching through our
>> >> wiki and the mailing list, but I haven't come up with any concrete
>> >> reasons for why we disallow them.
>> >>
>> >> If it is perhaps the issue of keeping things in sync with kernels we
>> >> provide (that is, maintainers didn't/couldn't keep up with new kernels
>> >> being pushed during a release cycle), then I think the situation has
>> >> changed.
>> >>
>> >> We have two tools that can help us in this regard: akmod and Koschei,
>> >> both came after our policy change to disallow kernel modules.
>> >
>> >
>> > akmod is a dirty hack and fails often enough for rpmfusion stuff
>> >
>> > additionally you should *never* need GCC and devel packages installed
on a
>> > normal enduser system for a ton of reasons
>>
>> The most common reason that akmod fails is the same reason dkms often
>> fails: the correct kernel-devel isn't installed. For whatever reason,
>> there's no logic in DNF to handle this case properly. Of course, to be
>> fair, this problem happens in Yum too, but since Yum isn't actively
>> supported in Fedora anymore, it's not as much of a concern.
>
>
> Maybe this particular concern can be addressed in DNF with a plugin ?
>
> The way I've previously worded a possible solution is to have a yum/dnf
plugin for akmod.
> This plugin will select the appropriate kernel-devel based on the kernel
that is currently installed.
> ( https://bugzilla.rpmfusion.org/show_bug.cgi?id=3386 ).
>
> But this dnf plugin can be useful by default in fedora, since the
kernel-devel issue can rise when one user install a particular development
group where kernel-devel is needed.
> (user typically ends with kernel-debug-devel instead of the one for their
kernel variant that can also be kernel-lpae or else).

There are two issues here, I think:

1. Is Fedora okay, in principle, with shipping out-of-tree modules?

I won't comment on #1.  (I also won't comment on Secure Boot issues.)

2. Assuming that shipping an out-of-tree module is okay, is akmod a good
mechanism?

I would argue strongly that akmod is *not* a good mechanism.

Clearly any end-user-box-builds-modules system needs the package manager to
pull in the right devel stuff.  This is clearly a solvable problem.

But akmod in particular has a really nasty built-in assumption: it assumes
that the running kernel came from an RPM at all.  For people who write
kernels, this utterly sucks.  For example, I have no intention of
rpm-ifying every test kernel I build for my laptop.  I install them
according to the standard arrangement, which "make install" can do just
fine.  There are symlinks in standard places that a kmod build system could
find.  Akmod can't do that.  Akmod also can't figure out what to make its
freshly-built rpm depend on because there is no correct answer.

I think that, if Fedora were to adopt a kmod build system: it should have a
QA requirement: if you "make modules_install && make install" a kernel and
boot into it, the kmod system should work.  Akmod fails utterly in that
scenario.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org