Re: [Tinycc-devel] bounds checking with tcc

[Michael Matz]

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.


Ciao,
Michael.


> 
> Regards,
> 
>     Herman
> >
> >
> > Ciao,
> > Michael.
> >> Hope this explains things.
> >>
> >> Regards,
> >>
> >>      Herman
> >>>> I will stop now because bounds checking looks not to work for complex
> >>>> applications.
> >>>>
> >>>> Perhaps we could add the above code to git? The first and last one are
> >>>> fixing problems. For the last problem I have a testcase that reproduces
> >>>> the VT_LLOCAL problem.
> >>> So, I'm against the libtcc1.a linking change; it might benefit bounds
> >>> checking right now, but worsens the situation for everything else.  The
> >>> VT_LLOCAL problem indeed should be fixed (but see above), especially if
> >>> you have a testcase.  The change to gen_static_call should be unnecessary
> >>> with the libtcc1 change.  To bounds-check all variables, not just arrays,
> >>> seems to be a fairly aggressive change, I think it's not really
> >>> appropriate at this time.
> >>>
> >>>
> >>> Ciao,
> >>> Michael.
> >>
> 
> 
>