Oddities when checking for SHSTK support

lquidfire · 2024-11-13 10:20:46

Hi all,

I could use some assistance with the following.

When running namcap on the following package in AUR "openarc-unofficial-patches-git", it informs me, among other things, about the following:

openarc-unofficial-patches-git W: ELF file ('usr/bin/openarc') lacks GNU_PROPERTY_X86_FEATURE_1_SHSTK

After some searching here on the forums, I tried the following:

LDFLAGS+=' -Wl,-z,cet-report=error'

However, this results in a new, unrelated (?) error that prevents configuring:

checking for libidn2... yes
checking for libmilter/mfapi.h... yes
checking for smfi_register in -lmilter... no
configure: error: Unable to find libmilter
==> ERROR: A failure occurred in build().
    Aborting...

The smfi_register in -lmilter is found without issues when I do not have those LDFLAGS added.

Does anyone have an idea why this is happening? What can I do to make it see the libmilter, and continue the search to find out what is missing the SHSTK support?

Many thanks!

Lone_Wolf · 2024-11-14 10:26:28

https://github.com/flowerysong/OpenARC/issues/18 looks relevant .

Please post the full config.log .

lquidfire · 2024-11-16 08:22:25

The full config.log is pasted online.

It would seem to me from the log that the problem is not that it can't find the libmilter piece, but that the libmilter does not support SHSTK. The error message is confusing.

I tried to build libmilter myself with the -fcf-protection flag enabled, but that did not seem to do the trick [update: See below, I found how to build libmilter with fcf-protection enabled, which solved the problem.]

Last edited by lquidfire (2024-11-18 13:28:46)

Lone_Wolf · 2024-11-16 13:36:39

configure:8695: checking for vfork.h
configure:8695: gcc -c -march=native -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection         -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -flto=auto  conftest.c >&5
conftest.c:48:10: fatal error: vfork.h: No such file or directory
   48 | #include <vfork.h>
      |          ^~~~~~~~~
compilation terminated.

A search in the sourcecode indicates config.ac uses the autoconf macro AC_FUNC_FORK .

https://www.gnu.org/savannah-checkouts/ … tions.html indicates that macro is used for compatibility with older autoconf versions.

The man page for vfork has an interesting note

Linux notes
Fork handlers established using pthread_atfork(3) are not called when a multithreaded program employing the NPTL threading library calls vfork(). Fork handlers are called in this case in a program using the LinuxThreads threading library. (See pthreads(7) for a description of Linux threading libraries.)

This looks very similar to the linked BR.

clean up the src folder to remove any cache remnants, then try a fresh build.

lquidfire · 2024-11-18 09:30:47

You can see in the log I posted that it ends up finding a working fork and vfork:

...
| #define HAVE_STDBOOL_H 1
| #define HAVE_FORK 1
| #define HAVE_VFORK 1
| #define HAVE_ALARM 1
| #define HAVE_WORKING_VFORK 1
| #define HAVE_WORKING_FORK 1
| #define GETGROUPS_T gid_t
...

I had to poke around libmilter a bit to build it with CET-protection enabled, but once I got that going, I could also build openarc with SHSTK and IBT support.

I have submitted a bug report, including patch, for libmilter. First bug-report, so I hope everything was done well.

This does not change the fact that the error message was highly confusing. Where would I report that?

Thank you for your help so far!

Last edited by lquidfire (2024-11-18 09:31:35)

Lone_Wolf · 2024-11-18 09:59:55

This does not change the fact that the error message was highly confusing. Where would I report that?

That requires changes by upstream, but for aur packages there are two possible upstreams : aur maintainer & the source authors.

Despite the name of the package I see no sign of patching and the systemd services should have no effect during build.

Since you are the aur maintainer, I advise to file a feature request with openarc devs to add a test for this usecase and/or improve the error message.

lquidfire · 2024-11-18 12:30:16

Lone_Wolf wrote:

Despite the name of the package I see no sign of patching and the systemd services should have no effect during build.

This is a fork of the seemingly abandoned official OpenARC project. The 100+ PR's were added (or discarded) in this new fork, and further improvements were made, including bringing the software more up-to-date. Hence, no patches in the PKGBUILD, but upstream, in the fork. Perhaps the naming of the package should be changed.

Lone_Wolf wrote:

Since you are the aur maintainer, I advise to file a feature request with openarc devs to add a test for this usecase and/or improve the error message.

If I understand the steps correctly, enabling the `cet-report=error` flag results in the libilter silently(!) being dropped, and therefore not recognised by the check in the configure stage.

Is there a way to make the error message from the `cet-report=error` flag print to screen? I am not sure how to write a test to incorporate this. I am also not sure this is too useful, since the `cet-report=error` flag is not a common flag, and once you're going down that line, you are already troubleshooting. Without that flag there is no issue building openarc*.

One could add a test to see if everything is SHSTK/IBT compatible, but that is a different matter. Not all distro's have the `-fcf-protection` flag enabled, either.

Lone_Wolf · 2024-11-19 09:19:20

This is a fork of the seemingly abandoned official OpenARC project. The 100+ PR's were added (or discarded) in this new fork, and further improvements were made, including bringing the software more up-to-date. Hence, no patches in the PKGBUILD, but upstream, in the fork. Perhaps the naming of the package should be changed.

In similar cases the aur package maintainer keeps the name ands a (sticky) comment they are using a fork.

I see there are 3 openarc packages in aur maintained by you, Personally I'd create an openarc-legacy package for the unmaintained original code, and use openarc & openarc-git for the fork .

I just noticed you are also one of the people that maintain the fork.

This is beyond my skill level, I suggest you change the title of this thread to something like "fcf-protection / cet-error flags cause problems at buildtime" to hopefully attract attention from forum users that can help.

Since the same issue could arise on other distros, a bugreport for the fork should be created.
Even if there's no solution yet, openarc fork users should be informed of the issue.

Arch Linux

#1 2024-11-13 10:20:46

Oddities when checking for SHSTK support

#2 2024-11-14 10:26:28

Re: Oddities when checking for SHSTK support

#3 2024-11-16 08:22:25

Re: Oddities when checking for SHSTK support

#4 2024-11-16 13:36:39

Re: Oddities when checking for SHSTK support

#5 2024-11-18 09:30:47

Re: Oddities when checking for SHSTK support

#6 2024-11-18 09:59:55

Re: Oddities when checking for SHSTK support

#7 2024-11-18 12:30:16

Re: Oddities when checking for SHSTK support

#8 2024-11-19 09:19:20

Re: Oddities when checking for SHSTK support

Board footer