netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Jiri Olsa <olsajiri@gmail.com>, Stephane Eranian <eranian@google.com>
Cc: 谭梓煊 <tanzixuan.me@gmail.com>,
	"Zixuan Tan" <tanzixuangg@gmail.com>,
	terrelln@fb.com, "Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <kafai@fb.com>,
	"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"KP Singh" <kpsingh@kernel.org>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	bpf@vger.kernel.org
Subject: Re: [PATCH] perf build: Suppress openssl v3 deprecation warnings in libcrypto feature test
Date: Mon, 1 Aug 2022 15:24:18 +0200	[thread overview]
Message-ID: <YufUAiLqKiuwdvcP@krava> (raw)
In-Reply-To: <Yrqcpr7ICzpsoGrc@krava>

On Tue, Jun 28, 2022 at 08:16:06AM +0200, Jiri Olsa wrote:
> On Mon, Jun 27, 2022 at 11:08:34AM +0800, 谭梓煊 wrote:
> > On Sun, Jun 26, 2022 at 10:45 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > >
> > > On Sat, Jun 25, 2022 at 11:34:38PM +0800, Zixuan Tan wrote:
> > > > With OpenSSL v3 installed, the libcrypto feature check fails as it use the
> > > > deprecated MD5_* API (and is compiled with -Werror). The error message is
> > > > as follows.
> > > >
> > > > $ make tools/perf
> > > > ```
> > > > Makefile.config:778: No libcrypto.h found, disables jitted code injection,
> > > > please install openssl-devel or libssl-dev
> > > >
> > > > Auto-detecting system features:
> > > > ...                         dwarf: [ on  ]
> > > > ...            dwarf_getlocations: [ on  ]
> > > > ...                         glibc: [ on  ]
> > > > ...                        libbfd: [ on  ]
> > > > ...                libbfd-buildid: [ on  ]
> > > > ...                        libcap: [ on  ]
> > > > ...                        libelf: [ on  ]
> > > > ...                       libnuma: [ on  ]
> > > > ...        numa_num_possible_cpus: [ on  ]
> > > > ...                       libperl: [ on  ]
> > > > ...                     libpython: [ on  ]
> > > > ...                     libcrypto: [ OFF ]
> > > > ...                     libunwind: [ on  ]
> > > > ...            libdw-dwarf-unwind: [ on  ]
> > > > ...                          zlib: [ on  ]
> > > > ...                          lzma: [ on  ]
> > > > ...                     get_cpuid: [ on  ]
> > > > ...                           bpf: [ on  ]
> > > > ...                        libaio: [ on  ]
> > > > ...                       libzstd: [ on  ]
> > > > ...        disassembler-four-args: [ on  ]
> > > > ```
> > > >
> > > > This is very confusing because the suggested library (on my Ubuntu 20.04
> > > > it is libssl-dev) is already installed. As the test only checks for the
> > > > presence of libcrypto, this commit suppresses the deprecation warning to
> > > > allow the test to pass.
> > > >
> > > > Signed-off-by: Zixuan Tan <tanzixuan.me@gmail.com>
> > > > ---
> > > >  tools/build/feature/test-libcrypto.c | 6 ++++++
> > > >  1 file changed, 6 insertions(+)
> > > >
> > > > diff --git a/tools/build/feature/test-libcrypto.c b/tools/build/feature/test-libcrypto.c
> > > > index a98174e0569c..31afff093d0b 100644
> > > > --- a/tools/build/feature/test-libcrypto.c
> > > > +++ b/tools/build/feature/test-libcrypto.c
> > > > @@ -2,6 +2,12 @@
> > > >  #include <openssl/sha.h>
> > > >  #include <openssl/md5.h>
> > > >
> > > > +/*
> > > > + * The MD5_* API have been deprecated since OpenSSL 3.0, which causes the
> > > > + * feature test to fail silently. This is a workaround.
> > > > + */
> > >
> > > then we use these deprecated MD5 calls in util/genelf.c if libcrypto is detected,
> > > so I wonder how come the rest of the compilation passed for you.. do you have
> > > CONFIG_JITDUMP disabled?
> > >
> > > thanks,
> > > jirka
> > >
> > No, CONFIG_JITDUMP is not disabled. I am using the default configuration.
> > 
> > Yes, you are right. The rest of the compilation should fail, but it doesn't.
> > I checked the verbose build commands. This seems to be the result of another
> > inconsistency.
> > 
> > If libcrypto is detected, the macro "HAVE_LIBCRYPTO_SUPPORT" will be
> > defined, but in perf/util/genelf.c, "HAVE_LIBCRYPTO" without the "_SUPPORT"
> > prefix is checked. This causes urandom always be used to create build id
> > rather than MD5 and SHA1, no matter what the detection result is.
> > 
> > In perf/Makefile.config, from line 776
> > ```
> > ifndef NO_LIBCRYPTO
> >   ifneq ($(feature-libcrypto), 1)
> >     msg := $(warning No libcrypto.h found, disables jitted code injection,
> >             please install openssl-devel or libssl-dev);
> >     NO_LIBCRYPTO := 1
> >   else                                  <-- if libcrypto feature detected
> >     CFLAGS += -DHAVE_LIBCRYPTO_SUPPORT  <-- define this
> >     EXTLIBS += -lcrypto
> >     $(call detected,CONFIG_CRYPTO)
> >   endif
> > endif
> > ```
> > 
> > In perf/util/genelf.c, from line 33
> > ```
> > #ifdef HAVE_LIBCRYPTO                <-- but check this, it's always false
> 
> nice :)
> 
> > 
> > #define BUILD_ID_MD5
> > #undef BUILD_ID_SHA /* does not seem to work well when linked with Java */
> > #undef BUILD_ID_URANDOM /* different uuid for each run */
> > 
> > #ifdef BUILD_ID_SHA
> > #include <openssl/sha.h>
> > #endif
> > 
> > #ifdef BUILD_ID_MD5
> > #include <openssl/md5.h>
> > #endif
> > #endif                               <-- this block will be skipped
> > ```
> > 
> > Maybe we should fix this, to really make use of libcrypto if it is available?
> 
> yea, I think that was the original idea, let's keep the variable with
> SUPPORT suffix and use the -Wdeprecated-declarations for genelf.c
> 
> full fix would be to detect the new API and use it when it's available but..
> given that the check was false at least since 2016, perhaps we could remove
> that code? ;-) Stephane?

ping

jirka

  reply	other threads:[~2022-08-01 13:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-25 15:34 [PATCH] perf build: Suppress openssl v3 deprecation warnings in libcrypto feature test Zixuan Tan
2022-06-26 14:45 ` Jiri Olsa
2022-06-26 15:18   ` Arnaldo Carvalho de Melo
2022-06-27  3:08   ` 谭梓煊
2022-06-28  6:16     ` Jiri Olsa
2022-08-01 13:24       ` Jiri Olsa [this message]
2022-08-02 18:09         ` Arnaldo Carvalho de Melo
2022-08-02 18:13           ` Arnaldo Carvalho de Melo
2022-08-03  5:16             ` Zixuan Tan
2022-08-03  7:32           ` Jiri Olsa
2022-08-03 16:01             ` Arnaldo Carvalho de Melo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YufUAiLqKiuwdvcP@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eranian@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=tanzixuan.me@gmail.com \
    --cc=tanzixuangg@gmail.com \
    --cc=terrelln@fb.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).