valgrind complaining about s_client (maybe assembler code?)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

valgrind complaining about s_client (maybe assembler code?)

Stephen Farrell

Hiya,

I'm seeing some errors from valgrind when running s_client
from a clean build from the tip. (Details of that below.)

In another build, (for ESNI), when I do a GCM encrypt and
then read the tag, it looks like the error is coming from
some sha256 assembler code:

==27027==  Uninitialised value was created by a stack allocation
==27027==    at 0x4B0ED63: sha256_block_data_order_avx2
(sha256-x86_64.s:4192)

Building either (clean or my ESNI fork) with "no-asm"
works without valgrind complaining, as do other debug
builds, but it seems like once optimisation is turned
on, these errors occur. They don't however, seem to
affect correct operation of TLS though (in either build).

On a 32-bit system the ESNI build also seems fine with
or without optimisation.

Details below for a clean clone from github. The full
valgrind/s_client output with stdout & stderr can be
found at [1].

I manually added a "-g" to the Makefile (leaving on
"-O3" as well), and the equivalent output is at [2]
and seems to show that valgrind sees the error around
some GCM tag handling code again.

The equivalent output when built with "no-asm" is
at [3] and has no valgrind errors.

Any ideas?

Thanks,
S.

[1] https://down.dsg.cs.tcd.ie/misc/vgerrs.txt
[2] https://down.dsg.cs.tcd.ie/misc/vgerrs-sym.txt
[3] https://down.dsg.cs.tcd.ie/misc/vgnoasm.txt

My system:

Machine: Dell XPS13
OS: Ubuntu 19.10 up to date
CPU: Intel® Core™ i7-10510U CPU @ 1.80GHz × 8
The build is using gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008

The first error seen for the clean build from the tip is:

==19663== Conditional jump or move depends on uninitialised value(s)
==19663==    at 0x4B6F962: gcm_stream_final (in
/home/stephen/code/openssl-clean-upstream/libcrypto.so.3)
==19663==    by 0x4A7BE35: EVP_DecryptFinal_ex (in
/home/stephen/code/openssl-clean-upstream/libcrypto.so.3)
==19663==    by 0x4899256: tls13_enc (in
/home/stephen/code/openssl-clean-upstream/libssl.so.3)
==19663==    by 0x4897AED: ssl3_get_record (in
/home/stephen/code/openssl-clean-upstream/libssl.so.3)
==19663==    by 0x4894D27: ssl3_read_bytes (in
/home/stephen/code/openssl-clean-upstream/libssl.so.3)
==19663==    by 0x48AE320: tls_get_message_header (in
/home/stephen/code/openssl-clean-upstream/libssl.so.3)
==19663==    by 0x48A44FC: state_machine.part.0 (in
/home/stephen/code/openssl-clean-upstream/libssl.so.3)
==19663==    by 0x48942B7: ssl3_write_bytes (in
/home/stephen/code/openssl-clean-upstream/libssl.so.3)
==19663==    by 0x487B868: ssl_write_internal (in
/home/stephen/code/openssl-clean-upstream/libssl.so.3)
==19663==    by 0x487BA96: SSL_write (in
/home/stephen/code/openssl-clean-upstream/libssl.so.3)
==19663==    by 0x172E5A: s_client_main (in
/home/stephen/code/openssl-clean-upstream/apps/openssl)
==19663==    by 0x160105: do_cmd (in
/home/stephen/code/openssl-clean-upstream/apps/openssl)

The commands I used to build and generate the errors:

$ cd $HOME/code
$ git clone https://github.com/openssl/openssl.git openssl-clean-upstream
$ cd openssl-clean-upstream
$ ./config
... stuff ...
$ make -j8
... stuff ...
$ export LD_LIBRARY_PATH=$HOME/code/openssl-clean-upstream
$ echo -e "GET /" | valgrind ./apps/openssl s_client -msg -debug
-CApath /etc/ssl/certs/ -no_ssl3 -no_tls1 -no_tls1_1 -no_tls1_2
-connect www.cloudflare.com:443   -servername www.cloudflare.com
>vgerrs.txt 2>&1

0x5AB2FAF17B172BEA.asc (10K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: valgrind complaining about s_client (maybe assembler code?)

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Stephen Farrell
> Sent: Monday, November 11, 2019 09:53
>
> I'm seeing some errors from valgrind when running s_client
> from a clean build from the tip. (Details of that below.)

Have you reviewed past discussions about valgrind and OpenSSL?

https://duckduckgo.com/html?q=site%3Amta.openssl.org%20openssl-users%20valgrind

In general, memory-use checkers such as valgrind's memcheck are going to be suspicious of some aspects of OpenSSL, which makes some assumptions about memory that it knows are suitable, but which cannot generally be verified by typical static or dynamic analysis.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


Reply | Threaded
Open this post in threaded view
|

Re: valgrind complaining about s_client (maybe assembler code?)

Stephen Farrell

Hiya,

On 11/11/2019 16:50, Michael Wojcik wrote:
>> From: openssl-users [mailto:[hidden email]] On
>> Behalf Of Stephen Farrell Sent: Monday, November 11, 2019 09:53
>>
>> I'm seeing some errors from valgrind when running s_client from a
>> clean build from the tip. (Details of that below.)
>
> Have you reviewed past discussions about valgrind and OpenSSL?

I wouldn't say I reviewed it all in detail no, but yep, I
did spend a while checking and didn't find the same issue.
(Apologies if I missed it, which is always possible;-)

> https://duckduckgo.com/html?q=site%3Amta.openssl.org%20openssl-users%20valgrind
>
>  In general, memory-use checkers such as valgrind's memcheck are
> going to be suspicious of some aspects of OpenSSL, which makes some
> assumptions about memory that it knows are suitable, but which cannot
> generally be verified by typical static or dynamic analysis.

Sure. OTOH, I didn't see these errors until just now when
I rebased with upstream so they seem to be new, (in the
last couple of months), or I guess could be down to some
novelty with my CPU/compiler, given I'm using a brand new
laptop and Ubuntu 19.10;-)

FWIW, valgrind hasn't been giving me false positives over
the last year or so, and has been v. useful in finding
leaks, so it'd be nice if there were a fix or better
workaround than "no-asm" (but since I do have "no-asm",
and don't need go-faster-stripes, this isn't urgent for
me).

Cheers,
S.

>
> -- Michael Wojcik Distinguished Engineer, Micro Focus
>
>

0x5AB2FAF17B172BEA.asc (10K) Download Attachment
signature.asc (849 bytes) Download Attachment