valgrind and ubsan tests

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

valgrind and ubsan tests

Reini Urban
Hi
In light of recent bad news I checked openssl master against some of the
typical tools. (As many other I guess)
Not symbolic sat solvers yet, stp with cryptominisat is used by some
fine fuzzers, checkers and other tools already.

* valgrind https://gist.github.com/rurban/10414413

valgrind complains about uninitialised value(s) but misses apparently
the memset in the *_init() functions. Strange because I thought valgrind
is that clever and knows about memset.

* ubsan https://gist.github.com/rurban/10424468

clang's recent -fsanitizer=undefined found better problems

e.g.
c_enc.c:80:5: runtime error: shift exponent 32 is too large for 32-bit
type 'unsigned int'
obj_dat.c:151:21: runtime error: left shift of 2 by 30 places cannot be
represented in type 'int'

cbc128.c:96:41: runtime error: load of misaligned address 0x61100000824f
for type 'size_t' (aka 'unsigned long'), which requires 8 byte alignment
0x61100000824f: note: pointer points here
...


Note that -O3 without -fwrapv and undefined wrap or overflow behavior is
rather critical on some compilers, as it may do wrong optimizations.
Sooner or later. So I'm a bit worried about missing explicit wrap semantics.
Not so about missing alignments. On Intel misaligned access is actually
faster mostly, but it points at missing optimizations via SSE intrinsics.


And if in case anybody wants to study readable openssl code:
my fork at https://github.com/rurban/openssl was processed with astyle
--style=bsd
as I heard that many people very very upset about the current codingstyle.
Of course this will not be changed currently as I guess you are very
paranoid currently about so many changes.

--
Reini

Working towards a true Modern Perl.
Slim, functional, unbloated, compile-time optimizable
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: valgrind and ubsan tests

Hubert Kario
----- Original Message -----

> From: "Reini Urban" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, 10 April, 2014 11:57:32 PM
> Subject: valgrind and ubsan tests
>
> Hi
> In light of recent bad news I checked openssl master against some of the
> typical tools. (As many other I guess)
> Not symbolic sat solvers yet, stp with cryptominisat is used by some
> fine fuzzers, checkers and other tools already.
>
> * valgrind https://gist.github.com/rurban/10414413
>
> valgrind complains about uninitialised value(s) but misses apparently
> the memset in the *_init() functions. Strange because I thought valgrind
> is that clever and knows about memset.

I've seen this before, the problem was with the code, not valgrind.

Unfortunately, I don't remember what exactly was the problem.

Compile with -O0 and -ggdb, compare assembly from -O3 and -O0,
that should show what's the problem.
 

> * ubsan https://gist.github.com/rurban/10424468
>
> clang's recent -fsanitizer=undefined found better problems
>
> e.g.
> c_enc.c:80:5: runtime error: shift exponent 32 is too large for 32-bit
> type 'unsigned int'
> obj_dat.c:151:21: runtime error: left shift of 2 by 30 places cannot be
> represented in type 'int'
>
> cbc128.c:96:41: runtime error: load of misaligned address 0x61100000824f
> for type 'size_t' (aka 'unsigned long'), which requires 8 byte alignment
> 0x61100000824f: note: pointer points here
> ...
>
>
> Note that -O3 without -fwrapv and undefined wrap or overflow behavior is
> rather critical on some compilers, as it may do wrong optimizations.
> Sooner or later. So I'm a bit worried about missing explicit wrap semantics.
> Not so about missing alignments. On Intel misaligned access is actually
> faster mostly, but it points at missing optimizations via SSE intrinsics.

Ahh, if you're compiling with -O3, then you will have false positives from
valgrind.

Note that some of those cases where valgrind does complain in -O3 and does not
in -O0 may actually be caused by code itself being... let's say, suboptimal
(e.g. duplicated).

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [hidden email]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]