Hi,
I’m also seeing a failing annocheck for BTI on aarch64 in dovecot-fts-xapian, which does not contain assembly code and does compile with the recommended -mbranch-protection=standard flag according to the build log. See https://src.fedoraproject.org/rpms/dovecot-fts-xapian/pull-request/8 and the rpminspect results at https://artifacts.dev.testing-farm.io/aaa27461-cfa7-4a0f-a2d5-c37db8db7b00/. This makes me think the problem is somewhere in the toolchain, either in the compiler & linker, or in annocheck. Since the resulting binary does in fact not seem to have a .note.gnu.property section, I’m guessing it’s the former. The exact same code does not have the problem on F44, so something must recently have changed on rawhide. Now, it’s absolutely possible that this is actually triggered by the assembly change in libuv, but maybe it’s worth attempting to build the same code on F44 and seeing whether it is also a problem there — because if it isn’t, the problem is probably not with the assembly. HTH, Clemens > On 18. Feb 2026, at 12:26, Peter Robinson <[email protected]> wrote: > > Adding Jeremy directly on cc: as he knows a lot more about the BTI low > level bits. > > Peter > > On Wed, 11 Feb 2026 at 21:52, Stephen Gallagher <[email protected]> wrote: >> >> While attempting to package libuv 1.52.0, I discovered via rpminspect >> that a change[1] made since 1.51.0 has introduced some assembly that >> leaves GCC unable to determine whether the resulting binaries are >> BTI-safe. I am not sure of the best way to approach this. I'm pretty >> sure that this specific usage is fine, but I don't particularly want >> to use `-Wl,-z,force-bti` because that could end up hiding a truly >> unsafe change later on. >> >> I am not well enough versed in low-level compiler knowledge to figure >> out what the alternative would be, though. I don't want to just revert >> the upstream patch, because I'm led to believe that this will have a >> negative impact on a significant percentage of ARM hardware. >> >> I would very much appreciate some help figuring this one out. >> >> [1] https://github.com/libuv/libuv/pull/4863 -- Clemens Lang RHEL Crypto Team Red Hat -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
