1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Rebuilds to enable PAC and BTI support on arm64

    From Sebastian Ramacher@21:1/5 to All on Mon Oct 28 23:00:01 2024
    Hi,

    since dpkg 1.22.0 the additional hardening flags to enable Pointer Authentication (PAC) and Branch Target Identification (BTI)
    on arm64 are enabled by default. See [1] for the discussion to enable
    these flags.

    To have the desired effect for the next release and have some time
    to catch regressions, I have started with scheduling rebuilds of
    packages that have not been built since the change in the default flags.
    While the change of flags only affects arm64, packages building
    Multi-Arch: same binaries require consistent versions on all
    architectures. For those packages, the rebuilds have been scheduled on
    all architectures.

    Note that all builds have been scheduled with build priority -50, so
    builds of uploads have higher priority and will be picked up by the
    buildds before PAC/BTI rebuilds.

    Thanks to Emanuele Rocca for identifying the list of packages that have
    to be rebuilt to gain PAC/BTI support.

    Cheers

    [1] https://lists.debian.org/debian-dpkg/2022/05/msg00022.html
    --
    Sebastian Ramacher

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Holger Levsen@21:1/5 to Sebastian Ramacher on Thu Oct 31 12:40:01 2024
    On Mon, Oct 28, 2024 at 10:55:57PM +0100, Sebastian Ramacher wrote:
    since dpkg 1.22.0 the additional hardening flags to enable Pointer Authentication (PAC) and Branch Target Identification (BTI)
    on arm64 are enabled by default. See [1] for the discussion to enable
    these flags.

    /me likes

    To have the desired effect for the next release and have some time
    to catch regressions, I have started with scheduling rebuilds of
    packages that have not been built since the change in the default flags. While the change of flags only affects arm64, packages building
    Multi-Arch: same binaries require consistent versions on all
    architectures. For those packages, the rebuilds have been scheduled on
    all architectures.

    /me likes very much! background: even though snapshot.d.o has been
    fixed now, so that it's become generally usable again, several many
    snapshots from 2023 and 2024 are missing, thus making it impossible
    to recreate the build environments used needed for reproducible builds
    of trixie.

    these mass rebuilds will help reduce that gap.

    Thanks to Emanuele Rocca for identifying the list of packages that have
    to be rebuilt to gain PAC/BTI support.

    thank you both! :)


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    Gendern ist wie Wurst ohne Fleisch: Fortschritt.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmcja/UACgkQCRq4Vgaa qhxP+w//dvzNRdm099RnRzQ2fB8HY9pfndt8c9kOzHYtfZPPuVB8TsalBOZmHnrm q4B78zvKd8094WEzqhgmtsD4Ab35TqPf+neGdh0DQQ3zAb7jo8kKqB9xUX0Llf05 3BdXJkRqD4TyJuDjecLgtjvK8XhtnmSuYTbw+T9a6+jm+5D9ozQSQSHSwcraX89A UWGM/qoh14ALH+W/6t2+ZDnYxW99kokEnD0XaJzEhWEOLJzz6K9QzAkpdxEVCMKT 1pp6rqROd0bMR2lM1w1WRjIm+6K7N+hXBeZL5ijWXd4bkU4t1lJocYvFJvVSZWmk 3MJ79TYAvwVMBVIt6i382FcnyspJlnMblWx7qm0MmUpWReQtWQ60f8L5ICHohoit n/3GGUnvScQgL40kLr+NwD5iGxbDT7olg70AAniZueima6VX/lptTQloTP8Kv5SL 6qj52Y1lZcXI/yrNGX/ZzkNTJoIu2N8a1i6nT8I0jofkWWSemOHJMNCv24yoYUKd 2JzTlLtJVs7z6+iwJxV+WPUOTtLYNIUw2lyBtd8Y3N59Tf+6KSh+3KqhjbiIVxEK 8WueIVcj+LofDoDQXqzDdoK+66B9/FckS3jV1gUcy09ZgdgbFpl/n+q/96CiH4P4
  • From Emanuele Rocca@21:1/5 to Sebastian Ramacher on Wed Nov 6 10:50:01 2024
    On 2024-10-28 10:55, Sebastian Ramacher wrote:
    since dpkg 1.22.0 the additional hardening flags to enable Pointer Authentication (PAC) and Branch Target Identification (BTI)
    on arm64 are enabled by default.

    Some more background and an update on this.

    Both PAC and BTI are enabled by adding -mbranch-protection=standard to
    the compiler flags. The defaults in Debian sid include such flag since
    August 2023 (dpkg 1.22.0) as Sebastian said.

    However PAC and BTI differ in the way they are enabled. For PAC, simply building a program with -mbranch-protection=standard results in PAC to
    be enabled. When it comes to BTI, all execution units (ie: all object
    files) linked together need to have BTI in order for the resulting ELF
    file to have BTI turned on. Since pretty much every program in the world
    uses crtbeginS.o and crtendS.o from GCC as well as crti.o, Scrt1.o and
    crtn.o from glibc, this means that only packages built with a
    BTI-enabled GCC and glibc get the feature. In sid, we enabled BTI
    support in gcc-14 14.1.0-4 (2024-07-10) and glibc 2.39-5 (2024-07-22).
    See https://wiki.debian.org/ToolChain/PACBTI for more details.

    I performed a local archive rebuild to get the list of all packages that
    don't currently have BTI on, but would get it with a simple rebuild
    (binNMU). I added the date of "last build" to the output just to verify
    that no package was built after the end of July 2024, those should have
    had BTI already. To my surprise some of the packages in the list where
    last built in 2014, which is... well a long time ago! https://people.debian.org/~ema/pac-bti/arm64-binNMUs.log

    When the binNMUs started (thank you Sebastian) we had 10204 binary
    packages with BTI turned on, and we are now at 18348. Once the rebuilds
    are over I'll check the situation again. There's likely going to be a
    long tail of packages that don't get BTI with a simple rebuild for many reasons, including for example not using the default compiler flags.

    As a final thought, given that new toolchain versions bring multiple improvements over the years it's perhaps worth thinking about rebuilding
    the archive on some sort of regular basis to make sure we get the
    benefits?

    ema

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to Emanuele Rocca on Wed Nov 6 13:30:01 2024
    On Wed, Nov 06, 2024 at 10:43:07AM +0100, Emanuele Rocca wrote:
    As a final thought, given that new toolchain versions bring multiple improvements over the years it's perhaps worth thinking about rebuilding
    the archive on some sort of regular basis to make sure we get the
    benefits?

    "Let's at least force rebuilds all packages not rebuilt since stable
    before every freeze starts" is a popular opinion.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmcrYPYtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh iQ4P/i/B5PVQF/womQ8BVcPLycTSlE/0wpW/HjiSuwRwjubord7Fo0eLa+DUIuTd TNVDJ2QLMfdHVtdKrB6OkgRlR/Vi0Q+CIilVpd/uhr34lPWv7vnmUdil+OLv9+0E Cr6b2yN0tv+YtJzHz0tvGENXNofy2pSXNnZ0ruytmUSrCBWdeciQXqDdIfulm/eR Di3HVQo2Pkn31iij9Yvba1q8bwzKYKGktVMbAYsjZNoEh1gfmCX/RC4jCdgtnZA3 IDQsRfZamFFlCW3VkeIQ31x3DcJNhd6b6pCAYJprqsoZWf7rotwkVTMn802Sh5ac lgafxg2McKQ2dLeCuqqqqH9rR+OGX6L3NR/PUw6OfI5KCYjde7VEFFrM9DuUyZPq rNWw0DuNmTp/R6XX7EmzAW/jkYKVqb/I1lBXW6DtZXsUfvzvwl6gzypOIxxyBM5x 0IQVmiB6wMwcJ7v0JSVBoZcu03KsHr1m8JEz57l7k8Dab8LG81dlqX/RzUtHJCfX wHTpXSraykrjpS2W3Vrc5nQVx5klghZ7lVHMmtpI7BbvECAzR4HLYZdc+Zq/czSe x2dx/oIJ1DCc2IZEn7FhxJDW8YNWVo/63YZsF8tbuBoY10TtYNCfKfktSOniejd1 lLg/tDmnWAv2Szv2uuh81cK7dNdxXnBPWfJgEt50K+aitagQ
    =cN5g
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to Holger Levsen on Wed Nov 6 14:50:01 2024
    On Wed, Nov 06, 2024 at 01:16:57PM +0000, Holger Levsen wrote:
    On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote:
    "Let's at least force rebuilds all packages not rebuilt since stable
    before every freeze starts" is a popular opinion.

    true. and "let's not do that" is even more popular, else why haven't we
    done this in three decades?

    Doing is harder than talking, and doing something like that is much
    harder than, say, fixing and uploading a package. Where can one start?

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmcrc8ItFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 6vMP/0oQRDVOm3GLgGjzQytVHFg+P4q5p60qnqHK04NugndMBk7JolKnmVo8o6Jw zn2U8+O7muhojDrNFmdute08u5qoUamGz5VYzQvs9ROBnANY0/3744Sm0jlWhITe 4cOW2Axo3TDBfMYl6ea2qmnPYCu3OX2RqPBlcSnm8exKj3srlnhPYLA4A/nQYqWV lONb5ApzLbGYlIok/IuAYS8vG775MSYYVW7l3rkBH9uQE9KhwasEJNywGG88MgEp PhrOzleZS8UoZcxXmATu/v/XawrJe1r/+DHs/p3DQCB01mrsUnwAwN6X0O8fOW7K KdxOKNLeVxjFuRj1HDizloJWGY8rrKkmpTmmxnWUwcxdxbLYrcyhLfpfy0Y1cQ6C s/er++Id3OrnYzfNHq4UhFW+lutUqmFMrfN7kxcJ3XB2S6qLqGuB2CXjN0cemq2E 5UTl2raKKga5uq2NL96s0HO0Lk0mihYghKjSDYYOdwuXrzq/GW0twg9kAZ+3JN6W 5+aRXT6B7XGvE6lKpACo0myqexHIJXdQepLrNioZLhNfc/aSAT7bm+qG8Gi76VUn XRiRXJY3cU4b3mzItWNI22Dt9oAmRnXegEv1IyAJ/lnahmUuGbx3JB+F1TD4Jy1N fEOafgnpPf//B2Xewf+mwu+FPUFKvCfdk39vqxsxS1WHN/HB
    =Exbm
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Holger Levsen@21:1/5 to Andrey Rakhmatullin on Wed Nov 6 14:20:01 2024
    On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote:
    "Let's at least force rebuilds all packages not rebuilt since stable
    before every freeze starts" is a popular opinion.

    true. and "let's not do that" is even more popular, else why haven't we
    done this in three decades?


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    If you upload your address book to "the cloud", I don't want to be in it.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmcrbEUACgkQCRq4Vgaa qhwXgxAAiAgOZRGzKEXlwO+4g4eDEBX+BosQhNl/ye8ZSyUp9Jt5nRYazknmuH+y 8zxi0t54TBuxi3pUMM+0bjkE3BXXh0Jvc/IldYETyP9+ImyxBgfHs2XmWr8gWAdT Q34dna8YHuBzQZzKfEv8BvYIOfWH/AWi4BJFemaytgZPAdJhjOlI2JWk5vgb0J+J RQHJl/2tzROO/sAWGq9xOLaThMBHHP9NjdZMcFkifny4j9kBts8wkXg0iUVblYul 6/6UYDQ5ib28QrfLVzrYjwf/nBW600HaOK0ZIKeAsMJG3ZRtB7K2dfHV/REOFuvy J3kYHEZ4JN5xzUyZ6pHxeQVNoKllF+/TdztB2l4T8TZnlaKMFhXe+Ucuw/IDGHSr V01jaIugSi9kuJn0aWKxZWDp7IXmGufcmHL1M3b0X51rokQ6hDOty/bs+ExfNGIT FKC33ukPGl54/XON3/dJBJcFImzzvWKEudsyfrX3gzUADqz8RmWFQo/OQqXUJ0ue 95Ge9lA9dXS4JXpZJhb04gMRliK0DHiRNXgQQfYdRlk1GBBz9Ms2hd+SCD3YrKOO j5XXBMqgsmtJLels/jc7VHKKN0MvDqqQ5vfHaYw
  • From Andreas Tille@21:1/5 to All on Wed Nov 6 16:30:01 2024
    Am Wed, Nov 06, 2024 at 01:16:57PM +0000 schrieb Holger Levsen:
    On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote:
    "Let's at least force rebuilds all packages not rebuilt since stable
    before every freeze starts" is a popular opinion.

    true. and "let's not do that" is even more popular, else why haven't we
    done this in three decades?

    Changing something is just some effort. How do you want to distinguish
    the "let's not do that" opinion from the "no spare time to trigger a
    change" "opinion"?

    Finally we have those regular archive wide rebuilds that trigger lots of
    FTBFS bugs. I could imagine to simply upload those that pass the
    rebuild tests. Otherwise the package needs manual intervention by the maintainer which also will end up in an upload or a testing removal.

    Kind regards
    Andreas.

    --
    https://fam-tille.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to Andrey Rakhmatullin on Thu Nov 7 03:00:01 2024
    Hi!

    On Wed, 2024-11-06 at 17:28:38 +0500, Andrey Rakhmatullin wrote:
    On Wed, Nov 06, 2024 at 10:43:07AM +0100, Emanuele Rocca wrote:
    As a final thought, given that new toolchain versions bring multiple improvements over the years it's perhaps worth thinking about rebuilding the archive on some sort of regular basis to make sure we get the
    benefits?

    "Let's at least force rebuilds all packages not rebuilt since stable
    before every freeze starts" is a popular opinion.

    Of course, as Emanuele mentions doing mass rebuilds, which seems to
    be more common nowadays, can bring benefits from toolchain improvements (potentially all layers from compilers, to packaging tools).

    But routinely rebuilding and _uploading_ the results also comes with
    its drawbacks. For one it will hide ABI breaks. Having packages not get upgraded during a Debian release upgrade has also been a good and easy indicator for end users that those packages are stale and perhaps it's
    time to look for alternatives.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)