[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 04:31:24AM -0500, Andres Salomon wrote:
> > Now, for this to be fully efficient, there is still a little change that
> > needs done to d-i. Support for the kernel meta-packages for all arches.

> > A common kernel-official or whatever package will be created, including
> > all the kernel-latest or whatever fixes, and base-installer will
> > exclusively install those packages (altough at lower priority it could
> > propose to bypass them or something), since this is needed to make
> > abi-breaking arches kernel security uploads transparent to the user
> > doing an apt-get upgrade.

> > Ok, this is my proposal, i am waiting for feedback, and i hope those
> > that put me in your blacklist would reconsider and still follow up on
> > this proposal.

> One of the things not mentioned was ABI stuff.  I implemented an
> ABI-check-during-build for ubuntu, but I don't feel that's a long term
> solution; really, I don't care for our current ABI handling at all.  I
> don't want to deal w/ package renames, nor do I want to deal w/ toolchain
> breakage fucking our ABI, and other misc things that might happen.  I
> had intended to brainstorm w/ fabbione and other people at the next
> ubuntu conference regarding this, but I'll mention my thoughts now, as
> well.

> We can assume, if the user is keeping up on kernel upgrades, that they
> either have a kernel build environment installed, or have a central
> machine that does builds for them.  If they're not keeping up on
> kernel upgrades.. Well, they should be, unless they're completely
> disconnected from the internet or something.  There is always some manual
> work involved during an ABI-changing upgrade; every upgrade means a
> rebuild of third party modules on some machine.

> My idea is to do away w/ ABI considerations, and instead compile modules
> in the kernel's postinst.  This would happen for every kernel upgrade, iff
> there are third party modules registered w/ the system.  The way this
> might look is:

> - hostap-source installs /usr/src/modules/hostap.tar.bz2, and depends upon
> gcc, make, bzip2, and module-assistant.
> - kernel-image-2.6.10-686 (pre-?)depends upon kernel-headers-2.6.10-686.
> - During k-i-2.6.10-686's preinst, for each module tarball in
> /usr/src/modules, untar and build using module-assistant.  If any build
> fails, abort the upgrade/install.  If all builds succeed, proceed with the
> upgrade/install
> - During k-i-2.6.10-686's postinst, for each module tarball in
> /usr/src/modules, install the appropriate module package (built in
> preinst).

A pre-dependency on kernel-headers doesn't seem to guarantee that gcc,
module-assistant, or any of the module-source packages are in a usable
state.  Currently nothing depends on kernel-images, so re-running the
dist-upgrade should be enough to fix this case without hitting nasty dep
loops, but even that seems much more awkward than I'd like.

Is it your intention that in such a system, the core kernel-image packages
would no longer declare abinames at all?  That would mean either gratuitous
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
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.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: