Re: [RFC bpf-next 2/2] bpftool: Use libcrypto feature test to optionally support signing

[Quentin Monnet <qmo@kernel.org>]

2025-10-29 11:22 UTC+0000 ~ Alan Maguire <alan.maguire@oracle.com>
> On 29/10/2025 10:40, Quentin Monnet wrote:
>> 2025-10-29 09:46 UTC+0000 ~ Alan Maguire <alan.maguire@oracle.com>
>>> New libcrypto test verifies presence of openssl3 needed for BPF
>>> signing; use that feature to conditionally compile signing-related
>>> code so bpftool build will not break in the absence of libcrypto v3.
>>
>>
>> Hi Alan, thanks for this work!
>>
>>
>>>
>>> Fixes: 40863f4d6ef2 ("bpftool: Add support for signing BPF programs")
>>> Suggested-by: Quentin Monnet <qmo@kernel.org>
>>
>>
>> This is not exactly what I suggested, I mentioned adding such a feature
>> check and printing a more user-friendly error message at build time if
>> the dependency is missing, not leaving out the program signing feature.
>>
>> I've got reservations about the current approach: my concern is that
>> people packaging bpftool may prefer to compile and ship it without
>> program signing, if their build environment does not include the OpenSSL
>> dependency. But it seems to me that it will be an important feature
>> going forward, and that bpftool should ship with it.
>>
>> Regarding the OpenSSL v3 vs. older version concern (from the build
>> failure report thread):
>>
>>> One issue here is that some distros package openssl v3 such that the
>>> #include files are in /usr/include/openssl3 and libraries in
>>> /usr/lib64/openssl3 so that older versions can co-exist. Maybe we could
>>> figure out a feature test that handles that too?
>>
>> In that case, we should have a feature probe that gives us the right
>> build parameters to ensure that v3, and not some older version, is
>> picked when building bpftool? (We could imagine falling back to an older
>> version, but I see v3.0 is now the oldest OpenSSL supported version so
>> it's probably not worth it?)
>>
> 
> Actually there may be a simpler solution here; compilation at least
> succeeds for openssl < 3 with the following change
> 
> diff --git a/tools/bpf/bpftool/sign.c b/tools/bpf/bpftool/sign.c
> index b34f74d210e9..f9b742f4bb10 100644
> --- a/tools/bpf/bpftool/sign.c
> +++ b/tools/bpf/bpftool/sign.c
> @@ -28,6 +28,12 @@
> 
>  #define OPEN_SSL_ERR_BUF_LEN 256
> 
> +/* Use deprecated in 3.0 ERR_get_error_line_data for openssl < 3 */
> +#if !defined(OPENSSL_VERSION_MAJOR) || (OPENSSL_VERSION_MAJOR < 3)
> +#define ERR_get_error_all(file, line, func, data, flags) \
> +       ERR_get_error_line_data(file, line, data, flags)
> +#endif
> +
>  static void display_openssl_errors(int l)
>  {
>         char buf[OPEN_SSL_ERR_BUF_LEN];
> 
> 
> Given that openssl is already a build requirement for the kernel, that
> may well be enough to resolve this issue without feature tests etc.
> However I can't speak to whether there are other issues with using
> openssl v1 aside from compile-time problem this solves.


I'm equally unfamiliar with the risks associated with older OpenSSL
versions. Other than that, it sounds like a good solution to me. As
Namhyung pointed out, bpftool's build affects other things like perf, or
kernel build itself (for preloaded BPF iterators), so aligning
requirements with the ones from the kernel would make sense. From
Documentation/process/changes.rst I see that the minimal requirement for
OpenSSL is v1.0.0, so your suggestion is probably acceptable?

Quentin