On Wed, 2022-06-22 at 10:05 +0200, Graham Inggs wrote: > Hi, > > As part of the interim architecture qualification for bookworm, we > request that DSA, the security team, Wanna build, and the toolchain > maintainers review and update their list of known concerns for bookworm > release architectures. > > If the issues and concerns from you or your team are not up to date, > then please follow up to this email (keeping debian-release@l.d.o in CC > to ensure we are notified). > > In particular, we would like to hear any new concerns for riscv64 > (see below). > > Whilst porters remain ultimately responsible for ensuring the > architectures are ready for release, we do expect that you / your team > are willing to assist with clarifications of the concerns and to apply > patches/changes in a timely manner to resolve the concerns. [...] 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. 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. 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. (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.) Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody.
Attachment:
signature.asc
Description: This is a digitally signed message part