openssl 3.0.0 valgrind failure on OPENSSL_ia32_cpuid

[William Roberts]

On Fri, Aug 27, 2021 at 2:47 PM Ken Goldman <kgoldman at us.ibm.com> wrote:
>
> I run valgrind on all my software to find memory leaks.  This worked for
> openssl 1.0.2 and 1.1.1, but fails with 3.0.0.  Suggestions?
>
> vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x49 0x89 0xD8 0x31
> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=1
> ==29625== valgrind: Unrecognised instruction at address 0x56b2b10.
> ==29625==    at 0x56B2B10: OPENSSL_ia32_cpuid (x86_64cpuid.s:36)
> ==29625==    by 0x569FA37: OPENSSL_cpuid_setup (cpuid.c:147)
> ==29625==    by 0x55163C2: ??? (in /home/kgold/openssl30/libcrypto.so.3)
> ==29625== Your program just tried to execute an instruction that Valgrind
> ==29625== did not recognise.  There are two possible reasons for this.
> ==29625== 1. Your program has a bug and erroneously jumped to a non-code
> ==29625==    location.  If you are running Memcheck and you just saw a
> ==29625==    warning about a bad jump, it's probably your program's fault.
> ==29625== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==29625==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==29625==    you are not sure, please let us know and we'll try to fix it.
> ==29625== Either way, Valgrind will now raise a SIGILL signal which will
> ==29625== probably kill your program.
> ==29625==
> ==29625== Process terminating with default action of signal 4 (SIGILL)
> ==29625==  Illegal opcode at address 0x56B2B10
> ==29625==    at 0x56B2B10: OPENSSL_ia32_cpuid (x86_64cpuid.s:36)
> ==29625==    by 0x569FA37: OPENSSL_cpuid_setup (cpuid.c:147)
> ==29625==    by 0x55163C2: ??? (in /home/kgold/openssl30/libcrypto.so.3)
>

I stopped using valgrind awhile ago, because I had too many issues
with false positives, etc.
I really noticed this when dealing with glib/dbus. At this time, I
made the switch to ASAN and
both gcc and clang support it and the diagnostics have been better
than anything I got with
valgrind; it's been many years and I never looked back.

Just google your compiler and asan and you should get guides, but in
general it's as easy
as adding CFLAGS='-O0 -g -fsanitize=address -fno-omit-frame-pointer'

Then just run the binary as normal. You may need to set up the
symbolizer to resolve addresses
to file/line names. IIRC its via the ASAN_SYMBOLIZER_PATH and that is
discussed further in the ASAN
docs.

I would give that a try, that's what I am using for OpenSSL 3.0
integration and fuzzing in my CI's

Bill