coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new snapshot available: coreutils-8.29.64-1755f.tar.xz


From: Kamil Dudka
Subject: Re: new snapshot available: coreutils-8.29.64-1755f.tar.xz
Date: Mon, 02 Jul 2018 10:38:50 +0200

On Sunday, July 1, 2018 3:37:36 AM CEST Pádraig Brady wrote:
> On 28/06/18 02:56, Kamil Dudka wrote:
> > On Thursday, June 28, 2018 5:59:13 AM CEST Pádraig Brady wrote:
> >> Note one should define 'lint' when running static analysis,
> >> to avoid false positives.
> > 
> > Yes and no.  Because, if you do, you will analyze different code than you
> > run in production builds.  You might be able to prove correctness of the
> > code now but, if you mute static analyzers by adding IF_LINT(=0) and
> > passing -Dlint to preprocessor, you will not be notified later on when
> > some tiny change in the copy_internal() function (or even in the calling
> > context) causes a real use of uninitialized contents of stack.
> 
> It's more subtle than that.
> For most dev work, lint should be defined to avoid
> mem leak check and static analysis false positives.
> This is due to leak checker not knowing process is about to end,
> and static analyzer limitations (often with cross module issues).
> Ideally we'd not need to guard initializations like this at all.

I do not think there is a major difference between static an dynamic analysis 
in this regard.  The IF_LINT(=0) constructs can hide real programming mistakes 
for both static and dynamic analyzers if used incorrectly.  They are probably 
used "correctly" now but the situation may silently change as side effect of 
future code changes, leading to undefined behavior in production not visible 
by static analyzers.

> On the other hand we do _not_ want define lint for ASAN runs.
> I.E. we want to avoid default init for release builds due to
> perf of redundant init and free().
> For ASAN we want to avoid the redundant init so
> that a UMR is actually flagged.  For example in this case
> reading a zeroed stat would not be flagged by ASAN but
> would be a logic error.
> zeroing a stat buffer as init is always incorrect
> and should not be in prod code.

Take it as a hardening technique.  Other commonly used hardening techniques
on a modern operating system have bigger performance impact than this.

Kamil

> cheers,
> Pádraig





reply via email to

[Prev in Thread] Current Thread [Next in Thread]