linux-kernel - Re: [RFC][PATCH -v2 1/4] locking/drm/i915: Kill mutex trickery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160826032509.GA29502@rhlx01.hs-esslingen.de>
Date:   Fri, 26 Aug 2016 05:25:09 +0200
From:   Andreas Mohr <andi@...as.de>
To:     Waiman Long <Waiman.Long@....com>
Cc:     Daniel Vetter <daniel.vetter@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH -v2 1/4] locking/drm/i915: Kill mutex trickery

Hi,

[no properly binding reference via In-Reply-To: available thus manually re-creating, sorry]

> > But initerim I guess we could set our own owner field and check that
> > to keep the duct-tape from getting off completely.
> > -Daniel
> 
> Another alternative is to provide a standard mutex API that returns the
> owner of the lock if there is a real need for this capability. Peeking
> into lock internal is not a good practice.

>From personal experience here I would suggest that
the core issue here is that
this would create an inherently race-window-tainted API,
which clearly is something to be avoided:

The point is that the lock *owner* value is *volatile*
whenever it is *not* our own context instance
that is currently holding the lock
while querying this API
(i.e., thus not guaranteeing that the owner value will *not* be changed interim!),
since in such a situation
(not-privately-locked case!!)
lock ownership may change at any point from under
our just-observed result value.

Returning such inherently racy information from a publicly offered mutex API
is, errrrr, not so good, to put it rather mildly.

So, it seems the most we could provide
which would offer a reliable, non-racy API protocol
is something like:

static bool mutex_is_locked_by_us(struct mutex *mutex)

since during execution of this processing it would be guaranteed that:
- either we do have the lock, thus *we* *RELIABLY* are and will be "the owner"
- or we simply do not have it, thus *we* *RELIABLY* are and will be "not the owner"


[but note that in that case
this mutex API implementation code would have
a potentially unholy dependency on task stuff such as "current",
but which it probably already has anyway]

HTH,

Andreas Mohr