info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Enabling -fstack-clash-protection for trixie
11 views
Skip to first unread message
Moritz Mühlenhoff
Aug 6, 2023, 5:30:04 PM8/6/23
to
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
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
Aug 10, 2023, 4:50:04 AM8/10/23
to
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.
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/
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
should too.
Lucas Nussbaum
Aug 10, 2023, 9:00:05 AM8/10/23
to
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
> 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.
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
Aug 10, 2023, 11:00:04 AM8/10/23
to
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.
On 2023-08-10 02:43, Lucas Nussbaum wrote:
> What I would need is a script that customizes a chroot.
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)
Lucas Nussbaum
Aug 12, 2023, 2:21:52 AM8/12/23
to
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
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?
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
Aug 14, 2023, 9:00:04 AM8/14/23
to
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
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.
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
Guillem Jover
Aug 28, 2023, 12:20:04 AM8/28/23
to
Hi!
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
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
Lucas Nussbaum
Oct 25, 2023, 3:10:05 PM10/25/23
to
Sorry for the delay in answering your email.
Is this still of interest? Yes, that would be possible.
Lucas
Emanuele Rocca
Nov 2, 2023, 6:00:06 AM11/2/23
to
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
On 2023-10-25 08:55, Lucas Nussbaum wrote:
> Is this still of interest?
Emanuele
Emanuele Rocca
Nov 25, 2023, 7:50:04 AM11/25/23
to
Hello Lucas!
On 2023-10-25 08:55, Lucas Nussbaum wrote:
> 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
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
[...]
> > 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.
Emanuele
Lucas Nussbaum
Jan 12, 2024, 12:10:04 PMJan 12
to
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
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
0 new messages