[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)

On Thu, Mar 24, 2005 at 03:30:01PM -0500, Andres Salomon wrote:
> (ignoring -release followup-to, since it affects -kernel and -boot as well)

Sorry, mailer misfire, I guess.

> On Thu, 24 Mar 2005 03:24:53 -0800, Steve Langasek wrote:

> > recompiles on every revision of a kernel-image package, which is slightly
> > irritating; or failing to provide a smooth downgrade path in the event of an

> That is irritating, but less so than rebooting and discovering you need to
> run `module-assistant auto-install <foo>` to compile a module for an ABI
> change (and if the machine requires the third party module to boot and get
> online, fun ensues).  That said, if we could get a solution to long NEW
> processing times, then doing both in tandem (ABINAMEs + recompile hooks
> upon ABI and major kernel upgrades) is a possibility.

I don't believe long NEW processing times are seriously an issue here; the
ftp team is very responsive to needs for quick processing of
release-relevant kernel packages.  The problem, AFAICT, is that it currently
takes so many *iterations* of NEW processing to get everything updated for a
kernel ABI change, including kernel-image packages for 11 architectures that
arrive in NEW over a span of weeks, plus whatever module binary packages
there are.

> > ABI change that coincides with a silently broken module, which is truly
> > ugly.  The idea of automatically recompiling modules sounds good to me,
> > but I still think it needs to be coupled with kernel ABI tracking to
> > avoid the risk of slagging the user's initrd.

> How would the initrd get slagged?  It would need to be regenerated, of
> course, during the upgrade to pull in newly built modules.

Any time you rebuild your kernel binary modules, there's a non-zero chance
that the rebuilt version will not work correctly even though it built
successfully.  If you aren't going to track ABI changes, then you have no
backup kernel to use in this case (because you've overwritten the old one
with a binary-incompatible one) that would let you roll back the change in
the event that one of the modules that broke rendered your system

It's a standard part of my system administration practices to keep a
previous kernel version around that I can roll back to when upgrading to a
new version; this approach would seem to make that more awkward.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: