Message-ID: <1480382148.16599.61.camel@decadent.org.uk>
Date:   Tue, 29 Nov 2016 01:15:48 +0000
From:   Ben Hutchings <ben@...adent.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Nicholas Piggin <npiggin@...il.com>
Cc:     linux-arch@...r.kernel.org, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Michal Marek <mmarek@...e.com>, Arnd Bergmann <arnd@...db.de>,
        Ingo Molnar <mingo@...nel.org>,
        Adam Borowski <kilobyte@...band.pl>,
        Debian kernel maintainers <debian-kernel@...ts.debian.org>
Subject: Re: [PATCH] x86/kbuild: enable modversions for symbols exported
 from asm

[I've had to guess at the cc list for this, because we no longer have
mail archives that preserve them.]

On Fri, 2016-11-25 at 10:01 -0800, Linus Torvalds wrote:
> On Thu, Nov 24, 2016 at 4:40 PM, Nicholas Piggin <npiggin@...il.com> wrote:
> > > 
> > > Yes, manual "marking" is never going to be a viable solution.
> > 
> > I guess it really depends on how exactly you want to use it. For distros
> > that do stable ABI but rarely may have to break something for security
> > reasons, it should work and give exact control.

This is roughly how Debian handles the kernel module ABI during a
stable release.

> No. Because nobody else will care, so unless it's like a single symbol
> or something, it will just be a maintenance nightmare.

I agree with this.  We can explicitly "version" individual symbols
anyway by doing something like:

-int foo(void);
+#define foo foo_2
+int foo_2(int);

> > What else do people *actually* use it for? Preventing mismatched modules
> > when .git version is not attached and release version of the kernel has
> > not been bumped. Is that it?
> 
> It used to be very useful for avoiding loading stale modules and then
> wasting days on debugging something that wasn't the case when you had
> forgotten to do "make modules_install". Change some subtle internal
> ABI issue (add/remove a parameter, whatever) and it would really help.
> 
> These days, for me, LOCALVERSION_AUTO and module signing are what I
> personally tend to use.
>
> The modversions stuff may just be too painful to bother with. Very few
> people probably use it, and the ones that do likely don't have any
> overriding reason why.
[...]

Debian has some strong reasons:

1. Changing the release string requires any out-of-tree modules to be
upgraded (at least rebuilt) on end-user systems.  So we try to avoid
doing that during the lifetime of a stable release, i.e. we don't let
the release string change.  Also, the release string is reflected in
package names (e.g. linux-image-4.8.0-1-amd64), and introducing new
package names requires manual approval by the Debian archive team.

2. We want to allow ABI breaks for "internal" symbols used only by in-
tree modules, as those breaks will be resolved by rebooting to complete
the upgrade.  But we need a run-time check to prevent loading an
incompatible module before the reboot.

3. So far as I can see, module signing doesn't work for a distribution
kernel with out-of-tree modules as there has to be a trust path from a
built-in certificate to the module signing certificate.  So signature
enforcement will have to be disabled on systems that use out-of-tree
modules, thus it's not a substitute for modversions.

We expect Linux 4.9 to be the basis for a longterm stable branch and on
that basis intend to include it in the next Debian stable release. 
Even if the decision is to get rid of modversions, it would be very
helpful if they could be revived for 4.9 so that we have some time to
adapt our packaging practices to work without them in future.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
                                - John Levine, moderator of
comp.compilers


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists