Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Ben Hutchings]

[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@xxxxxxxxx> 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

Attachment: signature.asc
Description: This is a digitally signed message part