Thread (87 messages) 87 messages, 17 authors, 2016-12-15

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

From: Hannes Frederic Sowa <hidden>
Date: 2016-12-14 14:13:09
Also in: linux-kbuild, lkml

Possibly related (same subject, not in this thread)

On 09.12.2016 17:03, Greg Kroah-Hartman wrote:
On Sat, Dec 10, 2016 at 01:56:53AM +1000, Nicholas Piggin wrote:
quoted
On Fri, 9 Dec 2016 15:36:04 +0100
Stanislav Kozina [off-list ref] wrote:
quoted
quoted
quoted
quoted
quoted
The question is how to provide a similar guarantee if a different way?  
As a tool to aid distro reviewers, modversions has some value, but the
debug info parsing tools that have been mentioned in this thread seem
superior (not that I've tested them).  
On the other hand the big advantage of modversions is that it also
verifies the checksum during runtime (module loading). In other words, I
believe that any other solution should still generate some form of
checksum/watermark which can be easily checked for compatibility on
module load.
It should not be hard to add to the DWARF based tools though. We'd just
parse DWARF data instead of the C code.  
A runtime check is still done, with per-module vermagic which distros
can change when they bump the ABI version. Is it really necessary to
have more than that (i.e., per-symbol versioning)?  
 From my point of view, it is. We need to allow changing ABI for some 
modules while maintaining it for others.
In fact I think that there should be version not only for every exported 
symbol (in the EXPORT_SYMBOL() sense), but also for every public type 
(in the sense of eg. structure defined in the public header file).
Well the distro can just append _v2, _v3 to the name of the function
or type if it has to break compat for some reason. Would that be enough?
There are other ways that distros can work around when upstream "breaks"
the ABI, sometimes they can rename functions, and others they can
"preload" structures with padding in anticipation for when/if fields get
added to them.  But that's all up to the distros, no need for us to
worry about that at all :)
The _v2 and _v3 functions are probably the ones that also get used by
future backports in the distro kernel itself and are probably the reason
for the ABI change in the first place. Thus going down this route will
basically require distros to touch every future backport patch and will
in general generate a big mess internally.

I think it is important to keep versioning information outside of the
source code. Some kind of modversions will still be required, but
distros should be able to decide if they put in some kind of checksum or
a string, what suites them most.

Thanks,
Hannes (who is still impressed by the genksyms tools)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help