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

[Ben Hutchings <ben@decadent.org.uk>]

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

On Wed, 2016-11-30 at 10:40 -0800, Linus Torvalds wrote:
> > On Wed, Nov 30, 2016 at 10:18 AM, Nicholas Piggin <npiggin@gmail.com> wrote:
> > 
> > Here's an initial rough hack at removing modversions. It gives an idea
> > of the complexity we're carrying for this feature (keeping in mind most
> > of the lines removed are generated parser).
> 
> You definitely don't have to try to convince me. We've had many issues
> with modversions over the years. This was just the "last drop" as far
> as I'm concerned, we've had random odd crc generation failures due to
> some build races too.
> 
> > In its place I just added a simple config option to override vermagic
> > so distros can manage it entirely themselves.
> 
> So at least Fedora doesn't even enable CONFIG_MODVERSIONS as-is. I'm
> _hoping_ it's just Debian that wants this,

The last time I looked, RHEL and SLE did.  They change the release
string for each new kernel version, but they will copy/link old out-of-
tree modules into the new version's "weak-updates" module subdirectory
if the symbol versions still match.

> and we'd need to get some
> input from the Debian people whether that "control vermagic" is
> sufficient? I suspect it isn't, but I can't come up with any simple
> alternate model either..

Allowing the vermagic to be changed separately doesn't help us, as we
already control the release string.  If we were to change some of the
module tools to consider vermagic then it would allow us to report the
full version in the release string while not forcing rebuilds on every
kernel upgrade - but that's not a pressing problem.

One thing that could work for us would be:

- Stricter version matching for in-tree modules (maybe some extra
  part in vermagic that is skipped for out-of-tree modules)
- Ability to blacklist use of a symbol, or all symbols in a module,
  by out-of-tree modules

where the blacklist would be a matter of distribution policy.  But this
would still require a fair amount of work by someone, and I doubt you'd
want this upstream.

> I'm also somewhat surprised that it's Debian that has this problem,
> considering how Debian is usually the distro that is _least_ receptive
> to various non-free binaries.

If this was just about non-free modules I wouldn't care.  There are
also many freely licenced out-of-tree modules that for various reasons
don't get submitted or accepted upstream; also backports of new or
updated drivers.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by
stupidity.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]