LinuxLists.cc - [PATCH 00/15] v5 kernel core pieces refcount conversions

2017-08-30 12:23:04

Subject: [PATCH 00/15] v5 kernel core pieces refcount conversions

Now we have at least x86 support for ARCH_HAS_REFCOUNT merged and
arm and others on their way.

Changes in v5:
* Kees catched that the following changes in
perf_event_context.refcount and futex_pi_state.refcount
are not correct now when ARCH_HAS_REFCOUNT is enabled:
- WARN_ON(!atomic_inc_not_zero(refcount));
+ refcount_inc(refcount);
So they are now changed back to using refcount_inc_not_zero.

Changes in v4:
* just rebase and corrections on linux-next/master

Changes in v3:
* SoB chain corrected
* minor corrections based on v2 feedback
* rebase on linux-next/master as of today

Changes in v2:
* dropped already merged patches
* rebase on top of linux-next/master
* Now by default refcount_t = atomic_t (*) and uses all atomic
standard operations unless CONFIG_REFCOUNT_FULL is enabled.
This is a compromise for the systems that are critical on
performance (such as net) and cannot accept even slight delay
on the refcounter operations.

This series, for core kernel components, replaces atomic_t reference
counters with the new refcount_t type and API (see include/linux/refcount.h).
By doing this we prevent intentional or accidental
underflows or overflows that can led to use-after-free vulnerabilities.

The patches are fully independent and can be cherry-picked separately.
If there are no objections to the patches, please merge them via respective trees.

Elena Reshetova (15):
sched: convert sighand_struct.count to refcount_t
sched: convert signal_struct.sigcnt to refcount_t
sched: convert user_struct.__count to refcount_t
sched: convert numa_group.refcount to refcount_t
sched/task_struct: convert task_struct.usage to refcount_t
sched/task_struct: convert task_struct.stack_refcount to refcount_t
perf: convert perf_event_context.refcount to refcount_t
perf/ring_buffer: convert ring_buffer.refcount to refcount_t
perf/ring_buffer: convert ring_buffer.aux_refcount to refcount_t
uprobes: convert uprobe.ref to refcount_t
nsproxy: convert nsproxy.count to refcount_t
groups: convert group_info.usage to refcount_t
creds: convert cred.usage to refcount_t
futex: convert futex_pi_state.refcount to refcount_t
kcov: convert kcov.refcount to refcount_t

fs/exec.c | 4 ++--
fs/proc/task_nommu.c | 2 +-
include/linux/cred.h | 13 ++++++------
include/linux/init_task.h | 7 +++---
include/linux/nsproxy.h | 6 +++---
include/linux/perf_event.h | 3 ++-
include/linux/sched.h | 5 +++--
include/linux/sched/signal.h | 5 +++--
include/linux/sched/task.h | 4 ++--
include/linux/sched/task_stack.h | 2 +-
include/linux/sched/user.h | 5 +++--
kernel/cred.c | 46 ++++++++++++++++++++--------------------
kernel/events/core.c | 18 ++++++++--------
kernel/events/internal.h | 5 +++--
kernel/events/ring_buffer.c | 8 +++----
kernel/events/uprobes.c | 8 +++----
kernel/fork.c | 24 ++++++++++-----------
kernel/futex.c | 13 ++++++------
kernel/groups.c | 2 +-
kernel/kcov.c | 9 ++++----
kernel/nsproxy.c | 6 +++---
kernel/sched/fair.c | 12 +++++------
kernel/user.c | 8 +++----
23 files changed, 112 insertions(+), 103 deletions(-)

--
2.7.4

2017-08-30 12:23:10

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 01/15] sched: convert sighand_struct.count to refcount_t

2017-08-30 12:23:27

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 05/15] sched/task_struct: convert task_struct.usage to refcount_t

2017-08-30 12:23:33

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 06/15] sched/task_struct: convert task_struct.stack_refcount to refcount_t

2017-08-30 12:23:42

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 03/15] sched: convert user_struct.__count to refcount_t

2017-08-30 12:23:47

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 08/15] perf/ring_buffer: convert ring_buffer.refcount to refcount_t

2017-08-30 12:23:53

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 10/15] uprobes: convert uprobe.ref to refcount_t

2017-08-30 12:23:58

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 11/15] nsproxy: convert nsproxy.count to refcount_t

2017-08-30 12:24:03

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 12/15] groups: convert group_info.usage to refcount_t

2017-08-30 12:24:08

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 13/15] creds: convert cred.usage to refcount_t

atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basic atomic operations
(set, inc, inc_not_zero, dec_and_test, etc.)

Such atomic variables should be converted to a newly provided
refcount_t type and API that prevents accidental counter overflows
and underflows. This is important since overflows and underflows
can lead to use-after-free situation and be exploitable.

The variable cred.usage is used as pure reference counter.
Convert it to refcount_t and fix up the operations.

Suggested-by: Kees Cook <[email protected]>
Reviewed-by: David Windsor <[email protected]>
Reviewed-by: Hans Liljestrand <[email protected]>
Signed-off-by: Elena Reshetova <[email protected]>
---
include/linux/cred.h | 6 +++---
kernel/cred.c | 44 ++++++++++++++++++++++----------------------
2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/include/linux/cred.h b/include/linux/cred.h
index 00948dd..a9f217b 100644
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -109,7 +109,7 @@ extern bool may_setgroups(void);
* same context as task->real_cred.
*/
struct cred {
- atomic_t usage;
+ refcount_t usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
atomic_t subscribers; /* number of processes subscribed */
void *put_addr;
@@ -222,7 +222,7 @@ static inline bool cap_ambient_invariant_ok(const struct cred *cred)
*/
static inline struct cred *get_new_cred(struct cred *cred)
{
- atomic_inc(&cred->usage);
+ refcount_inc(&cred->usage);
return cred;
}

@@ -262,7 +262,7 @@ static inline void put_cred(const struct cred *_cred)
struct cred *cred = (struct cred *) _cred;

validate_creds(cred);
- if (atomic_dec_and_test(&(cred)->usage))
+ if (refcount_dec_and_test(&(cred)->usage))
__put_cred(cred);
}

diff --git a/kernel/cred.c b/kernel/cred.c
index 8122d7c..49664e5 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -42,7 +42,7 @@ struct group_info init_groups = { .usage = REFCOUNT_INIT(2) };
* The initial credentials for the initial task
*/
struct cred init_cred = {
- .usage = ATOMIC_INIT(4),
+ .usage = REFCOUNT_INIT(4),
#ifdef CONFIG_DEBUG_CREDENTIALS
.subscribers = ATOMIC_INIT(2),
.magic = CRED_MAGIC,
@@ -101,17 +101,17 @@ static void put_cred_rcu(struct rcu_head *rcu)

#ifdef CONFIG_DEBUG_CREDENTIALS
if (cred->magic != CRED_MAGIC_DEAD ||
- atomic_read(&cred->usage) != 0 ||
+ refcount_read(&cred->usage) != 0 ||
read_cred_subscribers(cred) != 0)
panic("CRED: put_cred_rcu() sees %p with"
" mag %x, put %p, usage %d, subscr %d\n",
cred, cred->magic, cred->put_addr,
- atomic_read(&cred->usage),
+ refcount_read(&cred->usage),
read_cred_subscribers(cred));
#else
- if (atomic_read(&cred->usage) != 0)
+ if (refcount_read(&cred->usage) != 0)
panic("CRED: put_cred_rcu() sees %p with usage %d\n",
- cred, atomic_read(&cred->usage));
+ cred, refcount_read(&cred->usage));
#endif

security_cred_free(cred);
@@ -135,10 +135,10 @@ static void put_cred_rcu(struct rcu_head *rcu)
void __put_cred(struct cred *cred)
{
kdebug("__put_cred(%p{%d,%d})", cred,
- atomic_read(&cred->usage),
+ refcount_read(&cred->usage),
read_cred_subscribers(cred));

- BUG_ON(atomic_read(&cred->usage) != 0);
+ BUG_ON(refcount_read(&cred->usage) != 0);
#ifdef CONFIG_DEBUG_CREDENTIALS
BUG_ON(read_cred_subscribers(cred) != 0);
cred->magic = CRED_MAGIC_DEAD;
@@ -159,7 +159,7 @@ void exit_creds(struct task_struct *tsk)
struct cred *cred;

kdebug("exit_creds(%u,%p,%p,{%d,%d})", tsk->pid, tsk->real_cred, tsk->cred,
- atomic_read(&tsk->cred->usage),
+ refcount_read(&tsk->cred->usage),
read_cred_subscribers(tsk->cred));

cred = (struct cred *) tsk->real_cred;
@@ -194,7 +194,7 @@ const struct cred *get_task_cred(struct task_struct *task)
do {
cred = __task_cred((task));
BUG_ON(!cred);
- } while (!atomic_inc_not_zero(&((struct cred *)cred)->usage));
+ } while (!refcount_inc_not_zero(&((struct cred *)cred)->usage));

rcu_read_unlock();
return cred;
@@ -212,7 +212,7 @@ struct cred *cred_alloc_blank(void)
if (!new)
return NULL;

- atomic_set(&new->usage, 1);
+ refcount_set(&new->usage, 1);
#ifdef CONFIG_DEBUG_CREDENTIALS
new->magic = CRED_MAGIC;
#endif
@@ -258,7 +258,7 @@ struct cred *prepare_creds(void)
old = task->cred;
memcpy(new, old, sizeof(struct cred));

- atomic_set(&new->usage, 1);
+ refcount_set(&new->usage, 1);
set_cred_subscribers(new, 0);
get_group_info(new->group_info);
get_uid(new->user);
@@ -335,7 +335,7 @@ int copy_creds(struct task_struct *p, unsigned long clone_flags)
get_cred(p->cred);
alter_cred_subscribers(p->cred, 2);
kdebug("share_creds(%p{%d,%d})",
- p->cred, atomic_read(&p->cred->usage),
+ p->cred, refcount_read(&p->cred->usage),
read_cred_subscribers(p->cred));
atomic_inc(&p->cred->user->processes);
return 0;
@@ -426,7 +426,7 @@ int commit_creds(struct cred *new)
const struct cred *old = task->real_cred;

kdebug("commit_creds(%p{%d,%d})", new,
- atomic_read(&new->usage),
+ refcount_read(&new->usage),
read_cred_subscribers(new));

BUG_ON(task->cred != old);
@@ -435,7 +435,7 @@ int commit_creds(struct cred *new)
validate_creds(old);
validate_creds(new);
#endif
- BUG_ON(atomic_read(&new->usage) < 1);
+ BUG_ON(refcount_read(&new->usage) < 1);

get_cred(new); /* we will require a ref for the subj creds too */

@@ -500,13 +500,13 @@ EXPORT_SYMBOL(commit_creds);
void abort_creds(struct cred *new)
{
kdebug("abort_creds(%p{%d,%d})", new,
- atomic_read(&new->usage),
+ refcount_read(&new->usage),
read_cred_subscribers(new));

#ifdef CONFIG_DEBUG_CREDENTIALS
BUG_ON(read_cred_subscribers(new) != 0);
#endif
- BUG_ON(atomic_read(&new->usage) < 1);
+ BUG_ON(refcount_read(&new->usage) < 1);
put_cred(new);
}
EXPORT_SYMBOL(abort_creds);
@@ -523,7 +523,7 @@ const struct cred *override_creds(const struct cred *new)
const struct cred *old = current->cred;

kdebug("override_creds(%p{%d,%d})", new,
- atomic_read(&new->usage),
+ refcount_read(&new->usage),
read_cred_subscribers(new));

validate_creds(old);
@@ -534,7 +534,7 @@ const struct cred *override_creds(const struct cred *new)
alter_cred_subscribers(old, -1);

kdebug("override_creds() = %p{%d,%d}", old,
- atomic_read(&old->usage),
+ refcount_read(&old->usage),
read_cred_subscribers(old));
return old;
}
@@ -552,7 +552,7 @@ void revert_creds(const struct cred *old)
const struct cred *override = current->cred;

kdebug("revert_creds(%p{%d,%d})", old,
- atomic_read(&old->usage),
+ refcount_read(&old->usage),
read_cred_subscribers(old));

validate_creds(old);
@@ -611,7 +611,7 @@ struct cred *prepare_kernel_cred(struct task_struct *daemon)
validate_creds(old);

*new = *old;
- atomic_set(&new->usage, 1);
+ refcount_set(&new->usage, 1);
set_cred_subscribers(new, 0);
get_uid(new->user);
get_user_ns(new->user_ns);
@@ -735,7 +735,7 @@ static void dump_invalid_creds(const struct cred *cred, const char *label,
printk(KERN_ERR "CRED: ->magic=%x, put_addr=%p\n",
cred->magic, cred->put_addr);
printk(KERN_ERR "CRED: ->usage=%d, subscr=%d\n",
- atomic_read(&cred->usage),
+ refcount_read(&cred->usage),
read_cred_subscribers(cred));
printk(KERN_ERR "CRED: ->*uid = { %d,%d,%d,%d }\n",
from_kuid_munged(&init_user_ns, cred->uid),
@@ -809,7 +809,7 @@ void validate_creds_for_do_exit(struct task_struct *tsk)
{
kdebug("validate_creds_for_do_exit(%p,%p{%d,%d})",
tsk->real_cred, tsk->cred,
- atomic_read(&tsk->cred->usage),
+ refcount_read(&tsk->cred->usage),
read_cred_subscribers(tsk->cred));

__validate_process_creds(tsk, __FILE__, __LINE__);
--
2.7.4

2017-08-30 12:24:13

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

2017-08-30 12:24:18

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 15/15] kcov: convert kcov.refcount to refcount_t

2017-08-30 12:25:31

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 09/15] perf/ring_buffer: convert ring_buffer.aux_refcount to refcount_t

2017-08-30 12:23:38

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 07/15] perf: convert perf_event_context.refcount to refcount_t

2017-08-30 12:26:21

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 02/15] sched: convert signal_struct.sigcnt to refcount_t

2017-08-30 12:23:25

by Elena Reshetova

[permalink] [raw]

Subject: [PATCH 04/15] sched: convert numa_group.refcount to refcount_t

2017-08-31 23:48:06

by Kees Cook

[permalink] [raw]

Subject: Re: [PATCH 00/15] v5 kernel core pieces refcount conversions

On Wed, Aug 30, 2017 at 5:22 AM, Elena Reshetova
<[email protected]> wrote:
> Now we have at least x86 support for ARCH_HAS_REFCOUNT merged and
> arm and others on their way.
>
> Changes in v5:
> * Kees catched that the following changes in
> perf_event_context.refcount and futex_pi_state.refcount
> are not correct now when ARCH_HAS_REFCOUNT is enabled:
> - WARN_ON(!atomic_inc_not_zero(refcount));
> + refcount_inc(refcount);
> So they are now changed back to using refcount_inc_not_zero.

Thanks!

Reviewed-by: Kees Cook <[email protected]>

Andrew, are you able to carry these patches in -mm, since they span a
bunch of core kernel areas?

-Kees

>
> Changes in v4:
> * just rebase and corrections on linux-next/master
>
> Changes in v3:
> * SoB chain corrected
> * minor corrections based on v2 feedback
> * rebase on linux-next/master as of today
>
> Changes in v2:
> * dropped already merged patches
> * rebase on top of linux-next/master
> * Now by default refcount_t = atomic_t (*) and uses all atomic
> standard operations unless CONFIG_REFCOUNT_FULL is enabled.
> This is a compromise for the systems that are critical on
> performance (such as net) and cannot accept even slight delay
> on the refcounter operations.
>
> This series, for core kernel components, replaces atomic_t reference
> counters with the new refcount_t type and API (see include/linux/refcount.h).
> By doing this we prevent intentional or accidental
> underflows or overflows that can led to use-after-free vulnerabilities.
>
> The patches are fully independent and can be cherry-picked separately.
> If there are no objections to the patches, please merge them via respective trees.
>
>
> Elena Reshetova (15):
> sched: convert sighand_struct.count to refcount_t
> sched: convert signal_struct.sigcnt to refcount_t
> sched: convert user_struct.__count to refcount_t
> sched: convert numa_group.refcount to refcount_t
> sched/task_struct: convert task_struct.usage to refcount_t
> sched/task_struct: convert task_struct.stack_refcount to refcount_t
> perf: convert perf_event_context.refcount to refcount_t
> perf/ring_buffer: convert ring_buffer.refcount to refcount_t
> perf/ring_buffer: convert ring_buffer.aux_refcount to refcount_t
> uprobes: convert uprobe.ref to refcount_t
> nsproxy: convert nsproxy.count to refcount_t
> groups: convert group_info.usage to refcount_t
> creds: convert cred.usage to refcount_t
> futex: convert futex_pi_state.refcount to refcount_t
> kcov: convert kcov.refcount to refcount_t
>
> fs/exec.c | 4 ++--
> fs/proc/task_nommu.c | 2 +-
> include/linux/cred.h | 13 ++++++------
> include/linux/init_task.h | 7 +++---
> include/linux/nsproxy.h | 6 +++---
> include/linux/perf_event.h | 3 ++-
> include/linux/sched.h | 5 +++--
> include/linux/sched/signal.h | 5 +++--
> include/linux/sched/task.h | 4 ++--
> include/linux/sched/task_stack.h | 2 +-
> include/linux/sched/user.h | 5 +++--
> kernel/cred.c | 46 ++++++++++++++++++++--------------------
> kernel/events/core.c | 18 ++++++++--------
> kernel/events/internal.h | 5 +++--
> kernel/events/ring_buffer.c | 8 +++----
> kernel/events/uprobes.c | 8 +++----
> kernel/fork.c | 24 ++++++++++-----------
> kernel/futex.c | 13 ++++++------
> kernel/groups.c | 2 +-
> kernel/kcov.c | 9 ++++----
> kernel/nsproxy.c | 6 +++---
> kernel/sched/fair.c | 12 +++++------
> kernel/user.c | 8 +++----
> 23 files changed, 112 insertions(+), 103 deletions(-)
>
> --
> 2.7.4
>

--
Kees Cook
Pixel Security

2017-09-01 07:40:06

by Thomas Gleixner

[permalink] [raw]

Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

On Wed, 30 Aug 2017, Elena Reshetova wrote:
> atomic_t variables are currently used to implement reference
> counters with the following properties:
> - counter is initialized to 1 using atomic_set()
> - a resource is freed upon counter reaching zero
> - once counter reaches zero, its further
> increments aren't allowed
> - counter schema uses basic atomic operations
> (set, inc, inc_not_zero, dec_and_test, etc.)
>
> Such atomic variables should be converted to a newly provided
> refcount_t type and API that prevents accidental counter overflows
> and underflows. This is important since overflows and underflows
> can lead to use-after-free situation and be exploitable.
>
> The variable futex_pi_state.refcount is used as pure
> reference counter. Convert it to refcount_t and fix up
> the operations.
>
> Suggested-by: Kees Cook <[email protected]>
> Reviewed-by: David Windsor <[email protected]>
> Reviewed-by: Hans Liljestrand <[email protected]>
> Signed-off-by: Elena Reshetova <[email protected]>

Reviewed-by: Thomas Gleixner <[email protected]>

2017-09-01 09:39:10

by Peter Zijlstra

[permalink] [raw]

Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > atomic_t variables are currently used to implement reference
> > counters with the following properties:
> > - counter is initialized to 1 using atomic_set()
> > - a resource is freed upon counter reaching zero
> > - once counter reaches zero, its further
> > increments aren't allowed
> > - counter schema uses basic atomic operations
> > (set, inc, inc_not_zero, dec_and_test, etc.)
> >
> > Such atomic variables should be converted to a newly provided
> > refcount_t type and API that prevents accidental counter overflows
> > and underflows. This is important since overflows and underflows
> > can lead to use-after-free situation and be exploitable.
> >
> > The variable futex_pi_state.refcount is used as pure
> > reference counter. Convert it to refcount_t and fix up
> > the operations.
> >
> > Suggested-by: Kees Cook <[email protected]>
> > Reviewed-by: David Windsor <[email protected]>
> > Reviewed-by: Hans Liljestrand <[email protected]>
> > Signed-off-by: Elena Reshetova <[email protected]>
>
> Reviewed-by: Thomas Gleixner <[email protected]>

So the thing to be careful with for things like futex and some of the
other core kernel code is the memory ordering.

atomic_dec_and_test() provides a full smp_mb() before and after,
refcount_dec_and_test() only provides release semantics.

This is typically sufficient, and I would argue that if we rely on more
than that, there _should_ be a comment, however reality isn't always as
nice.

That said, I think this conversion is OK, pi_state->refcount isn't
relied upon to provide additional memory ordering above and beyond what
refcounting requires.

2017-09-01 09:43:34

by Thomas Gleixner

[permalink] [raw]

Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

On Fri, 1 Sep 2017, Peter Zijlstra wrote:
> On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> > On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > > atomic_t variables are currently used to implement reference
> > > counters with the following properties:
> > > - counter is initialized to 1 using atomic_set()
> > > - a resource is freed upon counter reaching zero
> > > - once counter reaches zero, its further
> > > increments aren't allowed
> > > - counter schema uses basic atomic operations
> > > (set, inc, inc_not_zero, dec_and_test, etc.)
> > >
> > > Such atomic variables should be converted to a newly provided
> > > refcount_t type and API that prevents accidental counter overflows
> > > and underflows. This is important since overflows and underflows
> > > can lead to use-after-free situation and be exploitable.
> > >
> > > The variable futex_pi_state.refcount is used as pure
> > > reference counter. Convert it to refcount_t and fix up
> > > the operations.
> > >
> > > Suggested-by: Kees Cook <[email protected]>
> > > Reviewed-by: David Windsor <[email protected]>
> > > Reviewed-by: Hans Liljestrand <[email protected]>
> > > Signed-off-by: Elena Reshetova <[email protected]>
> >
> > Reviewed-by: Thomas Gleixner <[email protected]>
>
> So the thing to be careful with for things like futex and some of the
> other core kernel code is the memory ordering.
>
> atomic_dec_and_test() provides a full smp_mb() before and after,
> refcount_dec_and_test() only provides release semantics.
>
> This is typically sufficient, and I would argue that if we rely on more
> than that, there _should_ be a comment, however reality isn't always as
> nice.
>
> That said, I think this conversion is OK, pi_state->refcount isn't
> relied upon to provide additional memory ordering above and beyond what
> refcounting requires.

So the changelogs should reflect that. The current one suggests that this
is a one to one replacement for atomic_t just with the extra sanity checks
added.

Thanks,

tglx

2017-09-01 09:48:44

by Peter Zijlstra

[permalink] [raw]

Subject: Re: [PATCH 00/15] v5 kernel core pieces refcount conversions

On Thu, Aug 31, 2017 at 04:48:00PM -0700, Kees Cook wrote:
> On Wed, Aug 30, 2017 at 5:22 AM, Elena Reshetova
> <[email protected]> wrote:
> > Now we have at least x86 support for ARCH_HAS_REFCOUNT merged and
> > arm and others on their way.
> >
> > Changes in v5:
> > * Kees catched that the following changes in
> > perf_event_context.refcount and futex_pi_state.refcount
> > are not correct now when ARCH_HAS_REFCOUNT is enabled:
> > - WARN_ON(!atomic_inc_not_zero(refcount));
> > + refcount_inc(refcount);
> > So they are now changed back to using refcount_inc_not_zero.
>
> Thanks!
>
> Reviewed-by: Kees Cook <[email protected]>
>
> Andrew, are you able to carry these patches in -mm, since they span a
> bunch of core kernel areas?

No.. these patches should go through the regular trees that maintain
these various parts.

2017-09-01 10:53:02

by Elena Reshetova

[permalink] [raw]

Subject: RE: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

> On Fri, 1 Sep 2017, Peter Zijlstra wrote:
> > On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> > > On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > > > atomic_t variables are currently used to implement reference
> > > > counters with the following properties:
> > > > - counter is initialized to 1 using atomic_set()
> > > > - a resource is freed upon counter reaching zero
> > > > - once counter reaches zero, its further
> > > > increments aren't allowed
> > > > - counter schema uses basic atomic operations
> > > > (set, inc, inc_not_zero, dec_and_test, etc.)
> > > >
> > > > Such atomic variables should be converted to a newly provided
> > > > refcount_t type and API that prevents accidental counter overflows
> > > > and underflows. This is important since overflows and underflows
> > > > can lead to use-after-free situation and be exploitable.
> > > >
> > > > The variable futex_pi_state.refcount is used as pure
> > > > reference counter. Convert it to refcount_t and fix up
> > > > the operations.
> > > >
> > > > Suggested-by: Kees Cook <[email protected]>
> > > > Reviewed-by: David Windsor <[email protected]>
> > > > Reviewed-by: Hans Liljestrand <[email protected]>
> > > > Signed-off-by: Elena Reshetova <[email protected]>
> > >
> > > Reviewed-by: Thomas Gleixner <[email protected]>
> >
> > So the thing to be careful with for things like futex and some of the
> > other core kernel code is the memory ordering.
> >
> > atomic_dec_and_test() provides a full smp_mb() before and after,
> > refcount_dec_and_test() only provides release semantics.
> >
> > This is typically sufficient, and I would argue that if we rely on more
> > than that, there _should_ be a comment, however reality isn't always as
> > nice.
> >
> > That said, I think this conversion is OK, pi_state->refcount isn't
> > relied upon to provide additional memory ordering above and beyond what
> > refcounting requires.
>
> So the changelogs should reflect that. The current one suggests that this
> is a one to one replacement for atomic_t just with the extra sanity checks
> added.

I will update the commit texts accordingly and resend the whole series since
this should be then mentioned in every commit to make sure it is not missed.

Best Regards,
Elena.

>
> Thanks,
>
> tglx

2017-09-01 11:05:40

by Elena Reshetova

[permalink] [raw]

Subject: RE: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

> On Fri, 1 Sep 2017, Peter Zijlstra wrote:
> > > On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> > > > On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > > > > atomic_t variables are currently used to implement reference
> > > > > counters with the following properties:
> > > > > - counter is initialized to 1 using atomic_set()
> > > > > - a resource is freed upon counter reaching zero
> > > > > - once counter reaches zero, its further
> > > > > increments aren't allowed
> > > > > - counter schema uses basic atomic operations
> > > > > (set, inc, inc_not_zero, dec_and_test, etc.)
> > > > >
> > > > > Such atomic variables should be converted to a newly provided
> > > > > refcount_t type and API that prevents accidental counter overflows
> > > > > and underflows. This is important since overflows and underflows
> > > > > can lead to use-after-free situation and be exploitable.
> > > > >
> > > > > The variable futex_pi_state.refcount is used as pure
> > > > > reference counter. Convert it to refcount_t and fix up
> > > > > the operations.
> > > > >
> > > > > Suggested-by: Kees Cook <[email protected]>
> > > > > Reviewed-by: David Windsor <[email protected]>
> > > > > Reviewed-by: Hans Liljestrand <[email protected]>
> > > > > Signed-off-by: Elena Reshetova <[email protected]>
> > > >
> > > > Reviewed-by: Thomas Gleixner <[email protected]>
> > >
> > > So the thing to be careful with for things like futex and some of the
> > > other core kernel code is the memory ordering.
> > >
> > > atomic_dec_and_test() provides a full smp_mb() before and after,
> > > refcount_dec_and_test() only provides release semantics.
> > >
> > > This is typically sufficient, and I would argue that if we rely on more
> > > than that, there _should_ be a comment, however reality isn't always as
> > > nice.
> > >
> > > That said, I think this conversion is OK, pi_state->refcount isn't
> > > relied upon to provide additional memory ordering above and beyond what
> > > refcounting requires.
> >
> > So the changelogs should reflect that. The current one suggests that this
> > is a one to one replacement for atomic_t just with the extra sanity checks
> > added.
>
> I will update the commit texts accordingly and resend the whole series since
> this should be then mentioned in every commit to make sure it is not missed.

Actually on the second thought: does the above memory ordering differences
really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way
how it is currently implemented for x86 is the same way as it is for atomic cases.

>
> Best Regards,
> Elena.
>
> >
> > Thanks,
> >
> > tglx

2017-09-01 12:34:40

by Peter Zijlstra

[permalink] [raw]

Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

On Fri, Sep 01, 2017 at 11:05:33AM +0000, Reshetova, Elena wrote:
> Actually on the second thought: does the above memory ordering differences
> really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way
> how it is currently implemented for x86 is the same way as it is for atomic cases.

Never look to x86 for memory ordering, its boring.

And yes, for the ARM implementation it can certainly make a difference.

2017-09-01 13:24:23

by Elena Reshetova

[permalink] [raw]

Subject: RE: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

> On Fri, Sep 01, 2017 at 11:05:33AM +0000, Reshetova, Elena wrote:
> > Actually on the second thought: does the above memory ordering differences
> > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way
> > how it is currently implemented for x86 is the same way as it is for atomic cases.
>
> Never look to x86 for memory ordering, its boring.
>
> And yes, for the ARM implementation it can certainly make a difference.

So, yes, what I am trying to say is that it can really depend if you have ARCH_HAS_REFCOUNT
enabled or not and then also based on architecture. Thus I believe is also true for atomic: there
might be differences when you use arch. dependent version of function or not.

So, I guess if I rewrite the commits, I should only include the statement on relaxed memory order
for REFCOUNT_FULL and tell that arch. specific implementations may vary on their properties
(as they do now).

2017-09-01 13:37:03

by Peter Zijlstra

[permalink] [raw]

Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

On Fri, Sep 01, 2017 at 01:24:16PM +0000, Reshetova, Elena wrote:
>
> > On Fri, Sep 01, 2017 at 11:05:33AM +0000, Reshetova, Elena wrote:
> > > Actually on the second thought: does the above memory ordering differences
> > > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way
> > > how it is currently implemented for x86 is the same way as it is for atomic cases.
> >
> > Never look to x86 for memory ordering, its boring.
> >
> > And yes, for the ARM implementation it can certainly make a difference.
>
> So, yes, what I am trying to say is that it can really depend if you have ARCH_HAS_REFCOUNT
> enabled or not and then also based on architecture. Thus I believe is also true for atomic: there
> might be differences when you use arch. dependent version of function or not.

So the generic one in lib/refcount.c is already weaker on ARM, they
don't need to do a ARCH specific 'fast' implementation for the
difference to show up.

2017-09-01 16:55:54

by Kees Cook

[permalink] [raw]

Subject: Re: [PATCH 00/15] v5 kernel core pieces refcount conversions

On Fri, Sep 1, 2017 at 2:48 AM, Peter Zijlstra <[email protected]> wrote:
> On Thu, Aug 31, 2017 at 04:48:00PM -0700, Kees Cook wrote:
>> On Wed, Aug 30, 2017 at 5:22 AM, Elena Reshetova
>> <[email protected]> wrote:
>> > Now we have at least x86 support for ARCH_HAS_REFCOUNT merged and
>> > arm and others on their way.
>> >
>> > Changes in v5:
>> > * Kees catched that the following changes in
>> > perf_event_context.refcount and futex_pi_state.refcount
>> > are not correct now when ARCH_HAS_REFCOUNT is enabled:
>> > - WARN_ON(!atomic_inc_not_zero(refcount));
>> > + refcount_inc(refcount);
>> > So they are now changed back to using refcount_inc_not_zero.
>>
>> Thanks!
>>
>> Reviewed-by: Kees Cook <[email protected]>
>>
>> Andrew, are you able to carry these patches in -mm, since they span a
>> bunch of core kernel areas?
>
> No.. these patches should go through the regular trees that maintain
> these various parts.

Okay, sounds fine. Elena, can you split these up? (You'll probably
have to examine MAINTAINERS and/or git history for each patch...)

-Kees

--
Kees Cook
Pixel Security

2017-09-01 17:04:51

by Elena Reshetova

[permalink] [raw]

Subject: RE: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

> On Fri, Sep 01, 2017 at 01:24:16PM +0000, Reshetova, Elena wrote:
> >
> > > On Fri, Sep 01, 2017 at 11:05:33AM +0000, Reshetova, Elena wrote:
> > > > Actually on the second thought: does the above memory ordering differences
> > > > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way
> > > > how it is currently implemented for x86 is the same way as it is for atomic
> cases.
> > >
> > > Never look to x86 for memory ordering, its boring.
> > >
> > > And yes, for the ARM implementation it can certainly make a difference.
> >
> > So, yes, what I am trying to say is that it can really depend if you have
> ARCH_HAS_REFCOUNT
> > enabled or not and then also based on architecture. Thus I believe is also true for
> atomic: there
> > might be differences when you use arch. dependent version of function or not.
>
> So the generic one in lib/refcount.c is already weaker on ARM, they
> don't need to do a ARCH specific 'fast' implementation for the
> difference to show up.

But can they make "fast" implementation on ARM that would give stronger memory guarantees?

2017-09-01 17:09:08

by Elena Reshetova

[permalink] [raw]

Subject: RE: [PATCH 00/15] v5 kernel core pieces refcount conversions

> On Fri, Sep 1, 2017 at 2:48 AM, Peter Zijlstra <[email protected]> wrote:
> > On Thu, Aug 31, 2017 at 04:48:00PM -0700, Kees Cook wrote:
> >> On Wed, Aug 30, 2017 at 5:22 AM, Elena Reshetova
> >> <[email protected]> wrote:
> >> > Now we have at least x86 support for ARCH_HAS_REFCOUNT merged and
> >> > arm and others on their way.
> >> >
> >> > Changes in v5:
> >> > * Kees catched that the following changes in
> >> > perf_event_context.refcount and futex_pi_state.refcount
> >> > are not correct now when ARCH_HAS_REFCOUNT is enabled:
> >> > - WARN_ON(!atomic_inc_not_zero(refcount));
> >> > + refcount_inc(refcount);
> >> > So they are now changed back to using refcount_inc_not_zero.
> >>
> >> Thanks!
> >>
> >> Reviewed-by: Kees Cook <[email protected]>
> >>
> >> Andrew, are you able to carry these patches in -mm, since they span a
> >> bunch of core kernel areas?
> >
> > No.. these patches should go through the regular trees that maintain
> > these various parts.
>
> Okay, sounds fine. Elena, can you split these up? (You'll probably
> have to examine MAINTAINERS and/or git history for each patch...)

Well, I can do this, but patches are already fully independent for cherry-pick and all maintainers
should be in the CC list, so I was hoping people can pull into their trees from this series.
But if people want to split, I can do a split...

Best Regards,
Elena.

>
> -Kees
>
> --
> Kees Cook
> Pixel Security

2017-09-01 19:12:49

by Peter Zijlstra

[permalink] [raw]

Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

On Fri, Sep 01, 2017 at 05:03:55PM +0000, Reshetova, Elena wrote:
> > On Fri, Sep 01, 2017 at 01:24:16PM +0000, Reshetova, Elena wrote:
> > >
> > > > On Fri, Sep 01, 2017 at 11:05:33AM +0000, Reshetova, Elena wrote:
> > > > > Actually on the second thought: does the above memory ordering differences
> > > > > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way
> > > > > how it is currently implemented for x86 is the same way as it is for atomic
> > cases.
> > > >
> > > > Never look to x86 for memory ordering, its boring.
> > > >
> > > > And yes, for the ARM implementation it can certainly make a difference.
> > >
> > > So, yes, what I am trying to say is that it can really depend if you have
> > ARCH_HAS_REFCOUNT
> > > enabled or not and then also based on architecture. Thus I believe is also true for
> > atomic: there
> > > might be differences when you use arch. dependent version of function or not.
> >
> > So the generic one in lib/refcount.c is already weaker on ARM, they
> > don't need to do a ARCH specific 'fast' implementation for the
> > difference to show up.
>
> But can they make "fast" implementation on ARM that would give stronger memory guarantees?

Whatever for?

2017-09-04 10:32:05

by Elena Reshetova

[permalink] [raw]

Subject: RE: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

> -----Original Message-----
> From: Peter Zijlstra [mailto:[email protected]]
> Sent: Friday, September 1, 2017 10:13 PM
> To: Reshetova, Elena <[email protected]>
> Cc: Thomas Gleixner <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t
>
> On Fri, Sep 01, 2017 at 05:03:55PM +0000, Reshetova, Elena wrote:
> > > On Fri, Sep 01, 2017 at 01:24:16PM +0000, Reshetova, Elena wrote:
> > > >
> > > > > On Fri, Sep 01, 2017 at 11:05:33AM +0000, Reshetova, Elena wrote:
> > > > > > Actually on the second thought: does the above memory ordering
> differences
> > > > > > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the
> way
> > > > > > how it is currently implemented for x86 is the same way as it is for atomic
> > > cases.
> > > > >
> > > > > Never look to x86 for memory ordering, its boring.
> > > > >
> > > > > And yes, for the ARM implementation it can certainly make a difference.
> > > >
> > > > So, yes, what I am trying to say is that it can really depend if you have
> > > ARCH_HAS_REFCOUNT
> > > > enabled or not and then also based on architecture. Thus I believe is also true
> for
> > > atomic: there
> > > > might be differences when you use arch. dependent version of function or not.
> > >
> > > So the generic one in lib/refcount.c is already weaker on ARM, they
> > > don't need to do a ARCH specific 'fast' implementation for the
> > > difference to show up.
> >
> > But can they make "fast" implementation on ARM that would give stronger
> memory guarantees?
>
> Whatever for?

Well, maybe just by default when arch.-specific implementation is done. But I was just trying to speculate
to understand. I will resend this one with new comment added.

Still not sure if I need to resend the whole series with updated commits
or break this up by individual patches further for the separate merges.

2017-09-04 12:00:27

by Peter Zijlstra

[permalink] [raw]

Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

On Mon, Sep 04, 2017 at 10:31:54AM +0000, Reshetova, Elena wrote:
> > > But can they make "fast" implementation on ARM that would give stronger
> > > memory guarantees?
> >
> > Whatever for?
>
> Well, maybe just by default when arch.-specific implementation is
> done. But I was just trying to speculate to understand. I will resend
> this one with new comment added.

So the generic lib/refcount.c already has weak ordering. It doesn't make
sense for an arch specific implementation (on a weakly ordered machine)
to provide stronger guarantees (it would make things slower).

The weaker ordering of the refcount_t primitives is sufficient if we're
talking pure refcounts. If for some reason code relies on stronger
ordering there _SHOULD_ be a comment with describing the additional
ordering requirements.

But that's a fairly big 'should'. I can well imagine the comment not
being there. In fact, see below.

> Still not sure if I need to resend the whole series with updated
> commits or break this up by individual patches further for the
> separate merges.

I've yet to look at the ones targeted at subsystems I do, I'm forever
and terminally behind on review :/

I called out the issue on futex in particular because it is fairly
tricky code that.

Now Thomas would like you to mention the fact that refcount_t doesn't
provide the exact same ordering as the atomic_t usages it replaces and
I think it would be good if you could hand-wave an argument on why the
futex code doesn't care.

Now, suppose we were to convert i_count to refcount_t (yes, I know, my
initial conversion wasn't well received), then we need to add
futex_get_inode() similar to futex_get_mm().

That is, smp_mb__{before,after}_atomic() works as expected and can be
used to fortify the implied barriers by refcount_t.

---
Subject: fs,inode: Add comment explaining additional ordering

Add a note to ihold() to document the ordering futex relies upon.

Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
---
fs/inode.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/fs/inode.c b/fs/inode.c
index 50370599e371..17192ba92fef 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -395,6 +395,10 @@ void __iget(struct inode *inode)
*/
void ihold(struct inode *inode)
{
+ /*
+ * Note: futex.c:get_futex_key_refs() relies on this function
+ * implying an smp_mb().
+ */
WARN_ON(atomic_inc_return(&inode->i_count) < 2);
}
EXPORT_SYMBOL(ihold);

2017-09-14 16:04:38

by Elena Reshetova

[permalink] [raw]

Subject: RE: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

Sorry for delayed reply.

> On Mon, Sep 04, 2017 at 10:31:54AM +0000, Reshetova, Elena wrote:
> > > > But can they make "fast" implementation on ARM that would give stronger
> > > > memory guarantees?
> > >
> > > Whatever for?
> >
> > Well, maybe just by default when arch.-specific implementation is
> > done. But I was just trying to speculate to understand. I will resend
> > this one with new comment added.
>
> So the generic lib/refcount.c already has weak ordering. It doesn't make
> sense for an arch specific implementation (on a weakly ordered machine)
> to provide stronger guarantees (it would make things slower).

Thank you for explaining this! Helps to understand a lot.
>
> The weaker ordering of the refcount_t primitives is sufficient if we're
> talking pure refcounts. If for some reason code relies on stronger
> ordering there _SHOULD_ be a comment with describing the additional
> ordering requirements.
>
> But that's a fairly big 'should'. I can well imagine the comment not
> being there. In fact, see below.
>
> > Still not sure if I need to resend the whole series with updated
> > commits or break this up by individual patches further for the
> > separate merges.
>
> I've yet to look at the ones targeted at subsystems I do, I'm forever
> and terminally behind on review :/
>
> I called out the issue on futex in particular because it is fairly
> tricky code that.
>
> Now Thomas would like you to mention the fact that refcount_t doesn't
> provide the exact same ordering as the atomic_t usages it replaces and
> I think it would be good if you could hand-wave an argument on why the
> futex code doesn't care.

I think I can mention the ordering differences on all yet-to-be-merged
patches to make sure maintainers are aware. The problem with concrete
cases is that I don't usually have enough knowledge of code to understand
for sure where it would matter or not. Previously I was even under impression
that it should not matter at all for the variables that we are converting since
they are classical refcounters, but your examples clearly show that it is not
*always* the case (but I think it is the case for most of patches).
So, I am a bit confused on how to approach this.
Either just put a statement to all patches and rely that maintainers certainly
know their code and can catch these things or do an analysis myself, but
then I would need a bit of guidance on what is the reasonable heuristics on
how check each refcounter. This goes really beyond my current
kernel knowledge, but I am happy to learn if somebody points me to smth
I can read/fill missing points.

Best Regards,
Elena.

>
>
> Now, suppose we were to convert i_count to refcount_t (yes, I know, my
> initial conversion wasn't well received), then we need to add
> futex_get_inode() similar to futex_get_mm().
>
> That is, smp_mb__{before,after}_atomic() works as expected and can be
> used to fortify the implied barriers by refcount_t.
>
> ---
> Subject: fs,inode: Add comment explaining additional ordering
>
> Add a note to ihold() to document the ordering futex relies upon.
>
> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
> ---
> fs/inode.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/inode.c b/fs/inode.c
> index 50370599e371..17192ba92fef 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -395,6 +395,10 @@ void __iget(struct inode *inode)
> */
> void ihold(struct inode *inode)
> {
> + /*
> + * Note: futex.c:get_futex_key_refs() relies on this function
> + * implying an smp_mb().
> + */
> WARN_ON(atomic_inc_return(&inode->i_count) < 2);
> }
> EXPORT_SYMBOL(ihold);