Re: Dropping 386 support
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: Dropping 386 support
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
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.
RE: Dropping 386 support
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
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
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
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
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. http://www-sop.inria.fr/geometrica/team/Sylvain.Pion/progs/mmx-emu/ 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
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
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
Dropping 386 support
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
