Re: Maintaining kernel source in sarge
On Sun, May 25, 2003 at 07:58:09AM +1000, Herbert Xu wrote:
> Matt Zimmerman <mdz@debian.org> wrote:
> > 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.
In general, this is not a problem. The exception is coordinated disclosure,
where it is important that fixes be available for all architectures in order
to minimize exposure. In those cases, it would be helpful to coordinate
with all of the kernel package maintainers ahead of time.
> > 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.
Of course, we cannot expect anyone to tell us things that they do not
realize themselves. I thought you were referring to changes with known
security impact.
We cannot justifiably be too liberal with new releases in the hope of
getting unknown bugfixes, as we are as likely to receive unknown bugs.
> > 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.
If so, then we must be prepared to rebuild kernel module packages, and this
is a fact of life. Fortunately, we don't provide many of these.
> > 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.
Are task_struct and mm_struct exposed to modules? It does not seem like
they should need to be, but I am no expert in the kernel. If this is meant
to be this way, then shouldn't the struct have some amount of padding to
allow for changes like this without breaking compatibility?
> > 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.
That is no problem; at this point we need all of the information that we can
get. It helps greatly to see how the fix was made.
> > [arch-specific patch packages]
> >
> > 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.
Ah, I did not realize you did not mean to include these. Never mind, then.
> > 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.
That is, you are saying that we should try to run the most recent kernels so
that we can patch them more easily? I'm wary of introducing churn in stable
for problems which we don't yet know about.
> 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.
I did not mean to disregard the testing that you do, but kernel upgrades are
problematic enough as it is, considering that the entire system must be
brought down.
One example which comes to mind immediately is the grossly incompatible
TUN/TAP changes around kernel 2.4.5. The UML skas breakage from the ptrace
fix is another, but I don't know if that was possible to avoid.
We also have to deal with the fact that miscellaneous changes between kernel
releases can and do break third-party patches (EVMS 1.2.x, device-mapper,
freeswan, etc.) that we ship and our users depend on to run their systes.
If the only fix we provide is an updated kernel, then users can no longer
use the patches that we supply.
--
- mdz
Reply to: