#9505 Change proposal check: Aarch64 Pointer Authentication & Branch Target Enablement
Closed: Fixed a year ago by mohanboddu. Opened a year ago by bcotton.

On behalf of @jlinton, I am opening an issue to check the impact of a proposed F33 change: https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication


@jlinton Does this change should be included in mass rebuild? Seems like it should, but I am not able to figure out what happens to the existing builds that didn't get rebuilt after the change has landed.

Metadata Update from @mohanboddu:
- Issue tagged with: changes, f33

a year ago

Hi, sorry about the lag here, I'm a bit new to this, and missed this comment.. etc.

Yes, this change is required of the mass rebuild, but it also has a dependency on some gcc 10.2 changes which should be in fedora before this lands.

The bz https://bugzilla.redhat.com/show_bug.cgi?id=1847148 has more information as does my suggested pull request https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/97.

I've been trying to determine if gcc 10.2 is expected to be part of the next mass rebuild, or I need to submit a last min pull request for the defects from 10.2 that should be in 10.1 (which seems a bit silly).

Hmm, in response to the first question. I've been rebuilding most packages when I test this. In theory its possible that if a package is only using unwrapped pointers it simply won't benefit from the additional security, or worse case it won't work on a v8.3 machine because of an underlying library/package mismatch. For the first pass, the main focus is assuring we get it enabled, and that it continues to work on baseline v8.0 machines where the ops are effectively NOPs so there shouldn't be any problems if a package isn't rebuilt. We have a kernel patch in progress to disable PAC on 8.3 machines as well, which will provide a fire escape for if we find a 8.3+ machines or critical package having problems.

Which packages are you expecting won't be rebuilt for F33?

Metadata Update from @mohanboddu:
- Issue tagged with: change-ack, mass rebuild

a year ago

@jlinton When can you expect to build gcc 10.2? If you need some time before the mass rebuild starts, please file a ticket with FESCo.

I don't think the prerequisite gcc and glibc changes for this have landed in rawhide:

https://sourceware.org/pipermail/libc-alpha/2020-July/116611.html

Specifically, we don't seem to build gcc with --enable-standard-branch-protection, and glibc has not been rebuilt with PAC+BTI-enabled GCC. If my analysis is correct, the statically linked parts of glibc are not PAC+BTI-enabled, and after the mass rebuild, no programs will actually use PAC+BTI.

My understanding is that the gcc guys were going to build 10.2 and submit it to the repo.

@fweimer, That is odd i was seeing pac sequences with the rawhide compiler with nothing beyond the default fedora flags. Let me look at it some more.

Although that thread suggests its not right.

My understanding is that it's enabled in the compiler via redhat-rpm-config, but the linker will not produce properly marked up binaries because some of the statically linked bits are not built in the right way. I suspect I can patch this up for glibc in some way, but getting a compatible libgcc.a requires a special GCC, built with the non-default --enable-standard-branch-protection flag, and that has not happened for Fedora 33 so far.

Did you patch up glibc (presumably this is caused by the flag not propagating) into everything? I don't see a build in koji yet. Because if something is fixed with '--enable-standard-branch-protection' it is because something isn't being built with the provided CFLAGS.

I picked up the gcc 10.2 build, and the libgcc static libraries are chuck full of BTI, and to a lesser extent I do see PAC instruction sequences in them.

I'm rolling my own glibc at the moment to see what happens.

According to the Arm glibc maintainers, we need a GCC that has been configured with --enable-standard-branch-protection, otherwise the statically-linked GCC bits are not built correctly. See the discussion thread I referenced (and the glibc 2.32 NEWS file).

I'm not sure that is 100% accurate.. In the case of glibc, adding -mbranch-protection=standard to the rpm-inhert-flags appears to fix the glibc builds in fedora, which by default are missing the PAC/BTI bits. (I'm still getting a build break, with the glibc debuginfo though in my environment with that enabled).

If you pick up the gcc 10.2.1 build last friday and look at the static libs, they appear to be ok..

Please comment on the libc-alpha thread, then. We want to get this right for the glibc 2.32 NEWS file, too.

According to the Arm glibc maintainers, we need a GCC that has been configured with --enable-standard-branch-protection, otherwise the statically-linked GCC bits are not built correctly. See the discussion thread I referenced (and the glibc 2.32 NEWS file).

Do we have a list of things that statically link against glibc in Fedora?

Per repoquery, the only result is libxcrypt-static.

Just as a status update, on the gcc flags bit, I have an open query to Szabolcs about whether he tested with a gcc that was built with mbranch-protection=standard vs changing the compiler default setting vs just the default gcc flags. I will update this when I hear back.

Do we have a list of things that statically link against glibc in Fedora?

@pbrobinson Everything in userspace uses the statically linked startup code, most packages use functions such as fstat64 from libc_nonshared.a. On the GCC side, there are further files with startup code, and libgcc.a is purely a static library (there is also a shared object, libgcc_s, but its contents is different).

Just as a status update, on the gcc flags bit, I have an open query to Szabolcs about whether he tested with a gcc that was built with mbranch-protection=standard vs changing the compiler default setting vs just the default gcc flags. I will update this when I hear back.

@jlinton I really would like to follow the upstream-recommended way here and not patch build systems to implement an approach not supported by upstreams.

I talked to Sazbolcs about this, and he agrees that the compiler flag should be sufficient, and that initially he didn't consider that it might be done this way. I've requested he clarify the NEWS or that thread publicly for the record as well. Thanks,

@jlinton Seems like the work is done, closing this ticket now.

Please reopen if you need anything else, thanks.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata