Looks like it is non-x86_64 specific. I.e. fails on s390x, aarch64, ppc64le.

SELinux Memory Protection Tests:
 * https://akkadia.org/drepper/selinux-mem.html

The execmem permission is nothing that SELinux policy allows without asking, because it is a dangerous operation.

annocheck actually falgs this:

Hardened: /usr/lib64/ossl-modules/fips.so: FAIL: rwx-seg test because segment has Read, Write and eXecute flags set 

The build log unfortunately does not show the linker flags. The only unusual thing I can see is the objcopy call.

Could you check if the RWE LOAD segment is present even before the objcopy call?

Testing can proceed with selinux in permissive mode, so this is not an immediate blocker.

However we'd like to find the cause asap so we know how difficult it will be to address it.

Without machines to experiment with, my guess is this:

Due to the const volatile specifier, the section is created as:

	.section	.rodata1,"aw"

That is, it is allocated and writable. This means that the entire segment needs to be writable. On non-x86 targets, -z noseparate-code is the default, so .rodata1 overlaps with .text, and you end up with a RWE load segment. On x86-64, you still lose some security hardening because more data becomes writable.

If that's true, the objcopy doesn't matter: fips.so should be in a bad state before that.

Presumably you added the volatile as a compiler barrier. I suggest to use this instead (completely untested):

extern unsigned char __attribute__ ((visiblity ("hidden"))) fips_hmac_container[32];

__asm(".hidden fips_hmac_container\n\t"
      ".type fips_hmac_container, %object\n\t"
      ".size fips_hmac_container, 32\n\t"
      ".section .rodata.fips_hmac_container,\"a\"\n\t"
      ".balign 16\n"
      "fips_hmac_container:\n\t"
      ".zero 32\n\t"
      ".previous");

And switch to .rodata.fips_hmac_container in the objcopy call. This way, you avoid corrupting fips.so in case the toolchain uses .rodata1 for some reason.

This is a part of my downstream patch. I had to use volatile because otherwise there were some problems with moving it to the correct section. I'll try your solution and let you know if I succeed.

Unfortnately, I don't get any .rodata.fips_hmac_container in the binary I build. Replacing it back with .rodata1 helps, the necessary section is seen via objdump -t

I removed the `volatile` attribute for embedded hmac value. Currently the section attribute is preserved so hopefully the issue will go away.

(In reply to Dmitry Belyavskiy from comment #25)
> I removed the `volatile` attribute for embedded hmac value. Currently the
> section attribute is preserved so hopefully the issue will go away.

The volatile was presumably added to avoid constant propagation because the intent is to change the constant under the covers.

Yes. Without volatile the variable didn't fit into a requested section, so we couldn't embed the value.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: openssl), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:3900