Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns
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?
> 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.
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.
> 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.
> (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.
> Ben.
cu
Adrian
Reply to: