On Sat, 2022-07-16 at 06:23 +0300, Adrian Bunk wrote: > On Fri, Jul 15, 2022 at 01:51:21PM +0200, Ben Hutchings wrote: > > > > For i386, I have some concerns about upstream support of the Linux > > kernel. CPU security mitigations for x86 are concentrated on amd64, > > with i386 being left behind. Mitigation of Meltdown required a > > different implementation for i386 that was completed months after the > > public disclosure and was never backported to stable branches. More > > recently it became clear that mitigation of RETbleed was never tested > > on i386, since it didn't even compile there. > > What is the status of RETbleed mitigation on other architectures like arm64? Not known to be vulnerable. > > More generally, on 32-bit systems Linux can only directly access about > > 1 GiB of RAM, and support for large amounts of additional RAM (highmem) > > has been steadily regressing. This is not likely to be fixed. > > Support for 32-bit systems is slowly crumbling away, and the effort that > would be required for the year 2038 problem will likely kill most/all of > them in a few years. That's also true. > The relevant question is rather whether a point is already reached right > now where we can no longer support an architecture as release architecture. > > This is not limited to i386, it is also quite relevant for embedded arm > where new products using 32-bit cpus are still being developed today. New products can build user-space with 64-bit time_t. They don't have Debian's ABI constraints. > > This is not to say that i386, or 32-bit architectures, should be > > dropped as a whole. We've supported installing a 64-bit kernel on i386 > > since etch, though it now requires adding amd64 as a foreign > > architecture. I do think that at some time soon we should stop > > releasing kernel binaries or an installer for i386. > > Speaking with my i386 porter head on, I would rather ask for moving i386 > to ports than dropping all support for i386 hardware. I think we have the following use cases for i386 now: 1. PCs with 64-bit CPUs, with i386 as the primary Debian architecture. This might be the result of keeping an i386 installation through hardware upgrades. 2. PCs with 64-bit CPUs, that need to run i386 binaries that can't be rebuilt for amd64 (proprietary, or unportable). They might have either amd64 or i386 as the primary Debian architecture. 3. PCs with 32-bit CPUs. Moving i386 to ports would clearly serve use case 3 better than dropping the kernel and installer. Keeping i386 as a release architecture, but without a kernel and installer, seems to serve use cases 1 and 2 better. What's not clear is how many users fall into each of these use cases. > > (If we don't make that change for bookworm, then we should probably > > strongly encourage users to use 64-bit kernels on 64-bit capable > > hardware, and document how to install a foreign kernel package.) > > Such users should also migrate to 64-bit userspace. Generally, yes. But this is an easier step than "you need to reinstall" or "try crossgrading, it may or may not break your system completely". Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature.
Attachment:
signature.asc
Description: This is a digitally signed message part