[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170602121141.0a6de2ce@inria.fr>
Date: Fri, 2 Jun 2017 12:11:41 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Use-after-free in __unlock
Hello Joakim,
On Fri, 2 Jun 2017 07:48:36 +0200 Joakim Sindholt
<opensource@...sha.com> wrote:
> Wouldn't this be the time to consider Jens' lock?[1]
Thanks for the suggestion. I think this algorithm would in fact be
suited as a replacement for the internal lock. For the problem that
originated this thread, this algorithm is safer, because it never
dereferences the pointer to the lock after the lock is released. It
only passes the pointer to a futex_wake syscall. So eventually there
could be a spurious wake up for some completely unrelated lock that
happens to be allocated on the same address, but no dereferencing of a
deallocated variable.
The current implementation is much intertwined with the implementation
of stdatomic. While I'd still would like to maintain my long time goal
to integrate the whole package into musl, it would perhaps be
indicated to work on a more direct implementation of just the lock
algorithm in a first phase.
Thanks
Jens
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
