Hacking modversions

[Arjan van de Ven]

On Tue, 2005-03-01 at 19:22 +0000, Mike Hearn wrote:


> An ABI is a precise thing

only if it's defined. the linux kernel internals aren't.


> , I see that modversions already bases
> the checksums on things like struct size (though in my kernels it looks
> like every symbol changes so maybe it's random too). 

that by far isn't enough to describe the ABI. You also have to include
things like locking order, locking rules and every other kind of
behavior as well. 
Simple example: a function that suddenly no longer accepts NULL as a
safe parameter but oopses. Ok artiticial, but not that much (esp if it
was never supposed to be called with NULL) and it's REALLY hard to catch
such ABI changes. 

One step further: Now imagine this happening because you add a function
call inside the function, where with luck before NULL was harmless. And
this function happened to be one to be used (incorrectly) by
$yourfavoritemodule. End of game. It's *REALLY* hard to detect such
things preemptively, esp since we don't have the source to the external
modules (even when they are open source; realistically they are second
citizens and don't get looked at much for such things)


> It should be possible
> to look at a bugfix and say "Yep that doesn't change the ABI".

you would be surprised how incredibly hard that is. Red Hat tries it
really hard for RHEL, and even there we accidentally break the ABI like
every other update release in practice, despite trying REALLY hard.

It simply isn't as simple as it sounds. Most security fixes nowadays are
either very local, or cross multiple functions, probably in a 50% ratio
each. The moment you cross a function barrier you've lost in the "easy
ABI" game and it gets REALLY tricky. And even for local fixes it's not
always so easy... take the NULL pointer example.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050301/7834cecf/attachment.sig>