tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] bounds checking with tcc


From: Herman ten Brugge
Subject: Re: [Tinycc-devel] bounds checking with tcc
Date: Thu, 28 Nov 2019 17:57:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

Hello,

On 2019-11-28 17:08, Michael Matz wrote:
Hello,

On Wed, 27 Nov 2019, Herman ten Brugge wrote:

Exactly.  So we need to make a decision if we want that extension of the
bounds-checking feature in TCC under these constraints.  In my opinion we
don't want to, but I won't stand in the way of extending it to locals (but
then the comment needs adjustment to talk about the expected larger
overhead for each local).
I found some other code that uses the address off a local variable. See
attachment (c.c).
I can find more code like this :-(
Exactly my point.  bounds-checking in TCC is a cute hack, but nothing
more.  With other compilers gaining capabilities like sanitizers, plus
valgrind and friends, I think the value of that feature in tcc
asymptotically goes to zero.

So these hooks are deprecated. We could fix this by including our own
malloc/free routines. For a simple one see for example:
https://github.com/mattconte/tlsf
Yeah, well, there are many allocators out there, simple and complex.  I
don't think we should include any for this half-broken feature, especially
because it doesn't really help.  You would have to rewrite all calls to
malloc/free/realloc in the sources you see to redirect to the new
allocator.  The sources you don't see can't be rewritten, so any pointers
you get from libraries can't be bounds-checked.  That's the whole point of
using the malloc hooks, you can intercept _all_ calls to the allocation
routines, even from foreign libraries.  Without hooks you aren't going to
be reliable.

Of course the same can be achieved on ELF platforms via symbol
interposition.  And once you do that, you don't need hooks anymore, but
you also don't need a custom allocator.

Indeed.  But some more things are wrong: even with your full bounds patch,
but moving the definition of 's' to file global level, the output is still
wrong.
You just found another bounds checking problem :-)
Exactly :)

I fixed this with some push/pop trickery. This probably could be
improved. I have now added a minimum patch so bounds checking works a
little bit. We need still to fix the shared lib reloc problems and the
malloc/free hooks.
Do we?  Can we perhaps also simply declare bounds checking to work only
with the main executable?  Or remove that whole feature altogether?

Probably we also need to track the address off so
code runs faster.
I don't see a way for that except giving up on the single pass nature of
TCC, at which point it wouldn't be a tiny C compiler anymore.

After this long discussion I think the best thing to do is to remove the
bounds checking feature from tcc. As you mentioned there are much
better tools available today. Even allowing this only for the main
executable still gives problems (see f.c test code).
So fixing this for tcc will take quite some effort.

I can create a patch to remove bounds checking if you want.

A separate patch is the VT_LLOCAL change in x86_64-gen.c.
It will be a challenge to write a testcase for this.

Regards,

    Herman




reply via email to

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