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

[Guillem Jover]

Hi!

On Thu, 2023-10-26 at 12:55:32 +0200, Guillem Jover wrote:
> On Thu, 2023-10-26 at 11:40:53 +0200, Emanuele Rocca wrote:
> > Package: dpkg-dev
> > Version: 1.22.0
> > Severity: normal

> > -fstack-clash-protection is supposed to be enabled by default on amd64,
> > arm64, armhf, and armel since dpkg 1.22.0:
> > https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf
> >
> > However, due to an issue in the following conditional in
> > scripts/Dpkg/Vendor/Debian.pm, the flag is only on for amd64 and arm64:
> >
> > if (none { $cpu eq $_ } qw(amd64 arm64 armhf armel)) {
> >
> > The value of $cpu is "arm" for both armhf and armel. Please change the
> > line above to:
> >
> > 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,

On 2023-10-27 04:33, Guillem Jover wrote:
> 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]

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

--
Steve McIntyre, Cambridge, UK. st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

[gene heskett]

On 10/27/23 09:30, Steve McIntyre wrote:
> On Fri, Oct 27, 2023 at 03:23:10PM +0200, Emanuele Rocca wrote:
>> Hi Guillem,
>>
>> On 2023-10-27 04:33, Guillem Jover wrote:
>>> 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.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

[Steve McIntyre]

On Fri, Oct 27, 2023 at 10:30:33AM -0400, gene heskett wrote:
>On 10/27/23 09:30, Steve McIntyre wrote:
>>
>> 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.

--
Steve McIntyre, Cambridge, UK. st...@einval.com

Armed with "Valor": "Centurion" represents quality of Discipline,
Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
concord the digital world while feeling safe and proud.

[Lennart Sorensen]

On Fri, Oct 27, 2023 at 02:29:30PM +0100, Steve McIntyre wrote:
> 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.

--
Len Sorensen

[Wookey]

On 2023-10-27 14:29 +0100, Steve McIntyre wrote:
>
> 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
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

[Guillem Jover]

Hi!

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]

On 2023-11-11 18:57 +0100, Guillem Jover wrote:
> Hi!
>
> On Fri, 2023-10-27 at 20:17:21 -0400, Lennart Sorensen wrote:
> > On Fri, Oct 27, 2023 at 02:29:30PM +0100, Steve McIntyre wrote:
> > > 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.

> 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.

[Steve McIntyre]

+1 on the story and on dropping it.

>> 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.

[Lennart Sorensen]

On Sat, Nov 11, 2023 at 06:57:39PM +0100, Guillem Jover wrote:
> 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.

--
Len Sorensen

[Guillem Jover]

On Sat, 2023-11-11 at 23:52:21 +0000, Steve McIntyre wrote:
> On Sat, Nov 11, 2023 at 08:36:16PM +0000, Wookey wrote:
> >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.

> >> 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.)

> 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