1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.DPKG

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

    From Emanuele Rocca@1:229/2 to All on Thu Oct 26 11:40:02 2023
    XPost: linux.debian.bugs.dist
    From: ema@debian.org

    Package: dpkg-dev
    Version: 1.22.0
    Severity: normal
    Tag: patch

    Hi,

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

    Thanks!
    Emanuele

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Emanuele Rocca on Thu Oct 26 13:00:01 2023
    XPost: linux.debian.bugs.dist
    From: guillem@debian.org

    Hi!

    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.

    I'll try to get a release out during the weekend.

    Thanks,
    Guillem

    From 59234629857aa5910e27d0fadb3dfe29fbb3996d Mon Sep 17 00:00:00 2001
    From: Guillem Jover <guillem@debian.org>
    Date: Thu, 26 Oct 2023 12:48:21 +0200
    Subject: [PATCH] Dpkg::Vendor::Debian: Fix stackclash condition to enable the
    feature

    We were using the cpu to check where to enable this feature, but this
    should have been the arch, as that's what the names we match against
    are. We used these specific names to avoid enabling this feature on
    all arm based architectures where this feature might not be supported,
    and instead only enable it on new ones.

    Closes: #1054583
    ---
    scripts/Dpkg/Vendor/Debian.pm | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm index 000f7e7f5..49935c9d7 100644
    --- a/scripts/Dpkg/Vendor/Debian.pm
    +++ b/scripts/Dpkg/Vendor/Debian.pm
    @@ -337,7 +337,7 @@ sub set_build_features {
    # compiler supports it incorrectly (leads to SEGV)
    $use_feature{hardening}{stackprotector} = 0;
    }
    - if (none { $cpu eq $_ } qw(amd64 arm64 armhf armel)) {
    + if (none { $arch eq $_ } qw(amd64 arm64 armhf armel)) {
    # Stack clash protector only available on amd64 and arm.
    $use_feature{hardening}{stackclash} = 0;
    }
    --
    2.42.0

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Guillem Jover on Fri Oct 27 04:40:01 2023
    XPost: linux.debian.bugs.dist, linux.debian.ports.arm
    From: guillem@debian.org

    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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Emanuele Rocca@1:229/2 to Guillem Jover on Fri Oct 27 15:30:01 2023
    XPost: linux.debian.bugs.dist, linux.debian.ports.arm
    From: ema@debian.org

    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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Lennart Sorensen@1:229/2 to Steve McIntyre on Sat Oct 28 02:40:01 2023
    XPost: linux.debian.bugs.dist, linux.debian.ports.arm
    From: lsorense@csclub.uwaterloo.ca

    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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steve McIntyre@1:229/2 to Emanuele Rocca on Fri Oct 27 15:40:02 2023
    XPost: linux.debian.bugs.dist, linux.debian.ports.arm
    From: steve@einval.com

    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?

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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)