Enabling -fstack-clash-protection for trixie

[Moritz Mühlenhoff]

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

[Emanuele Rocca]

Hi,

Post by Moritz Mühlenhoff
I worked with Lucas a while back and he made an archive rebuild on amd64,
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.

Post by Moritz Mühlenhoff
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.

[Lucas Nussbaum]

Post by Emanuele Rocca
Hi,

Post by Moritz Mühlenhoff
I worked with Lucas a while back and he made an archive rebuild on amd64,
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

[Emanuele Rocca]

Hi,

Post by Lucas Nussbaum
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?

Post by Lucas Nussbaum
Then I will do two archive rebuilds (one with customization, one
without)

Great! Thank you very much.

[Lucas Nussbaum]

Hi Emanuele,

Post by Emanuele Rocca
Hi,

Post by Lucas Nussbaum
What I would need is a script that customizes a chroot.

This is what I'm passing to sbuild --chroot-setup-commands for my
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

[Emanuele Rocca]

Hi Lucas,

Post by Lucas Nussbaum
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

[Lucas Nussbaum]

Post by Emanuele Rocca
Hi Lucas,

Post by Lucas Nussbaum
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.
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

[Emanuele Rocca]

Hi Lucas!

Post by Lucas Nussbaum
Is this still of interest?

Not really, we've flipped the switch now. Thanks nonetheless. :-)

Emanuele

[Emanuele Rocca]

Hello Lucas!

Post by Lucas Nussbaum

Post by Emanuele Rocca
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.
sbuild-createchroot --arch=armhf --components=main,contrib,non-free,non-free-firmware sid /srv/sid-armhf

[...]

Post by Lucas Nussbaum
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

[Lucas Nussbaum]

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

[Guillem Jover]

Hi!

Post by Moritz Mühlenhoff
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,
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