[suggestion] tcache double-free check

[Eyal Itkin]

OK, in a few days I will send a patch that will use a direct call to
getrandom so to init the key.
As the function call may fail (maybe there won't be enough entropy),
on failure it will default to the alternative suggestion of using
"!tcache" instead of "tcache".


On Fri, Jul 24, 2020 at 12:26 AM Carlos O'Donell via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On 7/23/20 8:06 AM, Florian Weimer wrote:
> > * Adhemerval Zanella via Libc-alpha:
> >
> >> On 22/07/2020 23:35, Carlos O'Donell via Libc-alpha wrote:
> >>> On 7/21/20 2:03 AM, Florian Weimer wrote:
> >>>> * Carlos O'Donell:
> >>>>
> >>>>>> Instead of using some arbitrary constant or coming up with a fancy
> >>>>>> random value, is it possible we update the key to something that won't
> >>>>>> point to a critical memory management struct such as the tcache
> >>>>>> control block? I suggest a simple change that will ensure that the
> >>>>>> value used won't be a pointer that can be dereferenced: ~tcache
> >>>>>> (instead of tcache). The bitwise not costs a mere 1 CPU cycle, while
> >>>>>> making sure the key won't be a valid memory address.
> >>>>>
> >>>>> That sounds good to me.
> >>>>>
> >>>>> I assume the point being that you can't use a "memory derefernce"
> >>>>> gadget directly with that memory, you'd need some other primitive
> >>>>> to process the ~tcache.
> >>>>
> >>>> Why can't we use a random marker value?  Then we don't leak an address,
> >>>> either.
> >>>
> >>> I'm not against it, but we'd need something that is random, and for that
> >>> we need entropy. What have we got to use?
> >>
> >> We have include/random-bits.h which get some entropy from the clock
> >> (and shuffle the bits to avoid some clock bias). It is far from perfect,
> >> but it is used internally on some specific cases.
> >>
> >> Another possibility if a more robust random source is requires would be
> >> to try work on the arc4random patch proposal from Florian.
> >
> > For a one-time initialization, we could call getrandom directly.  (And
> > hope that seccomp filters do not terminate the process.)
>
> I'm OK with that.
>
> --
> Cheers,
> Carlos.
>