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.
Attachment:
signature.asc
Description: This is a digitally signed message part
