[Toybox] Kernighan's awk repo

[Rob Landley]

On 07/21/2016 11:21 AM, enh wrote:
> On Thu, Jul 21, 2016 at 1:46 AM, Rob Landley <rob at landley.net> wrote:
>> Adding a NOSTRIP target to the makefile: you can already set NOSTRIP=1
>> as an environment variable and scripts/make.sh will skip calling strip,
>> and even when it _does_ the original unstripped version goes in
>> generated/unstripped.
> 
> (having both is really handy. Android does this too. i make use of it
> all the time, for both projects.)

Actually I misread this on the first run through and it's not adding a
target, it's adding it to the export list.

> asan doesn't produce false positives. it's run-time checks, and if it
> says something just went wrong, it actually did.

It looks like the asan support boils down to:

NOSTRIP=1 CC=$CLANG_DIR/bin/clang CFLAGS="-fsanitize=address -g" make

And two or three other options which may or may not be combinable?

Sigh, I'm building llvm 3.8.0 here so following the blfs instructions so
I can reproduce this. (what on earth is clang-analyzer? I take it _that_
is the static analysis tool I was thinking of?)

> the closest it gets is where you _are_ reading uninitialized data but
> you happen to not surface that to the user. (toybox ls had this bug.)

's not a bug if you never use the result. Not unless you enable
something that traps on an integer overflow or similar.

(Yes performing a calculation that's never used sucks, but it's faster
and smaller to traverse the whole array than to test whether each one is
needed in each flag combination. I believe the "fix" was to initialize
the unused field to 0 and still perform the calculation that wasn't used.)

> but that's still a bad idea, and not fixing bad style like that (which
> you did fix) means you can't use asan to find all the other bugs. that
> would definitely be throwing the baby out with the bathwater. i think
> it's an open question how security-critical we should consider the
> various things implemented by toybox. my personal opinion is toward
> the "not at all" end of the spectrum,

I want them to be secure. I'm just not convinced these tools help.

Sigh, Linus was against kgdb for the longest time, and there was no
reason not to let OTHER people use a thing he didn't personally want to
use, so I'm not trying to _block_ this. I'm also trying to minimize the
intrusiveness and I didn't prioritize it until people argued so much
about it that putting other work to the side and dealing with this for a
bit becomes a net time saver just to stop having to write long emails
about it.

But there ARE lots of different things in this patch, including moving
generated to a variable (which is not called $GENERATED).

> but i _do_ care about /bin being
> reliable, and asan helps correctness. even if there's no reason for
> users to panic when ps segfaults or shows incorrect data, it's still
> annoying for developers.

Nothing in toybox should ever segfault. Segfaults jump to the top of the
queue.

Incorrect data is more of a gray area. Ubuntu's du shows 1024M where
mine shows 1.0G. (Commit d06ea3708d12.) I think mine is correct and
theirs is wrong. Similarly this grep -ov stuff, and ls

> security (lack of), particularly memory safety (lack of) is the
> asteroid that will kill a lot of our beloved C dinosaurs (such as the
> Linux kernel). tools like asan and kasan buy Barney and friends some
> extra time.

I'll believe go/swift/rust when I see it.

> (unlike valgrind, the asan overhead is low enough that you can often
> actually use asan-sanitized binaries for real work. mileage may vary
> on a netbook :-) )

I know how expensive my code is to run. :)

Rob