Re: Crash Analysis: Finalizer Logic in singlestep function can lead to Sandbox Escape Exploit

[Viacheslav Usov <via.usov@...>]

On Sat, Dec 4, 2021 at 7:45 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>
> Thinking about all the cases,  I would consider a more radical
> solution. Maybe we should forbid any GC operation while running
> a finalizer. As we discussed several times in the past, finalizers
> should be used to free resources that cannot be freed by the GC;
> period. The less they should do, the better. But that can be a
> too radical change for a bug-fix release.

I'd suggest considering another radical change. Instead of
"finalizers", let a C library that creates user data supply a
"destructor" that is called by GC just before a given datum is
positively going to be deallocated. Essentially like a C++ destructor.
C libraries can be obliged to do "as little as possible" in
destructors. The destructors (unlike the finalizers) should not be
callable from Lua code. Then, a C library should be able to query what
the destructor (address) for a given user datum is - this will make it
possible to check that a given user datum is what it expects. Changing
destructors after data creation should be impossible to keep the
identity of user data immutable. As a further optimization, the (new)
user datum creation API may accept an indication that no storage for a
metatable pointer is needed.

This does not address the problem of finalizers, but this addresses
the problem of simplicity and correctness of C libraries, because they
can use this much simpler mechanism in probably every case they have
to use metatables and finalizers now, which is not very easy to get
right, as we discussed in the thread "[BUG] unsafe metatable paradigm"
of 2019. Note that destructors would also automatically take care of
most of the "to be closed" chores.

Needless to say, this is not for a bug-fix release.

Cheers,
V.