bpftool BPF signing supported using openssl v1? (Was Re: [RFC bpf-next 2/2] bpftool: Use libcrypto feature test to optionally support signing)

[Alan Maguire <alan.maguire@oracle.com>]

On 30/10/2025 13:58, Quentin Monnet wrote:
> 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?
>

Sounds good to me! Would be good to get clarification from KP if
opensslv1 is acceptable as I couldn't find any openssl versioning
specific discussion in the threads; changed the subject line
accordingly. KP is openssl v1 ok? FWIW the BPF fentry_fexit tests that
use signed lskels do pass when run using bpftool+openssl v1 for me:

$ sudo ./test_progs -vvv -t fentry_fexit
bpf_testmod.ko is already unloaded.
Loading bpf_testmod.ko...
Successfully loaded bpf_testmod.ko.
test_fentry_fexit:PASS:fentry_skel_load 0 nsec
test_fentry_fexit:PASS:fentry_skel_load 0 nsec
test_fentry_fexit:PASS:fexit_skel_load 0 nsec
test_fentry_fexit:PASS:fexit_skel_load 0 nsec
test_fentry_fexit:PASS:fentry_attach 0 nsec
test_fentry_fexit:PASS:fexit_attach 0 nsec
test_fentry_fexit:PASS:ipv6 test_run 0 nsec
test_fentry_fexit:PASS:ipv6 test retval 0 nsec
test_fentry_fexit:PASS:fentry result 0 nsec
test_fentry_fexit:PASS:fexit result 0 nsec
test_fentry_fexit:PASS:fentry result 0 nsec
test_fentry_fexit:PASS:fexit result 0 nsec
test_fentry_fexit:PASS:fentry result 0 nsec
test_fentry_fexit:PASS:fexit result 0 nsec
test_fentry_fexit:PASS:fentry result 0 nsec
test_fentry_fexit:PASS:fexit result 0 nsec
test_fentry_fexit:PASS:fentry result 0 nsec
test_fentry_fexit:PASS:fexit result 0 nsec
test_fentry_fexit:PASS:fentry result 0 nsec
test_fentry_fexit:PASS:fexit result 0 nsec
test_fentry_fexit:PASS:fentry result 0 nsec
test_fentry_fexit:PASS:fexit result 0 nsec
test_fentry_fexit:PASS:fentry result 0 nsec
test_fentry_fexit:PASS:fexit result 0 nsec
#108     fentry_fexit:OK
Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED

$ ldd tools/sbin/bpftool
	linux-vdso.so.1 (0x00007f5497efc000)
	libelf.so.1 => /usr/lib64/libelf.so.1 (0x00007f5497800000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007f5497400000)
	libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007f5496e00000)
	^^^^^^^^^^^^^^
	openssl v1