Dropping 386 support

[Andres Salomon]

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:
<http://svn.debian.org/viewcvs/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/x86-i486_emu.dpatch>).
  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.

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.
  * 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.
  * Memory requirements have expanded, as have disk requirements.  i386
kernels require an initrd, and use more memory than, say, 2.0 or 2.2
kernels.
  * Embedded 386 users will end up creating custom kernels, anyways;
they will want to strip out unneeded functionality to pare down the
memory requirements of the kernel.  They can, of course, also apply the
486 emulation patch to their kernel.

Reasons for keeping 386 support:
  * 386 users currently running woody will be left out in the cold, wrt
security updates.  Of course, there's nothing stopping them from
coordinating with the security team to offer security updates for woody
long after sarge releases; I wouldn't bet on it, though.

Given d-i's memory requirements, and the fact that you'd be hard-pressed
to find a (desktop) 386 system with more than 16 megs of memory, I don't
consider debian 3.1 to be a viable candidate for installing onto a 386.
Also, note that if we do drop 386 support, I will rename
kernel-image-2.6.8-386 to kernel-image-2.6.8-486, and update
optimizations accordingly.

Comments?  Thoughts?


-- 
Andres Salomon <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

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:
> <http://svn.debian.org/viewcvs/kernel/trunk/kernel/source/kernel-source-2.6..8-2.6.8/debian/patches/x86-i486_emu.dpatch>).
>   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.

Re: Dropping 386 support

[Steve Langasek]

On Sun, Oct 03, 2004 at 08:55:24AM +0200, Martin Schulze wrote:
> > 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?

The 20MB figure is an optimistic extrapolation from the most recent
successful lowmem tests Joey Hess has done.

> 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.

True, though this doesn't change any of the other problems with trying
to support 80386 for sarge -- most notably, that there's no emulation
patch available that doesn't contain a root hole, no one who seems
comfortable working on a fix for this problem, and reservations from the
kernel team about including such a Debian-specific patch in the mainline
kernel packages.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Dropping 386 support

[Andres Salomon]

On Sun, 03 Oct 2004 08:55:24 +0200, Martin Schulze wrote:

> 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:
>> <http://svn.debian.org/viewcvs/kernel/trunk/kernel/source/kernel-source-2.6..8-2.6.8/debian/patches/x86-i486_emu.dpatch>).
[...]
> 
> 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?
> 
> 

Whoops, too many dots in kernel-source-2.6.8-2.6.8. That should be:
<http://svn.debian.org/viewcvs/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/x86-i486_emu.dpatch>


> 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.
> 
> 
> 


It ends w/ Herbert saying he'll punt it onto the new kernel maintainers.
The thread can be read here:
<http://thread.gmane.org/gmane.linux.kernel/205839>. People find various
problems w/ the patch.   Alan Cox proposes an interesting alternative
(trapping SIGILLs and emulating the necessary instructions in userspace),
but I haven't seen any implementations of it.


>> 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?
> 
> 
> 

I believe the 20meg version *is* the lowmem install target.  The standard
one requires something like 32 megs, last I heard.

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:

> <http://svn.debian.org/viewcvs/kernel/trunk/kernel/source/kernel-source-2.6..8-2.6.8/debian/patches/x86-i486_emu.dpatch>).
> 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

[Joey Hess]

Andres Salomon wrote:
> Given d-i's memory requirements, and the fact that you'd be hard-pressed
> to find a (desktop) 386 system with more than 16 megs of memory, I don't
> consider debian 3.1 to be a viable candidate for installing onto a 386.
> Also, note that if we do drop 386 support, I will rename
> kernel-image-2.6.8-386 to kernel-image-2.6.8-486, and update
> optimizations accordingly.

I have no opinion on 386 support, but it's too late to go changing
kernel package names for sarge. d-i relies on the current names, and
this sort of transition will likely set us back days or weeks on our
release schedule.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Dropping 386 support

[Andres Salomon]

On Sun, 03 Oct 2004 11:59:33 +0200, Martin Schulze wrote:
[...]
> 
> 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.
> 

That is correct; the patch is only vulnerable if one of those three
instructions (bswap, cmpxchg, or xadd) generates a SIGILL.  That we know
of, anyways (there's always the possibility that some logic bug exists in
the regs->eip processing, but nothing I noticed w/ a cursory glance).


> 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 like to see them documented elsewhere, so that people upgrading from
woody get a big fat warning that the kernel they're about to install has
security holes (if and only if their machine lacks the capability to
handle bswap/cmpxchg/xadd).


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

The more I think about it, the more I like the idea of having this in
userspace; instead of having people upgrade to a new kernel before
allowing glibc to upgrade, we could simply have an ld preloaded library
that gets installed (or, include it right in glibc?).  No reboot, no need
to hassle users.. But, I'm not willing to implement that, and I haven't
seen it anywhere.

 has
the mmx stuff Alan mentioned.


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

Re: Dropping 386 support

[Adeodato Simó]

* Joey Hess [Sun, 03 Oct 2004 12:54:21 -0400]:
> Andres Salomon wrote:
> > Given d-i's memory requirements, and the fact that you'd be hard-pressed
> > to find a (desktop) 386 system with more than 16 megs of memory, I don't
> > consider debian 3.1 to be a viable candidate for installing onto a 386.
> > Also, note that if we do drop 386 support, I will rename
> > kernel-image-2.6.8-386 to kernel-image-2.6.8-486, and update
> > optimizations accordingly.

> I have no opinion on 386 support, but it's too late to go changing
> kernel package names for sarge. d-i relies on the current names, and
> this sort of transition will likely set us back days or weeks on our
> release schedule.

  would it be a problem to actually update optimizations as Andres
  proposes, but without changing packages? that is, *if* finally sarge
  ships without plain i386 support and that is clearly noted in the
  release notes.

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Aphex Twin - Xtal
 
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself.  Therefore all
progress depends on the unreasonable man.
-- George Bernard Shaw

Re: Dropping 386 support

[Steve Langasek]

On Mon, Oct 04, 2004 at 12:19:16AM +0200, Adeodato Simó wrote:
> * Joey Hess [Sun, 03 Oct 2004 12:54:21 -0400]:
> > Andres Salomon wrote:
> > > Given d-i's memory requirements, and the fact that you'd be hard-pressed
> > > to find a (desktop) 386 system with more than 16 megs of memory, I don't
> > > consider debian 3.1 to be a viable candidate for installing onto a 386.
> > > Also, note that if we do drop 386 support, I will rename
> > > kernel-image-2.6.8-386 to kernel-image-2.6.8-486, and update
> > > optimizations accordingly.

> > I have no opinion on 386 support, but it's too late to go changing
> > kernel package names for sarge. d-i relies on the current names, and
> > this sort of transition will likely set us back days or weeks on our
> > release schedule.

>   would it be a problem to actually update optimizations as Andres
>   proposes, but without changing packages? that is, *if* finally sarge
>   ships without plain i386 support and that is clearly noted in the
>   release notes.

The d-i images really need to be built from kernel-image packages that
are in the archive at the time we ship.  Optimizing for 486 isn't a very
good reason on its own to force another kernel build cycle.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Dropping 386 support

[Joey Hess]

Steve Langasek wrote:
> The d-i images really need to be built from kernel-image packages that
> are in the archive at the time we ship.  Optimizing for 486 isn't a very
> good reason on its own to force another kernel build cycle.

I had not even considered the impact of changing the optimisation, only
of changing the package name. Steve's right, and we'd have to test the
new build too. Also, doesn't optimising for 486 slow things down more
than the current 386 builds on non-486 machines? The 386 build is
installed whenever we cannot guess the right processor to optimise for.
It's also installed all the time when the common netinst CD image is
used, since we can only fit on kernel image on that CD.

-- 
see shy jo


signature.asc
Description: Digital signature

RE: Dropping 386 support

[peter green]

calling stuff i386 when it will not run natively on a 386 seems like asking
for confustion to me

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

> -Original Message-
> From: Adeodato Simó [mailto:[EMAIL PROTECTED]
> Sent: 03 October 2004 23:19
> To: debian-kernel@lists.debian.org; debian-release@lists.debian.org;
> debian-boot@lists.debian.org
> Subject: Re: Dropping 386 support
>
>
> * Joey Hess [Sun, 03 Oct 2004 12:54:21 -0400]:
> > Andres Salomon wrote:
> > > Given d-i's memory requirements, and the fact that you'd be
> hard-pressed
> > > to find a (desktop) 386 system with more than 16 megs of
> memory, I don't
> > > consider debian 3.1 to be a viable candidate for installing
> onto a 386.
> > > Also, note that if we do drop 386 support, I will rename
> > > kernel-image-2.6.8-386 to kernel-image-2.6.8-486, and update
> > > optimizations accordingly.
>
> > I have no opinion on 386 support, but it's too late to go changing
> > kernel package names for sarge. d-i relies on the current names, and
> > this sort of transition will likely set us back days or weeks on our
> > release schedule.
>
>   would it be a problem to actually update optimizations as Andres
>   proposes, but without changing packages? that is, *if* finally sarge
>   ships without plain i386 support and that is clearly noted in the
>   release notes.
>
> --
> Adeodato Simó
> EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
> Listening to: Aphex Twin - Xtal
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself.  Therefore all
> progress depends on the unreasonable man.
> -- George Bernard Shaw
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]

Re: Dropping 386 support

[Rahmat M. Samik-Ibrahim]

On Sun, 2004-10-03 at 05:01, Andres Salomon wrote:

> Reasons for keeping 386 support:

I am not sure if this is still true. But in the past, "386" was
the safest bet to run any kind of non-Intel processor, especially
notebooks.

regards,

-- 
Rahmat M.  Samik-Ibrahim -- vLSM.org  -- http://rms46.vLSM.org/ --
Fetch my GNUPG public key at http://rms46.vlsm.org/pgp/pub.txt ---



signature.asc
Description: This is a digitally signed message part

Re: Dropping 386 support

[Christoph Hellwig]

On Sun, Oct 03, 2004 at 07:54:12PM -0400, Joey Hess wrote:
> Steve Langasek wrote:
> > The d-i images really need to be built from kernel-image packages that
> > are in the archive at the time we ship.  Optimizing for 486 isn't a very
> > good reason on its own to force another kernel build cycle.
> 
> I had not even considered the impact of changing the optimisation, only
> of changing the package name. Steve's right, and we'd have to test the
> new build too. Also, doesn't optimising for 486 slow things down more
> than the current 386 builds on non-486 machines? The 386 build is
> installed whenever we cannot guess the right processor to optimise for.
> It's also installed all the time when the common netinst CD image is
> used, since we can only fit on kernel image on that CD.

There's not really 486-optimized kernel as both core are so simple that
gcc isn't doing any special instruction scheduling.  The new
instructions in the 486 are pretty important, though - e.g. bswap can
optimize endian swapping quite nicely and cmpxchg is required for dri.

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

[peter green]

what about changing the 486 emulation kernel patch so that it completely
disables itself on non 386 processors

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


> -Original Message-
> From: Martin Schulze [mailto:[EMAIL PROTECTED]
> Sent: 04 October 2004 14:33
> To: Peter Green
> Cc: Adeodato Simó; debian-kernel@lists.debian.org;
> debian-release@lists.debian.org; debian-boot@lists.debian.org
> Subject: Re: Dropping 386 support
>
>
> 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:
>
>
> <http://www.debian.org/News/weekly/2003/17/>
>
>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
>
> <http://www.debian.org/News/weekly/2003/18/>
>
>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: <http://people.debian.org/~joey/pr/3.1/i386.html>
>
> 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.
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]

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.