Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel

[Guillem Jover]

Hi!

Package: dpkg-dev
Version: 1.22.0
Severity: normal
-fstack-clash-protection is supposed to be enabled by default on amd64,
https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf
However, due to an issue in the following conditional in
if (none { $cpu eq $_ } qw(amd64 arm64 armhf armel)) {
The value of $cpu is "arm" for both armhf and armel. Please change the
if (none { $cpu eq $_ } qw(amd64 arm64 arm)) {

Ah, nice catch, and sorry! I think this happened due to copy pasting
and modifying one of the surrounding lines. The intention was to use
$arch here, to avoid enabling this on all arm-based arches which might
not support this. I've queued the attached patch for my next push.

Checking now again, I realize Wookey mentioned enabling this for the 3
arm arches (those would be arm64, armhf and armel), so the patch I
provided would match that. But I was wondering now what about armeb and
arm64ilp32? I mean, I assume those should be excluded for now as they
did not get any testing, and they might not even be used/lively(?),
but wanted to ask in any case before pushing. If I don't hear anything
before the release, I'll just push what I proposed, and we can always
enabled these later on if needed.

Thanks,
Guillem

[Emanuele Rocca]

Hi Guillem,

Post by Guillem Jover
Checking now again, I realize Wookey mentioned enabling this for the 3
arm arches (those would be arm64, armhf and armel), so the patch I
provided would match that. But I was wondering now what about armeb and
arm64ilp32? I mean, I assume those should be excluded for now as they
did not get any testing, and they might not even be used/lively(?),

Correct, there has been no testing done on armeb/arm64ilp32 as far as
I'm aware. I'd suggest enabling the feature only on armhf/armel for the
time being.

Thank you for looking into this so quickly!

Emanuele

[Steve McIntyre]

Post by Emanuele Rocca
Hi Guillem,

Post by Guillem Jover
Checking now again, I realize Wookey mentioned enabling this for the 3
arm arches (those would be arm64, armhf and armel), so the patch I
provided would match that. But I was wondering now what about armeb and
arm64ilp32? I mean, I assume those should be excluded for now as they
did not get any testing, and they might not even be used/lively(?),

Correct, there has been no testing done on armeb/arm64ilp32 as far as
I'm aware. I'd suggest enabling the feature only on armhf/armel for the
time being.

Are either of those ports (armeb/arm64ilp32) actually useful / alive
at this point?

[gene heskett]

Post by Steve McIntyre

Post by Emanuele Rocca
Hi Guillem,

Post by Guillem Jover
Checking now again, I realize Wookey mentioned enabling this for the 3
arm arches (those would be arm64, armhf and armel), so the patch I
provided would match that. But I was wondering now what about armeb and
arm64ilp32? I mean, I assume those should be excluded for now as they
did not get any testing, and they might not even be used/lively(?),

Correct, there has been no testing done on armeb/arm64ilp32 as far as
I'm aware. I'd suggest enabling the feature only on armhf/armel for the
time being.

Are either of those ports (armeb/arm64ilp32) actually useful / alive
at this point?

Another architecture you might consider adding is whatever is used in
the banana-pi-m5 boards, its an improvement on the rpi4b, without the
radio, and with all 4 usb ports running at usb3 speeds. With a 4 core
arm64 running at 2GHz, so its a bit faster than the rpi4. With spi
support, it would make a great replacement for the rpi4b. At under $90
USD. Currently running ubuntu-jammy based distro in arm64 flavor, called
armbian. And running several 3d printers here. Good stable boards.

Cheers, Gene Heskett.

[Steve McIntyre]

Post by Steve McIntyre
Are either of those ports (armeb/arm64ilp32) actually useful / alive
at this point?

Another architecture you might consider adding is whatever is used in the
banana-pi-m5 boards, its an improvement on the rpi4b, without the radio, and
with all 4 usb ports running at usb3 speeds. With a 4 core arm64 running at
2GHz, so its a bit faster than the rpi4. With spi support, it would make a
great replacement for the rpi4b. At under $90 USD. Currently running
ubuntu-jammy based distro in arm64 flavor, called armbian. And running
several 3d printers here. Good stable boards.

Gene, please stay out of this. You have no idea what I'm talking about
here.

[Lennart Sorensen]

Post by Steve McIntyre
Are either of those ports (armeb/arm64ilp32) actually useful / alive
at this point?

Not that I have seen. I didn't think anything other than the IXP ever
really used big endian and that's a long time ago. arm64ilp32 seems
to serve less purpose than x32 did (and x32 doesn't seem to be doing
much either). Certainly looks essentially dead at this point.

[Guillem Jover]

Hi!

Post by Lennart Sorensen

Post by Steve McIntyre
Are either of those ports (armeb/arm64ilp32) actually useful / alive
at this point?

Not that I have seen. I didn't think anything other than the IXP ever
really used big endian and that's a long time ago. arm64ilp32 seems
to serve less purpose than x32 did (and x32 doesn't seem to be doing
much either). Certainly looks essentially dead at this point.

While scanning the libc-alpha list recently I read [M] that arm64ilp32
was never upstreamed in Linux nor glibc? If so, I think there's little
point in carrying the arch definitions in dpkg, and I guess that would
not make the cut if requested now (for reference this was requested in
bug #824742). Does anyone know whether it was ever used or it is being
used even if privately/internally somewhere? I'd think that could be a
good argument to make an exception, and keep this for a while still. I
see no usage of this arch in Debian Sources files for example, so it'd
seem safe to remove the arch definition in the Debian context.

[M] <https://sourceware.org/pipermail/libc-alpha/2023-November/152521.html>

For armeb, I assume it was properly upstreamed at the time, and it was
actually used, even if it's currently not in use (like arm) I see tons
of references in Sources files, and thus removing the arch definitions
for either of these would not be safe right now I think.

Thanks,
Guillem

[Wookey]

Post by Guillem Jover
Hi!

Post by Lennart Sorensen

Post by Steve McIntyre
Are either of those ports (armeb/arm64ilp32) actually useful / alive
at this point?

Not that I have seen. I didn't think anything other than the IXP ever
really used big endian and that's a long time ago. arm64ilp32 seems
to serve less purpose than x32 did (and x32 doesn't seem to be doing
much either). Certainly looks essentially dead at this point.

While scanning the libc-alpha list recently I read [M] that arm64ilp32
was never upstreamed in Linux nor glibc? If so, I think there's little
point in carrying the arch definitions in dpkg, and I guess that would
not make the cut if requested now (for reference this was requested in
bug #824742). Does anyone know whether it was ever used or it is being
used even if privately/internally somewhere?

It was being used internally/developmentally for a while (at CISCO)
but, as you observe, only with large kernel and toolchain
patches. Various groups dragged their feet on this to disourage it
becoming a thing we'd all have to maintain for years. I was doing the
debian development at ARM at the time and the bootstrap was never
completed. A few people (largely just CISCO) wanted it quite
badly. Nearly everyone else thought it was not worth the maintenance
effort. No-one has asked about it for quite a few years now (last mail
Oct 2018) so I think we can assume that it is indeed dead and no-one
would notice for years/ever if you removed it from dpkg.

Post by Guillem Jover
For armeb, I assume it was properly upstreamed at the time, and it was
actually used, even if it's currently not in use (like arm) I see tons
of references in Sources files, and thus removing the arch definitions
for either of these would not be safe right now I think.

It is obsolete. It probably doesn't work any more having been unused
since the early days of the NSLU2/Sarge (circa 2006/2007). It might
still have been in use till 2011ish?. As you say it should probably be
removed from upstream sources before it is removed from
dpkg. Interesting question on how much effort (if any) (and when)
should be applied to tidying up stuff like this which is simply no
longer in use. If/when 'arm' is removed 'armeb' should certainly go
with it.

Wookey

[Steve McIntyre]

Post by Wookey

Post by Guillem Jover
Hi!

Post by Lennart Sorensen

Post by Steve McIntyre
Are either of those ports (armeb/arm64ilp32) actually useful / alive
at this point?

Not that I have seen. I didn't think anything other than the IXP ever
really used big endian and that's a long time ago. arm64ilp32 seems
to serve less purpose than x32 did (and x32 doesn't seem to be doing
much either). Certainly looks essentially dead at this point.

While scanning the libc-alpha list recently I read [M] that arm64ilp32
was never upstreamed in Linux nor glibc? If so, I think there's little
point in carrying the arch definitions in dpkg, and I guess that would
not make the cut if requested now (for reference this was requested in
bug #824742). Does anyone know whether it was ever used or it is being
used even if privately/internally somewhere?

It was being used internally/developmentally for a while (at CISCO)
but, as you observe, only with large kernel and toolchain
patches. Various groups dragged their feet on this to disourage it
becoming a thing we'd all have to maintain for years. I was doing the
debian development at ARM at the time and the bootstrap was never
completed. A few people (largely just CISCO) wanted it quite
badly. Nearly everyone else thought it was not worth the maintenance
effort. No-one has asked about it for quite a few years now (last mail
Oct 2018) so I think we can assume that it is indeed dead and no-one
would notice for years/ever if you removed it from dpkg.

+1 on the story and on dropping it.

Post by Wookey

Post by Guillem Jover
For armeb, I assume it was properly upstreamed at the time, and it was
actually used, even if it's currently not in use (like arm) I see tons
of references in Sources files, and thus removing the arch definitions
for either of these would not be safe right now I think.

It is obsolete. It probably doesn't work any more having been unused
since the early days of the NSLU2/Sarge (circa 2006/2007). It might
still have been in use till 2011ish?. As you say it should probably be
removed from upstream sources before it is removed from
dpkg. Interesting question on how much effort (if any) (and when)
should be applied to tidying up stuff like this which is simply no
longer in use. If/when 'arm' is removed 'armeb' should certainly go
with it.

armeb was mostly before my involvement in any arm stuff, as Wookey
says. It did at least have some life as a functioning port, at
least. I'd agree on leaving it in place for now, assuming it's not
causing any trouble in terms of maintenance / support.

[Guillem Jover]

Post by Steve McIntyre

Post by Wookey
It was being used internally/developmentally for a while (at CISCO)
but, as you observe, only with large kernel and toolchain
patches. Various groups dragged their feet on this to disourage it
becoming a thing we'd all have to maintain for years. I was doing the
debian development at ARM at the time and the bootstrap was never
completed. A few people (largely just CISCO) wanted it quite
badly. Nearly everyone else thought it was not worth the maintenance
effort. No-one has asked about it for quite a few years now (last mail
Oct 2018) so I think we can assume that it is indeed dead and no-one
would notice for years/ever if you removed it from dpkg.

+1 on the story and on dropping it.

Thanks for the background info! Ok then, I've queued its removal
from dpkg.

Post by Steve McIntyre

Post by Wookey

Post by Guillem Jover
For armeb, I assume it was properly upstreamed at the time, and it was
actually used, even if it's currently not in use (like arm) I see tons
of references in Sources files, and thus removing the arch definitions
for either of these would not be safe right now I think.

It is obsolete. It probably doesn't work any more having been unused
since the early days of the NSLU2/Sarge (circa 2006/2007). It might
still have been in use till 2011ish?. As you say it should probably be
removed from upstream sources before it is removed from
dpkg. Interesting question on how much effort (if any) (and when)
should be applied to tidying up stuff like this which is simply no
longer in use. If/when 'arm' is removed 'armeb' should certainly go
with it.

Sorry, I was probably not clear, with the "references in Sources
files" I meant mainly references in debian/control (in fields), that
trickle down into Sources repo indices, where on Debian, AFAIUI dak
might be unhappy about unknown architectures once its host gets
updated to a version of dpkg that does not list them (but perhaps
that's only on upload but not for existing ones in the archive). I
think that could be the main blocker for such removals. Whether
upstream kernels and toolchains might keep, drop, or lack support for
existing ports, could be indicators of their liveliness but I don't
think should be the only deciding factors, just important ones to
consider. (I'm thinking about the recent ia64 removal from Linux and
probably glibc for example.)

Post by Steve McIntyre
armeb was mostly before my involvement in any arm stuff, as Wookey
says. It did at least have some life as a functioning port, at
least. I'd agree on leaving it in place for now, assuming it's not
causing any trouble in terms of maintenance / support.

Ah, I just had a flash from the past, about chatting about the port
face to face with Lennert Buytenhek. :) For dpkg there's not really
much of a maintenance burden. My concern has increasingly been that
these (dead/unused) ports can confuse or be a burden instead to
diligent package maintainers, when they try to handle or list all
such ports in packages.

I've now also gone over the current dpkg arch definitions and tried to
locally restrict or remove obsolete/non-existing things, going from the
current «dpkg-architecture -L» list of 524 arches down to 238, and will
see what's safe to push out. :) Checking now for references to ports
such as arm or armeb in Sources indices does not look too bad (around
40 source packages for arm and 10 for armeb), so I might do a better
analysis and then check how these could be shadowed for linux-any (as
I also realized now these are part of the base CPU definitions which
cannot be removed as that would affect any other port), and perhaps
propose their shadowing too alongside a mass bug filing to remove
such references in a bit if people would like to see such cleanup
getting done, otherwise keeping them for a while also seems fine to me.

Thanks,
Guillem

[Lennart Sorensen]

Post by Guillem Jover
While scanning the libc-alpha list recently I read [M] that arm64ilp32
was never upstreamed in Linux nor glibc? If so, I think there's little
point in carrying the arch definitions in dpkg, and I guess that would
not make the cut if requested now (for reference this was requested in
bug #824742). Does anyone know whether it was ever used or it is being
used even if privately/internally somewhere? I'd think that could be a
good argument to make an exception, and keep this for a while still. I
see no usage of this arch in Debian Sources files for example, so it'd
seem safe to remove the arch definition in the Debian context.
[M] <https://sourceware.org/pipermail/libc-alpha/2023-November/152521.html>
For armeb, I assume it was properly upstreamed at the time, and it was
actually used, even if it's currently not in use (like arm) I see tons
of references in Sources files, and thus removing the arch definitions
for either of these would not be safe right now I think.

armeb definitely was used in systems.

Certainly everything I could find about arm64ilp32 seems to indicate it
was experimental and support has been deleted from gcc and libc quite
a long time ago at least as far as I can tell. I sure can't find the
code in the kernel anymore unless it is well hidden.

[Wookey]

Post by Steve McIntyre
Are either of those ports (armeb/arm64ilp32) actually useful / alive
at this point?

No, but if someone did try to build a package for those it would be
incorrect for dpkg to enable these flags. The chances of anyone
actually doing that are pretty low, but correct code is a good thing.

Wookey