Re: Maintaining kernel source in sarge
Matt Zimmerman <mdz@debian.org> wrote:
>
> I think that we can live with multiple source packages given a little bit of
> infrastructure which more closely follows the way that kernel development
> happens. We need to be able to introduce specific patches to all of our
> kernels while minimizing the possibility of errors. Errors include breaking
> kernel builds, breaking module packages, missing some kernel packages and
> patches, etc. We also need to consider users who need to build their own
> kernels.
Agreed.
>> Here is my rough idea as to how it can work:
>>
>> 1. The architectures should be treated as independent packages.
>
> By 'independent packages', do you mean that we should have separate
> kernel-source source packages for each architecture? This would seem to be
> a step backward.
No, they are independent packages already in that each architecture is
built from a different Debian source package. I'm just saying that the
Security Team should treat it as different packages for the purposes of
release DSAs.
> This is already the case. However, look at the mess which results: s390
> and mips have integrated one of the ptrace patches into their respective
> kernel-patch packages (DSA-276 and DSA-270). Now, how are we going to fix
> i386? If we integrate the patch into kernel-source-2.4.17 or
> kernel-source-2.4.19, then s390 and mips are now broken because they will
> conflict.
This is a mistake that we can avoid in future. The release of a
kernel-source or a general kernel-patch package with the security fix
should precede all architecture uploads.
>> The main advantage to this is in fact security. It is routine for small
>> security fixes to enter a stable kernel unannounced. For instance,
>> between 2.4.18 and 2.4.19, dozens of unannounced small security which only
>> affect specific drivers were fixed. It also minimises any back-porting
>> that has to be done when a security alert is raised.
>
> I believe that we should not do anything to encourage this kind of
> irresponsible behaviour. If an upstream is not willing to share information
> about security fixes with us, we should not reward them by doing extra
> integration work to try to push a new upstream release into stable.
Well it's not a question of irresponsibility. It's simply impossible to
for either the upstream or us to vet every single patch that passes through
the system and decide whether it has security implications and raise an
alert as a result.
>> In fact, due to the use of modules, it is often impossible to make
>> security fixes which are module ABI compatible with previous kernels. For
>> example, the last two security holes (ptrace and net hash) both changed
>> the modules ABI.
>
> It is infortunate if this must sometimes happen, but hopefully it is an
> exception, and in those cases we will need to rebuild modules and provide
> for both kernel images to be installed at once.
It's going to be more common than you think due to the way the Linux
module ABI works. A small change in any structure that is either directly
or indirectly referred to by a commonly used one will result in a change.
> I don't see why the ptrace fix necessitated a change in the module ABI
> however, only that it was implemented that way upstream.
If you mean that it could have been fixed without changing the bitfields
in task_struct then perhaps so assuming that we care about it enough to
do it in such a way. Otherwise I don't see your point.
>> Let me make it a bit more concrete as to what we can do about woody
>> right now.
>
> Yes, on that note: could you send any separate patches that you have for
> these issues to team@security.debian.org?
>
> - CAN-2003-0001: etherleak
> - CAN-2003-0127: ptrace
> - CAN-2003-0244: ip route cache hash
> - CAN-2003-0246: ioperm issue
> - CAN-2002-1380: mmap() on /proc/pid/mem
> - CVE-2002-0429: lcall7 DoS
Will do. However I can't guarantee that the patches will apply to
older versions of 2.4.
> Here is a quick list for unstable:
>
> mizar:[...deb/notmine/security/kernel] apt-cache dumpavail | grep-dctrl -nsPackage -FDepends kernel-source-
> kernel-patch-2.2.20-powerpc
> kernel-patch-2.4.19-powerpc
> kernel-patch-2.4.20-hppa
> kernel-patch-2.4.20-ia64
> kernel-patch-2.4.20-powerpc
>
> Shall I file bugs for these so that they can be fixed for sarge?
I don't really mind the arch-specific kernel-patch packages depending
on them since they are and should always built against the Debian source.
I was mostly referring to the other kernel-patch packages.
In fact, I don't see a single generic kernel-patch package in unstable
that depends on kernel-source. That's a great thing.
>> Solution: Remove offending kernel-patch packages and kernel-source
>> packages. Users of those kernel-source packages should be encouraged to
>> upgrade to a later version. I'd recommend that we keep 2.4.18 and inject
>> 2.4.19/2.4.20 as soon as possible. All architectures have kernel images
>> in either stable or proposed-updates that is at least 2.4.18 or higher.
>
> Removing kernel-patch package from stable does not help users who are
> running kernels built from them, and this is not the least of the problems,
> either. Linux 2.4 does not exactly have a clean record when it comes to
> compatibility. What happens when some other package in woody breaks as a
> result of blindly upgrading to a new kernel release? Do we then work to fix
> that package, and then retest that packages which depend on it still work?
> What if the package which breaks is, for example, glibc? It would not be
> the first time.
>
> Pushing a new kernel release is essentially punting to the user, forcing
> them to decide between old bugs and new bugs.
Firstly I'm not suggesting the uploading new versions in direct response to
a security alert. I'm saying that we should be keeping up with new
versions so that we can be better prepared for subsequent security alerts.
And please don't exaggerate about the possibility of breaking systems.
New versions are only uploaded to proposed-updates after extensive testing
by the maintainers, the users in unstable as well as the general Linux
user base. If you have a particular breakage in the 2.4 line in mind,
please bring it up so we can see how it could've be dealt with better.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Reply to: