Bug#310982: plan to include in sarge 2.4 update

[Martin Schulze]

dann frazier wrote:
> On Mon, Nov 13, 2006 at 12:22:59PM -0800, Steve Langasek wrote:
> > Yes, because this is a kernel security bug.  The smbmount patch was
> > entertained pre-sarge only as a stopgap due to the proximity to release; the
> > right place to fix this is still in the kernel (upstream as appropriate).
> 
> I've done some testing and verified that 2.6.18 honors uid= and 2.6.8
> does not. It looks like this was fixed upstream:
>   http://linux.bkbits.net:8080/linux-2.6/[EMAIL 
> PROTECTED]|src/|src/fs|src/fs/smbfs|related/fs/smbfs/inode.c
> 
> So, I plan to use this patch for 2.6.8, and attempt to backport it to
> 2.4.27. If backporting becomes overly complicated/risky, I'll revert
> to using something like Horms' patch. I'll also see about getting a
> CVE assigned.
> 
> Everyone cool with this plan?

Ok.

Regards,

Joey

-- 
If nothing changes, everything will remain the same.  -- Barne's Law

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: sarge upgrade - linux, grub conflict

[Martin Schulze]

Bastian Blank wrote:
> On Tue, Apr 18, 2006 at 05:04:53PM +0200, maximilian attems wrote:
> > waldi why not add your patch to update-grub to the next stable release?

Please keep in mind that you can't rely on a current sarge installation
when it is upgraded to etch, in other words, you can't depend on people
keeping their sarge r0 up-to-date with newer revisions or security updates.
Especially for offline installations that are only maintained via ready
CD/DVD images this may be the case.

Regards,

Joey

-- 
The MS-DOS filesystem is nice for removable media.  -- H. Peter Anvin

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: timeline for next kernel update round

[Martin Schulze]

Martin Zobel-Helas wrote:
> Hi Moritz,
> 
> On Wednesday, 15 Mar 2006, you wrote:
> > Frans Pop wrote:
> > > On Wednesday 15 March 2006 00:15, Moritz Muehlenhoff wrote:
> > > > The update is built and tested, it'll appear soon. It contains three
> > > > ABI changing security fixes, so the ABI will be bumped. I can't speak
> > > > for d-i.
> 
> i had some discussion with Frans Pop today and we agreed that it might
> make more sense to have a new sarge d-i with R3 rather than R2. That's
> also due to the fact that he can't tell me how long it might take to
> build new sarge based d-i packages. (spoke about 2-8 weeks).
> 
> So my plan would be, as soon as we get the remaining issue for R2 fixed
> (which i expect within the next 2 weeks), we then go without new kernels
> in R2 and then have R3 a few weeks later (4-8 weeks), then with new
> kernels and new d-i.
> 
> Do you think this sounds reasonable for the security team?

Yes.

Regards,

Joey

-- 
Never trust an operating system you don't have source for!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: woody security updates

[Martin Schulze]

dann frazier wrote:
> On Thu, 2005-12-08 at 08:10 +0100, Martin Schulze wrote:
> > dann frazier wrote:
> > > Yes.  I really said woody.
> > > 
> > > I've imported the woody 2.4 kernel trees into an svn repository:
> > >   svn.debian.org/var/lib/gforge/chroot/home/users/dannf/woody
> > > 
> > > We're currently tracking 160 issues, across the 6 woody source trees:
> > >   svn://svn.debian.org/svn/kernel/patch-tracking
> > 
> > Thanks a lot!
> > 
> > However, please let us first roll out the update I've prepared already.
> 
> Ah; didn't realize you had already prepared one.  If you've only worked

I've even asked on debian-security for help, and got dilinger to help.
No status update though.

> on 2.4.18, I don't think there's been much duplication of effort.  So
> far I've just been merging patches that were already in 2.4.18 into the
> other trees - I'm just now getting to patches that aren't yet in 2.4.18.

Ok.

Regards,

Joey

-- 
Have you ever noticed that "General Public Licence" contains the word "Pub"?

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: woody security updates

[Martin Schulze]

dann frazier wrote:
> Yes.  I really said woody.
> 
> I've imported the woody 2.4 kernel trees into an svn repository:
>   svn.debian.org/var/lib/gforge/chroot/home/users/dannf/woody
> 
> We're currently tracking 160 issues, across the 6 woody source trees:
>   svn://svn.debian.org/svn/kernel/patch-tracking

Thanks a lot!

However, please let us first roll out the update I've prepared already.

It "only" needs to be ported forward / backward to 5 kernels...

The source for 2.4.18 is here:

http://klecker.debian.org/~joey/security/kernel/kernel-source-2.4.18_2.4.18-14.4.diff.gz
http://klecker.debian.org/~joey/security/kernel/kernel-source-2.4.18_2.4.18-14.4.dsc
http://klecker.debian.org/~joey/security/kernel/kernel-source-2.4.18_2.4.18.orig.tar.gz

Regards,

Joey

-- 
Have you ever noticed that "General Public Licence" contains the word "Pub"?

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#334113: CAN-2005-3257 assigned

[Martin Schulze]

This one is CAN-2005-3257.

Regards,

Joey

-- 
Never trust an operating system you don't have source for!

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Three more security problems in the 2.6 kernel

[Martin Schulze]

Moritz Muehlenhoff wrote:
> Hi Horms / security team,
> I found three more security related reports/patches on linux-kernel.
> 
> Cheers,
> Moritz
> 
> From: David Howells <[EMAIL PROTECTED]>
> 
> Plug request_key_auth memleak.  This can be triggered by unprivileged
> users, so is local DoS.
> 
> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
> Signed-Off-By: David Howells <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> ---
>  security/keys/request_key_auth.c |1 +
>  1 file changed, 1 insertion(+)
> 
> --- linux-2.6.13.y.orig/security/keys/request_key_auth.c
> +++ linux-2.6.13.y/security/keys/request_key_auth.c
> @@ -96,6 +96,7 @@ static void request_key_auth_destroy(str
> kenter("{%d}", key->serial);
> 
> key_put(rka->target_key);
> +   kfree(rka);
> 
>  } /* end request_key_auth_destroy() */

This is CAN-2005-3119 and... uh... not supposed to be public yet...

Regards,

Joey

-- 
Life is too short to run proprietary software.  -- Bdale Garbee


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: status of first round of sarge kernel updates

[Martin Schulze]

dann frazier wrote:
> On Wed, 2005-08-24 at 20:30 +0200, Martin Schulze wrote:
> > dann frazier wrote:
> > > On Tue, 2005-08-23 at 15:22 -0600, dann frazier wrote:
> > > > We're getting closer.  Please check this for accuracy:
> > > >   http://wiki.debian.net/?DebianKernelSargeUpdateStatus
> > > > 
> > > > I can try to do hppa this afternoon; any word on m68k, mips & s390?
> > > 
> > > Security Team,
> > >   Is there a way we can take advantage of your autobuilder setup for
> > > lagging archs?
> > 
> > Only when the source package is in the security queue accompanied
> > with a binary package the buildds for missing architectures should
> > try it on their respective architectures.
> 
> Joey,
>   Can we go ahead and start uploading packages for the archs we've
> completed?

Could you send me a {list,set} of patches and descriptions that were
fixed by these kernels?

> 
> And, if we can't find folks to build on these other archs, can we
> release a first pass advisory to get the completed ones out to users and
> followup later?  ISTR this happening for woody.

For woody, I have a whole bunch of updates.  I've tested them on the
2.4.18 kernel, so they can be ported to 2.4.16, .17 and .19, but that's
like 30 patches unfortunately.  A volunteer for this would be welcome.

Regards,

Joey

-- 
The MS-DOS filesystem is nice for removable media.  -- H. Peter Anvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: status of first round of sarge kernel updates

[Martin Schulze]

dann frazier wrote:
> On Tue, 2005-08-23 at 15:22 -0600, dann frazier wrote:
> > We're getting closer.  Please check this for accuracy:
> >   http://wiki.debian.net/?DebianKernelSargeUpdateStatus
> > 
> > I can try to do hppa this afternoon; any word on m68k, mips & s390?
> 
> Security Team,
>   Is there a way we can take advantage of your autobuilder setup for
> lagging archs?

Only when the source package is in the security queue accompanied
with a binary package the buildds for missing architectures should
try it on their respective architectures.

Regards,

Joey

-- 
It's time to close the windows.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel security upgrades

[Martin Schulze]

Andreas Barth wrote:
> Ok, summarising this means for me:
> 
> If we change the abi for d-i, than a lot of work at a lot of places
> needs to be done.  Definitly possible, but not the thing we want to do
> for each security upgrade.  On the other side, as long as we keep the
> old kernel around, and don't rebuild the CDs, everything is still fine.
> 
> The reason why we cannot keep the old kernels was - beside the fact that
> it's not so nice if we force our users to upgrade their kernel as first
> action - that we're overwriting the kernel source with the upgrade.
> 
> However, as long as the updated kernels are only available via
> security.d.o and via {stable,testing}-proposed-updates, the overwriting
> doesn't happen.
> 
> So, one idea would be to push the updated kernels into sarge only very
> seldom (means: reserve time for exactly one more ABI transition in
> sarge before release, rest happens only in unstable, t-p-u and/or
> testing-security), and decide on each of the following point releases
> whether we want to have the effort to touch all of the mentioned
> packages, or if we keep the updated kernels only on security.d.o.

This paragraph deals only with the current situation of pre-sarge, right?

Once sarge is released, we need to expect a changed abi every month,
even though it may not happen that often, it will happen.  It's not
clear how to handle this...

Regards,

Joey

-- 
The only stupid question is the unasked one.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel-image-2.6.8-ia64 ABI reversion

[Martin Schulze]

Steve Langasek wrote:
> On Fri, Mar 25, 2005 at 08:04:30AM +0100, Martin Schulze wrote:
> 
> > I've also been told that many module packages aren't built the Debian
> > way with a .dsc file that can be used as basis for dpkg-buildpackage
> > or similar.  This makes the problem more difficult.
> 
> The kernel module packages we know of that are built in this fashion are
> being blocked from testing, based on your comments.

Thanks.

waldi, could you be more specific about which other modules packages
aren't built the Debian way in sarge?

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ABI-changing kernel security fixes for sarge

[Martin Schulze]

Matthew Wilcox wrote:
> On Wed, Mar 23, 2005 at 04:09:42PM +0100, Frank Lichtenheld wrote:
> > How big is the chance that we will have another ABI change during
> > sarge's lifetime (100%?). So it can't hurd to figure out the problems
> > with that now independently of our decision in this matter...

I'd say the probability is about 99.%, fwiw.

> Absolutely.  It's bound to happen again.  We also need to figure out
> how to do driver updates during sarge's lifetime.  I suspect virtually
> everybody has had the experience of trying to install woody on a new PC.
> Some of the problems I remember:

For this I have suggested to use a semi-official / unofficial
repository for the installer and kernels.  I agree that there should
be some way to support new hardware, but it doesn't have to be in the
main archive of ftp.debian.org, imho.

Maybe backports.org/d-i/ would be a proper place, maybe not.

> Either that, or we need to commit to a 6-month release goal for etch and
> future releases.  Which wouldn't suck, we used to do it...

We should probably stick to a 6-month release goal anyway and achieve
12-months...

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ABI-changing kernel security fixes for sarge

[Martin Schulze]

Sven Luther wrote:
> > We'd need at least a list of module packages that we need to
> > recompile when a kernel update changes the ABI and all the
> > modules become void.
> > 
> > This also means that we need to be able to rebuild modules from
> > their corresponding source package.
> 
> Notice that enabling auto-NEW for such abi-changes will speed up this process
> considerably, but i was told a whinner for even suggesting such, and bashed
> upon unendlessly.

What is auto-NEW?

> Alos, please find someone else for building the powerpc 2.6.8 and 2.4.27
> security updates as i will most certainly not do that anymore.

I'd assume that another powerpc kernel developer/maintainer is part of
the kernel team then.  Otherwise it will be difficult to support
powerpc kernels security-wise.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel-image-2.6.8-ia64 ABI reversion

[Martin Schulze]

dann frazier wrote:
> It seems to me that the best use of everyone's time would be for the
> kernel team to have an agreement with the security team that we will
> restrict changes to our 2.4.27/2.6.8 kernels in such a way that they can
> start with our unstable packages for sarge updates (with maybe a sarge
> toolchain rebuild).  This way we can keep doing security updates and
> uploading kernels to sid to get some testing, and if $deity forbid we
> need to do an rc4, we've got new bits prepared for that as well.
> There's no reason for us to be working w/ these kernel revs if our
> changes aren't going to make it into sarge.
> 
> Security Team: is there a set of rules for our changes that would make a
> transition like this work?

No set of rules exist.

Security updates should be least intrusive.  However, some security updates
imply ABI changes which opens a can of worms (rebuilt modules needed, maybe
rebuilt d-i, rebuild udebs and the like).

I've also been told that many module packages aren't built the Debian
way with a .dsc file that can be used as basis for dpkg-buildpackage
or similar.  This makes the problem more difficult.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: sarge kernel security transition

[Martin Schulze]

dann frazier wrote:
> The ABI/security discussions have left me with a question - at what
> point does security maintenance of our kernels transition from the
> debian-kernel/testing security teams to the Debian security team, and
> how will we interact with one another?  I assume there will be some
> overlap, but it might be good to define this transition before it
> happens.

When security.debian.org has to be used the security team needs to
be in the loop.  We need to work together with the kernel maintainers,
though.  I believe that this is even more important for the kernel
than for other packages.

> Source Control
> ==
> I assume at some point we'll want to branch off our 2.4.27/2.6.8 kernels
> and lock them down for only security changes.  I think it would be nice
> to keep our svn repo up to date with the security releases, even if it
> is an after-the-fact svn_load_dirs dump.  I assume this would fall to
> the kernel team to maintain, if we choose to do so (versus the security
> team doing the committing).

That should be doable.

> Sarge package vs. latest packages
> =
> When the first security update happens, will the uploaders start with
> whatever is in sarge, or the latest version?

Regular security updates always take care of the version that was released
with the released/frozen Debian distribution.  When the kernel is frozen,
that package should probably be used.  Until that, a more recent version
can be used as basis, I guess, to be judged by the kernel team.

Updates to the once-released distributions will be based on the
latest version in that particular distribution (here: woody, sarge).

> When sarge happens, its likely there will be pending changes in
> kernel-source in svn, and maybe in sid.  Its also possible that some
> kernel-image re-builds may not have propagated into sarge yet.  The
> changes here should be mostly security fixes at this point; however
> we've not formally frozen these packages to my knowledge, so this isn't
> guaranteed.  Maybe now is the time to do that?

Ack.

Regards,

Joey

-- 
The only stupid question is the unasked one.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ABI-changing kernel security fixes for sarge

[Martin Schulze]

Horms wrote:
> Hi,
> 
> I am finally nearing the bottom of my todo list for the 
> up and coming release of kernel-source-2.4.27 2.4.27-9. 
> And to date, the only ABI change I have is for CAN-2005-0449, 
> as per my mail yesterday.
> 
> http://lists.debian.org/debian-boot/2005/03/msg00689.html
> 
> To the best of my knowledge 2.6.8 is in the same position -
> I worked with Andres Salomon on the fix that went in there,
> and the fix that was pulled out, and they are the
> same fixes as for 2.4.27.
> 
> I am quite comfortable with doing a post-sarge security update
> for this if the d-i team feels this is the best approach.
> Though it is a remote exploit, and that needs to be
> taken into due consideration.

We need to discuss how to handle security updates that impose ABI
changes anyway.  The current situation in woody is not acceptable
for sarge.

That is, new package names, and due to the abi change the updates
can't make it into woody.

We'd need at least a list of module packages that we need to
recompile when a kernel update changes the ABI and all the
modules become void.

This also means that we need to be able to rebuild modules from
their corresponding source package.

Regards,

Joey

-- 
Let's call it an accidental feature.  -- Larry Wall

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug #266882 still not fixed

[Martin Schulze]

Horms wrote:
> On Mon, Jan 03, 2005 at 03:25:41PM -0800, Matt Zimmerman wrote:
> > On Wed, Dec 15, 2004 at 11:27:58AM +0900, Horms wrote:
> > 
> > > On Wed, Dec 15, 2004 at 12:59:24AM +0100, Tomasz Malesinski wrote:
> > > > Why hasn't the bug #266882 (CAN-2004-0554 i387.h in kernel: asm
> > > > volatile("fnclex ; fwait");) has not been fixed in 2.4.18 for so long?
> > > 
> > > That and a host of others. Security-Team, Is there ever going to be a 
> > > new kernel for Woody?
> > 
> > Any patches that you can provide would be gratefully received.  The kernel
> > has a huge number of vulnerabilities, and more are discovered all the time.
> > Since the resources of the security team are limited, this work needs to be
> > distributed to package maintainers wherever possible.
> 
> Understood. Would it be helpful if security patches for the 2.4 kernel
> were forwarded to the security-team as they are added to SVN for
> inclusion in unstable and thus testing? Perhaps being better about
> opening entries on the BTS for security bugs, being better about
> posting patches to these entires, and being better about tagging
> them as security would be a mechanism to do this.

Yes, that would help a lot.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Please always Cc to me when replying to me on the lists.

Re: Dropping 386 support

[Martin Schulze]

peter green wrote:
> what about changing the 486 emulation kernel patch so that it completely
> disables itself on non 386 processors

Did you read the patch?  I thougth that was already the case from how
it is invoked.

> this way it would only have security issues on pure 386 which wouldn't be
> supported at all otherwise

Didn't I say that already?

Regards,

Joey

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

Please always Cc to me when replying to me on the lists.

Re: Include kernel with i486 emulation in 3.0r3

[Martin Schulze]

Rob Bradford wrote:
> I think we should push this matter through with an updated kernel in a 3.0r3
> update before the release of sarge. People could then upgrade to that before
> upgrading to sarge. And in my opinion would make the upgrade process much
> simpler and more straightforward. And as respect to security updates, this 
> will
> need to be maintained as long as woody support is maintained.

Adding new features to the kernel in stable besides closing security
bugs is not an option for Debian stable.

Apart from that, it's very questionable if there will ever be another
update to the current stable Debian release.  Hence, you must not
depend on it actually happening.

Besides that, it's still not a guarantee that our 80386 users will
install the kernel prior to updating to sarge.

And just to add more annoyances, we already have the problem with
kernel-image-2.4.18 != kernel-image-2.4.18-1 for Debian stable and
proposed-upgrades.  Where did you want to apply the i486 emulation?

Regards,

Joey

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

Please always Cc to me when replying to me on the lists.

Re: Dropping 386 support

[Martin Schulze]

peter green wrote:
> calling stuff i386 when it will not run natively on a 386 seems like asking
> for confustion to me

True, but we're way to close to a release to fix *that*.  And I'm not
sure that we could easily fix binary-i386 at all..

> why and when was this instruction emulation needed in the first place (that
> is why and when was the userland changed to need it)


Looking in that archive, this was first discussed in April 2003:




   Debian to drop Support for i386? Jochen Friedrich [30]noted that
   due to GCC 3.2 the new libstdc++5 library requires an 80486
   processor or higher, the old 80386 on which Linux was started, is
   no longer supported. Therefore Matthias Klose [31]wondered whether
   Debian should further support the i386 target.

   30. http://bugs.debian.org/185662
   31. http://lists.debian.org/debian-devel-0304/msg01895.html



   Dropping Support for i386? Nathanael Nerode [17]investigated the
   i386 problem and discovered that to maintain binary compatibility
   with C++ packages from other distributions, Debian needs to use the
   i486 version of atomicity.h supplied by GCC. Dagfinn Ilmari
   Mannsåker [18]wrote a small [19]script that compares the speed of
   OpenSSL code for i386 versus i486 on a P-III Mobile.

   17. http://lists.debian.org/debian-devel-0304/msg02112.html
   18. http://lists.debian.org/debian-devel-0304/msg02134.html
   19. http://ilmari.org/sslcmp

Another URL that was inspired by and mentioned on the debian-release
mailing list: 

Hope that helps.

Regards,

Joey

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

Please always Cc to me when replying to me on the lists.

Re: Dropping 386 support

[Martin Schulze]

Andres Salomon wrote:
> Hi,
> 
> The kernel team is considering dropping 386 support (the 80386
> processor, not the i386 arch) from Debian.  Currently, in order to
> support 386, we include a 486 emulation patch (the patch can be viewed
> from here:

> ).
> The patch is a requirement for 386 machines, as debian's gcc
> generates binaries with 486 opcodes.  This patch is known to be
> buggy (see bug #250468), and is considered unreleasable.  The
> members of the kernel team don't have the hardware, time, and/or
> desire to fix it, and the upstream author is too busy to fix it.  As
> d-i rc2 is about to be released (and that is presumably what sarge
> will release with), we need to make the decision what to do.  We
> have two options; we can either keep the patch in, risk releasing
> sarge w/ 386 support containing known security holes, and hope
> someone someone fixes the problem soon; or, we can drop 386 support
> completely.

I've read the patch from within the source package.  If I read it
correctly, the three instructions will only be emulated if the CPU
raised an 'illegal instraction' exception.  Hence, the emulation will
only run on real i386 machines but not on i486 and above.  Hence, the
security problems Arjan mentioned only affect real i386 machines.

Since, only real i386 machines are affected from these security
issues, and they couldn't be supported at all otherwise, I'd say go
with the security problems but document them in the release notes.

I'd be glad if we cold include a working patch, of course.

It's better to tell admins to kick off the users of their i386 boxes
than throw them away, imho.

Regards,

Joey

-- 
We all know Linux is great... it does infinite loops in 5 seconds.
-- Linus Torvalds

Please always Cc to me when replying to me on the lists.

Re: Dropping 386 support

[Martin Schulze]

Andres Salomon wrote:
> Hi,
> 
> The kernel team is considering dropping 386 support (the 80386
> processor, not the i386 arch) from Debian.  Currently, in order to
> support 386, we include a 486 emulation patch (the patch can be viewed
> from here:
> ).
>   The patch is a requirement for 386 machines, as debian's gcc generates 
> binaries with 486 opcodes.  This patch is known to be buggy (see bug 
> #250468), and is considered unreleasable.  The members of the kernel team 
> don't have the hardware, time, and/or desire to fix it, and the upstream 
> author is too busy to fix it.  As d-i rc2 is about to be released (and that 
> is presumably what sarge will release with), we need to make the decision 
> what to do.  We have two options; we can either keep the patch in, risk 
> releasing sarge w/ 386 support containing known security holes, and hope 
> someone someone fixes the problem soon; or, we can drop 386 support 
> completely.

trunk/kernel/source/kernel-source-2.6..8-2.6.8/debian/patches/x86-i486_emu.dpatch:
 unknown location

HTTP Response Status

404 Not Found
Traceback (most recent call last):
  File "/org/svn.debian.org/viewcvs/lib/viewcvs.py", line 3191, in main
request.run_viewcvs()
  File "/org/svn.debian.org/viewcvs/lib/viewcvs.py", line 308, in run_viewcvs
% self.where, '404 Not Found')
ViewCVSException: 404 Not Found: 
trunk/kernel/source/kernel-source-2.6..8-2.6.8/debian/patches/x86-i486_emu.dpatch:
 unknown locatio

Wrong path?  Or is ViewCVS broken currently?

The bug report you've listed isn't quite helpful since the discusssion
ends with Herbert saying that everything seems to be ok and Arjan
moving on to lkml, but no link or whatsoever has been added.

> Reasons for dropping 386 support are as follows:
>   * d-i currently requires at least 20 megs of ram to install.  My 386
> had 4 megs of ram, which required using lowmem w/ potato's installer.  I
> don't see standard d-i as being a viable option for installing debian on
> your 386 anytime soon.

I guess the lowmem version won't help either?

But still you can upgrade your woody i386 to sarge.  Last time I
installed an i386 I was too lazy to wait loads of time and installed
the disk on a Pentibum, then moved the disk to its final location and
booted the i386.  For that, it's not that problematic if the installer
doesn't support i386 as long as the installed system supports it.

>   * Potato ran decently on my 386 (functioning as a NAT box).  I
> upgraded to woody, and it ran much slower.  Sarge will be even worse;
> this will not get better, especially considering 486 opcodes will be
> emulated on the 386.

True.  For i386 Linux 2.2 is said to be the best kernel suited.

Regards,

Joey

-- 
We all know Linux is great... it does infinite loops in 5 seconds.
-- Linus Torvalds

Please always Cc to me when replying to me on the lists.