Re: Enabling -fstack-clash-protection for trixie [armhf rebuild]
Hi, I finally got time to perform those archive rebuilds. Results are available at http://qa-logs.debian.net/2024/01/11/ I did a first archive rebuild (all packages on arm64, armhf, armel), and then did a second one, restricted to packages that failed at on at least one architecture. Results in terms of packages counts are: 384 FAIL.all # failing on three architectures 423 FAIL.arm64 29 FAIL.arm64.but.OK.armhf 1062 FAIL.armel 668 FAIL.armel.but.OK.arm64 237 FAIL.armel.but.OK.armhf 851 FAIL.armhf 462 FAIL.armhf.but.OK.arm64 25 FAIL.armhf.but.OK.armel Let me know if you need more information. Best, Lucas
Re: Enabling -fstack-clash-protection for trixie [armhf rebuild]
Hello Lucas! On 2023-10-25 08:55, Lucas Nussbaum wrote: > On 14/08/23 at 14:53 +0200, Emanuele Rocca wrote: > > I'm not sure how the deal with AWS is (how many credits we have > > available and such) but would it be possible to repeat the experiment > > for armhf too? The Neoverse cpus can run 32 bit code natively, so at > > least from the point of view of the underlying hardware this shouldn't > > be a problem. > > > > I've tried the following on a m6g.medium and it did the right thing: > > > > sbuild-createchroot --arch=armhf > > --components=main,contrib,non-free,non-free-firmware sid /srv/sid-armhf [...] > Sorry for the delay in answering your email. > Is this still of interest? Yes, that would be possible. If the offer is still valid, yes please. :-) Emanuele
Re: Enabling -fstack-clash-protection for trixie [armhf rebuild]
Hi Lucas! On 2023-10-25 08:55, Lucas Nussbaum wrote: > Is this still of interest? Not really, we've flipped the switch now. Thanks nonetheless. :-) Emanuele
Re: Enabling -fstack-clash-protection for trixie [armhf rebuild]
On 14/08/23 at 14:53 +0200, Emanuele Rocca wrote: > Hi Lucas, > > On 2023-08-12 08:18, Lucas Nussbaum wrote: > > Results: > > http://qa-logs.debian.net/2023/08/11.stackclash-arm/ > > > > I only included logs for builds that succeeded in a vanilla build, > > but failed with the custom build. > > Thank you so much, this is great! There's not much fallout. > > I'm not sure how the deal with AWS is (how many credits we have > available and such) but would it be possible to repeat the experiment > for armhf too? The Neoverse cpus can run 32 bit code natively, so at > least from the point of view of the underlying hardware this shouldn't > be a problem. > > I've tried the following on a m6g.medium and it did the right thing: > > sbuild-createchroot --arch=armhf > --components=main,contrib,non-free,non-free-firmware sid /srv/sid-armhf Hi, Sorry for the delay in answering your email. Is this still of interest? Yes, that would be possible. Lucas
Re: Enabling -fstack-clash-protection for trixie
Hi! On Sun, 2023-08-06 at 23:25:23 +0200, Moritz Mühlenhoff wrote: > Following the procedure to modify default dpkg-buildflags I propose to > enable -fstack-clash-protection on amd64. The bug for dpkg tracking this > is #918914. > > | -fstack-clash-protection > | Generate code to prevent stack clash style attacks. When this option > | is enabled, the compiler will only allocate one page of stack space > | at a time and each page is accessed immediately after allocation. > | Thus, it prevents allocations from jumping over any stack guard page > | provided by the operating system. > > This has been enabled on other distros for many years already (e.g. > Fedora since 27, RHEL since 8, OpenSUSE since 15.1, Ubuntu since 19.10). > > I worked with Lucas a while back and he made an archive rebuild on amd64, > only a minimal list of packages will need to be adapted: > http://qa-logs.debian.net/2023/05/24/ > > The open question is whether to also enable this for arm64, mips64el, > ppc64el, riscv and s390x. I'm adding the respective porter lists, if there's > consensus among porters of a given arch other than amd64 to also add > the flag, please post a followup to #918914. Given the results from the rebuilds for amd64 and arm64 with minimal fallout, and no complaints, I'm going to enable this for amd64 and the three arm arches (arm64, armhf and armel) with dpkg 1.22.0, to be uploaded later today. We can later on modify the set of architectures (by request from porters) or tune them if it ends up causing problems. Thanks, Guillem
Re: Enabling -fstack-clash-protection for trixie
Hi Lucas, On 2023-08-12 08:18, Lucas Nussbaum wrote: > Results: > http://qa-logs.debian.net/2023/08/11.stackclash-arm/ > > I only included logs for builds that succeeded in a vanilla build, > but failed with the custom build. Thank you so much, this is great! There's not much fallout. I'm not sure how the deal with AWS is (how many credits we have available and such) but would it be possible to repeat the experiment for armhf too? The Neoverse cpus can run 32 bit code natively, so at least from the point of view of the underlying hardware this shouldn't be a problem. I've tried the following on a m6g.medium and it did the right thing: sbuild-createchroot --arch=armhf --components=main,contrib,non-free,non-free-firmware sid /srv/sid-armhf Cheers, Emanuele
Re: Enabling -fstack-clash-protection for trixie
Hi Emanuele, On 10/08/23 at 16:57 +0200, Emanuele Rocca wrote: > Hi, > > On 2023-08-10 02:43, Lucas Nussbaum wrote: > > What I would need is a script that customizes a chroot. > > This is what I'm passing to sbuild --chroot-setup-commands for my > builds: > > sbuild --chroot-setup-commands='printf "APPEND CFLAGS > -fstack-clash-protection\nAPPEND CXXFLAGS -fstack-clash-protection\n" > > /etc/dpkg/buildflags.conf' > > Would a script with just that printf command work for collab-qa-tools? Apparently yes. Results: http://qa-logs.debian.net/2023/08/11.stackclash-arm/ I only included logs for builds that succeeded in a vanilla build, but failed with the custom build. Lucas
Re: Enabling -fstack-clash-protection for trixie
Hi, On 2023-08-10 02:43, Lucas Nussbaum wrote: > What I would need is a script that customizes a chroot. This is what I'm passing to sbuild --chroot-setup-commands for my builds: sbuild --chroot-setup-commands='printf "APPEND CFLAGS -fstack-clash-protection\nAPPEND CXXFLAGS -fstack-clash-protection\n" > /etc/dpkg/buildflags.conf' Would a script with just that printf command work for collab-qa-tools? > Then I will do two archive rebuilds (one with customization, one > without) Great! Thank you very much.
Re: Enabling -fstack-clash-protection for trixie
On 10/08/23 at 10:49 +0200, Emanuele Rocca wrote: > Hi, > > On 2023-08-06 11:25, Moritz Mühlenhoff wrote: > > I worked with Lucas a while back and he made an archive rebuild on amd64, > > only a minimal list of packages will need to be adapted: > > http://qa-logs.debian.net/2023/05/24/ > > Can we do the same for arm64? As far as I understand the archive rebuild > system runs on AWS, so that should be possible I think? I don't expect > big differences compared to the amd64 results, but still it would be > a nice test to perform. Yes. What I would need is a script that customizes a chroot. See https://salsa.debian.org/lucas/collab-qa-tools/-/blob/master/modes/stackclash and other examples in https://salsa.debian.org/lucas/collab-qa-tools/-/tree/master/modes Then I will do two archive rebuilds (one with customization, one without) Lucas
Re: Enabling -fstack-clash-protection for trixie
Hi, On 2023-08-06 11:25, Moritz Mühlenhoff wrote: > I worked with Lucas a while back and he made an archive rebuild on amd64, > only a minimal list of packages will need to be adapted: > http://qa-logs.debian.net/2023/05/24/ Can we do the same for arm64? As far as I understand the archive rebuild system runs on AWS, so that should be possible I think? I don't expect big differences compared to the amd64 results, but still it would be a nice test to perform. > The open question is whether to also enable this for arm64 Yes please. Ubuntu (among others) did it several years ago and we really should too.
Enabling -fstack-clash-protection for trixie
Following the procedure to modify default dpkg-buildflags I propose to enable -fstack-clash-protection on amd64. The bug for dpkg tracking this is #918914. | -fstack-clash-protection | Generate code to prevent stack clash style attacks. When this option | is enabled, the compiler will only allocate one page of stack space | at a time and each page is accessed immediately after allocation. | Thus, it prevents allocations from jumping over any stack guard page | provided by the operating system. This has been enabled on other distros for many years already (e.g. Fedora since 27, RHEL since 8, OpenSUSE since 15.1, Ubuntu since 19.10). I worked with Lucas a while back and he made an archive rebuild on amd64, only a minimal list of packages will need to be adapted: http://qa-logs.debian.net/2023/05/24/ The open question is whether to also enable this for arm64, mips64el, ppc64el, riscv and s390x. I'm adding the respective porter lists, if there's consensus among porters of a given arch other than amd64 to also add the flag, please post a followup to #918914. Cheers, Moritz