[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202005291309.6183EC0604@keescook>
Date: Fri, 29 May 2020 13:14:56 -0700
From: Kees Cook <keescook@...omium.org>
To: Sargun Dhillon <sargun@...gun.me>
Cc: christian.brauner@...ntu.com,
containers@...ts.linux-foundation.org, cyphar@...har.com,
jannh@...gle.com, jeffv@...gle.com, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org, palmer@...gle.com, rsesek@...gle.com,
tycho@...ho.ws, Matt Denton <mpdenton@...gle.com>
Subject: Re: [PATCH v2 1/3] seccomp: Add find_notification helper
On Fri, May 29, 2020 at 05:40:38PM +0000, Sargun Dhillon wrote:
> >
> > While the comment is good, let's actually enforce this with:
> >
> > if (WARN_ON(!mutex_is_locked(&filter->notif_lock)))
> > return NULL;
> >
> I don't see much use of lockdep in seccomp (well, any), but
> wouldn't a stronger statement be to use lockdep, and just have:
>
> lockdep_assert_held(&filter->notify_lock);
>
> As that checks that the lock is held by the current task.
/me slaps his forehead
Yes. I need more coffee or something. Yes, I meant
lockdep_assert_held(), and now I need to go fix my pstore series since I
confused myself into the wrong function and using it so many times in
pstore overwrote the correct function in my head. Thank you!
> Although, that does put this check behind lockdep, which means
> that running in "normal" circumstances is less safe (but faster?).
Now, that's fine. The check needs to be "am *I* holding this mutex?" and
I don't think anything except lockdep can do that.
--
Kees Cook
Powered by blists - more mailing lists