All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	Will Deacon <will.deacon@arm.com>,
	Elena Reshetova <elena.reshetova@intel.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <h.peter.anvin@intel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC
Date: Fri, 11 Nov 2016 00:57:14 +0100	[thread overview]
Message-ID: <20161110235714.GR3568@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CAGXu5jJz_dHt-QNqPrYFnQNhj1oV_ux62SSi=PN=VEBm6oq0Mg@mail.gmail.com>

On Thu, Nov 10, 2016 at 03:15:44PM -0800, Kees Cook wrote:
> On Thu, Nov 10, 2016 at 2:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Nov 10, 2016 at 10:13:10PM +0100, Peter Zijlstra wrote:

> >> As it stands kref is a pointless wrapper. If it were to provide
> >> something actually useful, like wrap protection, then it might actually
> >> make sense to use it.
> >
> > It provides the correct cleanup ability for a reference count and the
> > object it is in, so it's not all that pointless :)

I really fail to see the point of:

	kref_put(&obj->ref, obj_free);

over:

	if (atomic_dec_and_test(&obj->ref))
		obj_free(obj);

Utter pointless wrappery afaict.

> > But I'm always willing to change it to make it work better for people,
> > if kref did the wrapping protection (i.e. used a non-wrapping atomic
> > type), then you would have that.  I thought that was what this patchset
> > provided...

So kref could simply do something like the below patch. But this patch
set completely rapes the atomic interface.

> > And yes, this is a horridly large patchset.  I've looked at these
> > changes, and in almost all of them, people are using atomic_t as merely
> > a "counter" for something (sequences, rx/tx stats, etc), to get away
> > without having to lock it with an external lock.
> >
> > So, does it make more sense to just provide a "pointless" api for this
> > type of "counter" pattern:
> >         counter_inc()
> >         counter_dec()
> >         counter_read()
> >         counter_set()
> >         counter_add()
> >         counter_subtract()
> > Those would use the wrapping atomic type, as they can wrap all they want
> > and no one really is in trouble.  Once those changes are done, just make
> > atomic_t not wrap and all should be fine, no other code should need to
> > be changed.

Still hate; yes there's a lot of stats which are just fine to wrap. But
there's a lot more atomic out there than refcounts and stats.

The locking primitives for example use atomic_t, and they really don't
want the extra overhead associated with this overflow crap, or the
namespace pollution.

> reference counters (say, "refcount" implemented with new atomic_nowrap_t)
> 
> statistic counters (say, "statcount" implemented with new atomic_wrap_t)
> 
> everything else (named "atomic_t", implemented as either
> atomic_nowrap_t or atomic_wrap_t, depending on CONFIG)

So the problem is that atomic_t has _much_ _much_ more than just add/sub
operations, which are the only ones modified for this patch set.

The whole wrap/nowrap thing doesn't make any bloody sense what so ever
for !arith operators like bitops or just plain cmpxchg.


---
 include/linux/kref.h | 55 ++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 51 insertions(+), 4 deletions(-)

diff --git a/include/linux/kref.h b/include/linux/kref.h
index e15828fd71f1..6af1f9344793 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -39,11 +39,26 @@ static inline void kref_init(struct kref *kref)
  */
 static inline void kref_get(struct kref *kref)
 {
-	/* If refcount was 0 before incrementing then we have a race
+	/*
+	 * If refcount was 0 before incrementing then we have a race
 	 * condition when this kref is freeing by some other thread right now.
 	 * In this case one should use kref_get_unless_zero()
 	 */
-	WARN_ON_ONCE(atomic_inc_return(&kref->refcount) < 2);
+	unsigned int old, new, val = atomic_read(&kref->refcount);
+
+	for (;;) {
+		WARN_ON_ONCE(val < 1);
+
+		new = val + 1;
+		if (new < val)
+			BUG(); /* overflow */
+
+		old = atomic_cmpxchg_relaxed(&kref->refcount, val, new);
+		if (old == val)
+			break;
+
+		val = old;
+	}
 }
 
 /**
@@ -67,9 +82,23 @@ static inline void kref_get(struct kref *kref)
 static inline int kref_sub(struct kref *kref, unsigned int count,
 	     void (*release)(struct kref *kref))
 {
+	unsigned int old, new, val = atomic_read(&kref->refcount);
+
 	WARN_ON(release == NULL);
 
-	if (atomic_sub_and_test((int) count, &kref->refcount)) {
+	for (;;) {
+		new = val - count;
+		if (new > val)
+			BUG(); /* underflow */
+
+		old = atomic_cmpxchg_release(&kref->refcount, val, new);
+		if (old == val)
+			break;
+
+		val = old;
+	}
+
+	if (!new) {
 		release(kref);
 		return 1;
 	}
@@ -102,6 +131,7 @@ static inline int kref_put_mutex(struct kref *kref,
 				 void (*release)(struct kref *kref),
 				 struct mutex *lock)
 {
+	/* XXX also fix */
 	WARN_ON(release == NULL);
 	if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
 		mutex_lock(lock);
@@ -133,6 +163,23 @@ static inline int kref_put_mutex(struct kref *kref,
  */
 static inline int __must_check kref_get_unless_zero(struct kref *kref)
 {
-	return atomic_add_unless(&kref->refcount, 1, 0);
+	unsigned int old, new, val = atomic_read(&kref->refcount);
+
+	for (;;) {
+		if (!val)
+			return 0;
+
+		new = val + 1;
+		if (new < val)
+			BUG(); /* overflow */
+
+		old = atomic_cmpxchg_relaxed(&kref->refcount, val, new);
+		if (old == val)
+			break;
+
+		val = old;
+	}
+
+	return 1;
 }
 #endif /* _KREF_H_ */

  parent reply	other threads:[~2016-11-10 23:57 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-10 20:24 [kernel-hardening] [RFC v4 PATCH 00/13] HARDENED_ATOMIC Elena Reshetova
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 01/13] Add architecture independent hardened atomic base Elena Reshetova
2016-11-10 20:41   ` [kernel-hardening] " David Windsor
2016-11-10 21:09     ` Peter Zijlstra
2016-11-10 21:35   ` Peter Zijlstra
2016-11-11  9:06     ` Reshetova, Elena
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 02/13] percpu-refcount: leave atomic counter unprotected Elena Reshetova
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 03/13] kernel: identify wrapping atomic usage Elena Reshetova
2016-11-10 21:58   ` [kernel-hardening] " Peter Zijlstra
2016-11-11  8:49     ` [kernel-hardening] " Reshetova, Elena
2016-11-19 13:28   ` [kernel-hardening] " Paul E. McKenney
2016-11-19 21:39     ` Kees Cook
2016-11-21 20:13       ` Paul E. McKenney
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 04/13] mm: " Elena Reshetova
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 05/13] fs: " Elena Reshetova
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 06/13] net: " Elena Reshetova
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 07/13] net: atm: " Elena Reshetova
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 08/13] security: " Elena Reshetova
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 09/13] drivers: identify wrapping atomic usage (part 1/2) Elena Reshetova
2016-11-10 21:48   ` [kernel-hardening] " Will Deacon
2016-11-11  8:57     ` [kernel-hardening] " Reshetova, Elena
2016-11-11 12:35       ` Mark Rutland
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 10/13] drivers: identify wrapping atomic usage (part 2/2) Elena Reshetova
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 11/13] x86: identify wrapping atomic usage Elena Reshetova
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 12/13] x86: implementation for HARDENED_ATOMIC Elena Reshetova
2016-11-10 20:40   ` [kernel-hardening] " Peter Zijlstra
2016-11-10 21:04     ` Kees Cook
2016-11-10 21:16       ` Peter Zijlstra
2016-11-10 21:32         ` Kees Cook
2016-11-10 21:46           ` Peter Zijlstra
2016-11-10 22:50     ` Peter Zijlstra
2016-11-10 23:07       ` Kees Cook
2016-11-10 23:30         ` Peter Zijlstra
2016-11-11  9:32           ` [kernel-hardening] " Reshetova, Elena
2016-11-11 10:29             ` [kernel-hardening] " Peter Zijlstra
2016-11-11 18:00           ` Kees Cook
2016-11-11 20:19             ` Peter Zijlstra
2016-11-10 21:33   ` Peter Zijlstra
2016-11-11  9:20     ` [kernel-hardening] " Reshetova, Elena
2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 13/13] lkdtm: add tests for atomic over-/underflow Elena Reshetova
2016-11-10 20:37 ` [RFC v4 PATCH 00/13] HARDENED_ATOMIC Peter Zijlstra
2016-11-10 20:37   ` [kernel-hardening] " Peter Zijlstra
2016-11-10 20:48   ` Will Deacon
2016-11-10 20:48     ` [kernel-hardening] " Will Deacon
2016-11-10 21:01     ` Kees Cook
2016-11-10 21:01       ` [kernel-hardening] " Kees Cook
2016-11-10 21:23       ` David Windsor
2016-11-10 21:27         ` Kees Cook
2016-11-10 21:27           ` Kees Cook
2016-11-10 21:39           ` David Windsor
2016-11-10 21:39             ` David Windsor
2016-11-10 21:39         ` Peter Zijlstra
2016-11-10 21:13     ` Peter Zijlstra
2016-11-10 21:13       ` [kernel-hardening] " Peter Zijlstra
2016-11-10 21:23       ` Kees Cook
2016-11-10 21:23         ` [kernel-hardening] " Kees Cook
2016-11-11  4:25         ` Rik van Riel
2016-11-10 22:27       ` Greg KH
2016-11-10 23:15         ` Kees Cook
2016-11-10 23:15           ` Kees Cook
2016-11-10 23:38           ` Greg KH
2016-11-10 23:38             ` Greg KH
2016-11-11  7:50             ` David Windsor
2016-11-11 17:43               ` Kees Cook
2016-11-11 17:46                 ` Peter Zijlstra
2016-11-11 18:04                   ` Kees Cook
2016-11-11 20:17                     ` Peter Zijlstra
2016-11-14 20:31                       ` Kees Cook
2016-11-15  8:01                         ` Peter Zijlstra
2016-11-15 16:50                         ` Rik van Riel
2016-11-15 17:23                           ` Kees Cook
2016-11-16 17:09                             ` Rik van Riel
2016-11-16 17:32                               ` Peter Zijlstra
2016-11-16 17:41                                 ` Rik van Riel
2016-11-16 17:34                               ` Reshetova, Elena
2016-11-17  8:37                                 ` Peter Zijlstra
2016-11-17  9:04                                   ` Reshetova, Elena
2016-11-17  9:36                                     ` Peter Zijlstra
2016-11-17  9:36                                   ` Julia Lawall
2016-11-17 10:16                                     ` Peter Zijlstra
2016-11-17 11:19                                       ` Mark Rutland
2016-11-17 11:32                                         ` Julia Lawall
2016-11-17 12:59                                       ` Julia Lawall
2016-11-11 18:47                   ` Mark Rutland
2016-11-11 19:39                     ` Will Deacon
2016-11-11 18:31                 ` Mark Rutland
2016-11-11 20:05                   ` Peter Zijlstra
2016-11-15 10:36                     ` Mark Rutland
2016-11-15 11:21                       ` Peter Zijlstra
2016-11-15 18:02                         ` Mark Rutland
2016-11-10 23:57           ` Peter Zijlstra [this message]
2016-11-10 23:57             ` Peter Zijlstra
2016-11-11  0:29             ` Colin Vidal
2016-11-11 12:41               ` Mark Rutland
2016-11-11 12:47                 ` Peter Zijlstra
2016-11-11 13:00                   ` Peter Zijlstra
2016-11-11 14:39                     ` Thomas Gleixner
2016-11-11 14:48                       ` Peter Zijlstra
2016-11-11 23:07                     ` Peter Zijlstra
2016-11-13 11:03             ` Greg KH
2016-11-13 11:03               ` Greg KH
2016-11-10 20:56   ` Kees Cook
2016-11-10 20:56     ` [kernel-hardening] " Kees Cook
2016-11-11  3:20     ` David Windsor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161110235714.GR3568@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=arnd@arndb.de \
    --cc=elena.reshetova@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=h.peter.anvin@intel.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.