• Bug#1055605: fstack-clash-protection hardening change breaks building p

    From Hugo Melder@1:229/2 to All on Wed Nov 8 19:10:01 2023
    XPost: linux.debian.bugs.dist
    From: hugo.melder@gmail.com

    Package: dpkg-dev
    Version: 1.22.0
    Severity: important

    Hi,

    The recent change (https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf) breaks building Debian packages with clang on arm64. LLVM does not have -fstack-clash-protection enabled on aarch64 (https://reviews.llvm.org/D96007).

    Here is the original bug report for adding clash protection: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918914

    The GNUstep Objective-C 2.0 toolchain depends on Clang as GCC does not have newer Objective-C features such as ARC, properties, and blocks.

    Fedora enables stack-clash-protection based on the toolchain (https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/blob/c0bad810b4b47086f58e7537e258333b14c92c45/f/rpmrc#_77), and omits the flag when the compiler is not gcc.

    I would suggest either checking for the compiler (if possible), or disabling it for aarch64 until Clang has support for it as well. Right now, projects like Grand Central Dispatch (libdispatch) or other projects with -Werror turned on, refuse to build.
    <html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">
    Package: dpkg-dev</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Version: 1.22.0</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style="caret-color:
    rgb(0, 0, 0); color: rgb(0, 0, 0);">Severity: important</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Hi,</span><
    br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">The recent change (</span><a href="https://git.dpkg.org/cgit/dpkg/dpkg.
    git/diff/?id=11efff1bf">https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf</a><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">) breaks building Debian packages with clang on arm64. LLVM does not have -fstack-clash-protection enabled
    on aarch64 (</span><a href="https://reviews.llvm.org/D96007">https://reviews.llvm.org/D96007</a><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">).</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br style="caret-color: rgb(
    0, 0, 0); color: rgb(0, 0, 0);"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Here is the original bug report for adding clash protection:&nbsp;</span><a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918914">https://bugs.debian.
    org/cgi-bin/bugreport.cgi?bug=918914</a><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">The GNUstep Objective-C 2.0
    toolchain depends on Clang as GCC does not have newer Objective-C features such as ARC, properties, and blocks.</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style="
    caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Fedora enables stack-clash-protection based on the toolchain (</span><a href="https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/blob/c0bad810b4b47086f58e7537e258333b14c92c45/f/rpmrc#_77">
    https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/blob/c0bad810b4b47086f58e7537e258333b14c92c45/f/rpmrc#_77</a><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">), and omits the flag when the compiler is not gcc.</span><br
    style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">I would suggest either checking for the compiler (if possible), or disabling
    it for aarch64 until Clang has support for it as well. Right now, projects like Grand Central Dispatch (libdispatch) or other projects with -Werror turned on, refuse to build.</span></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Hugo Melder on Fri Nov 24 02:00:01 2023
    XPost: linux.debian.bugs.dist
    From: guillem@debian.org

    Control: severity -1 wishlist

    Hi!

    On Wed, 2023-11-08 at 19:00:59 +0100, Hugo Melder wrote:
    Package: dpkg-dev
    Version: 1.22.0
    Severity: important

    The recent change (https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf)
    breaks building Debian packages with clang on arm64.

    So in principle, the default compiler in Debian is gcc, and the
    default flags up to now have been targeting that, plus the specific
    gcc version that is the current default. So packages using clang have
    had to amend those flags by themselves.

    LLVM does not have
    -fstack-clash-protection enabled on aarch64 (https://reviews.llvm.org/D96007).

    Hmm that's unfortunate.

    The GNUstep Objective-C 2.0 toolchain depends on Clang as GCC does not
    have newer Objective-C features such as ARC, properties, and blocks.

    Is that being used or packaged in Debian? (Just curious.)

    Fedora enables stack-clash-protection based on the toolchain (https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/blob/c0bad810b4b47086f58e7537e258333b14c92c45/f/rpmrc#_77),
    and omits the flag when the compiler is not gcc.

    I would suggest either checking for the compiler (if possible), or
    disabling it for aarch64 until Clang has support for it as well.

    Unfortunately I don't think there's a machine readable way to discern
    between them, that might not involve either parsing stuff like
    --version/--help or pre-processing or compiling a program, which
    seem rather undesirable. This would probably need to be specified by
    the caller somehow.

    I've got some pending discussion in the works for a revamp of the
    build flags handling, which includes also trying to cover multiple
    toolchains, which would hopefully cover this case. But as it is, I'd
    say as of now, packages that use something that is not the default
    compiler at the expected version, are on their own.

    Right now, projects like Grand Central Dispatch (libdispatch) or
    other projects with -Werror turned on, refuse to build.

    I tried to look for that in Debian and could not find it, do you have
    a pointer? But in any case, while I think supporting other toolchains
    would be ideal and worthwhile, building packages with blanket -Werror
    has always seemed like a bad idea because it then can cause this sort
    of thing (or other unexpected errors due to newly introduced warnings).

    Thanks,
    Guillem

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