linux.kernel - 26 new messages in 17 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* panic: setup panic_timeout early - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/b9ad085825bd3729?hl=en
* set_dumpable: fix the theoretical race with itself - 4 messages, 1 author
http://groups.google.com/group/linux.kernel/t/60f0240f00deb328?hl=en
* of/selftest: Add self tests for manipulation of properties - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/b615f15949c4ee2e?hl=en
* 3.12.0-rt2 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/122282eab30eec0a?hl=en
* staging/lustre: validate open handle cookies - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b9af2ffb60231fd2?hl=en
* aio: fix D-cache aliasing issues - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/e2884c60a25d22cc?hl=en
* of: remove /proc/device-tree - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c5856b4587eb9bca?hl=en
* kstrtox: remove redundant cleanup - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/f284ec730d289d67?hl=en
* documentation: Update circular buffer for load-acquire/store-release - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/9d3de39c23ef46a9?hl=en
* Fwd: [PATCH 1/8] watchdog: davinci: change driver to use WDT core - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/7567b784f9bce690?hl=en
* Fix NX-related Oops in wistron_btns module - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9a2c66ecc07ce7cd?hl=en
* x86/copy_user.S: Remove zero byte check before copy user buffer. - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/d9930d0ca010c5a8?hl=en
* afs: dir: remove unused label out_skip - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/652928071b0d20c8?hl=en
* mm: create a separate slab for page->ptl allocation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2bb284a987e3ac30?hl=en
* wait_for_completion_timeout() considered harmful. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f5d04ee768cd59a6?hl=en
* Please pull NFS client bugfixes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/23ff3acc912d37d1?hl=en
* possible divide by 0 in kernel/sched/cputime.c scale_stime() - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/69205b58e29526bd?hl=en

==============================================================================
TOPIC: panic: setup panic_timeout early
http://groups.google.com/group/linux.kernel/t/b9ad085825bd3729?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Nov 16 2013 10:50 am
From: Felipe Contreras


On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar <mingo@kernel.org> wrote:
> * Felipe Contreras <felipe.contreras@gmail.com> wrote:

> Anyway, the fact that you are argumentative even with Linus gives me
> little hope that you will improve your communication patterns with
> _me_, so I'm personally done arguing with you.

How am I being argumentative? I avoided all arguments.

>> You don't want to argue? Then don't argue. Apply the patch. [...]
>
> *Plonk*.

This is exactly the opposite of what is conducive to less argumentation.

If you are not going to comment on the patch, then don't say anything.

The patch is good, and the fact that both you and Linus are avoiding
any comments in the patch itself doesn't speak well for your
intentions to avoid argumentation.

So I ask you again. Do you see something wrong with the patch?

--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 3 ==
Date: Sat, Nov 16 2013 12:20 pm
From: Levente Kurusa


2013-11-16 19:46 keltezéssel, Felipe Contreras írta:
> On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar <mingo@kernel.org> wrote:
>> * Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> Anyway, the fact that you are argumentative even with Linus gives me
>> little hope that you will improve your communication patterns with
>> _me_, so I'm personally done arguing with you.
>
> How am I being argumentative? I avoided all arguments.
>
>>> You don't want to argue? Then don't argue. Apply the patch. [...]
>>
>> *Plonk*.
>
> This is exactly the opposite of what is conducive to less argumentation.
>
> If you are not going to comment on the patch, then don't say anything.
>
> The patch is good, and the fact that both you and Linus are avoiding
> any comments in the patch itself doesn't speak well for your
> intentions to avoid argumentation.
>
> So I ask you again. Do you see something wrong with the patch?
>

Yes, you.

--
Regards,
Levente Kurusa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 3 of 3 ==
Date: Sat, Nov 16 2013 12:30 pm
From: Levente Kurusa


2013-11-16 19:46 keltezéssel, Felipe Contreras írta:
> On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar <mingo@kernel.org> wrote:
>> * Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> Anyway, the fact that you are argumentative even with Linus gives me
>> little hope that you will improve your communication patterns with
>> _me_, so I'm personally done arguing with you.
>
> How am I being argumentative? I avoided all arguments.
>
>>> You don't want to argue? Then don't argue. Apply the patch. [...]
>>
>> *Plonk*.
>
> This is exactly the opposite of what is conducive to less argumentation.
>
> If you are not going to comment on the patch, then don't say anything.
>
> The patch is good, and the fact that both you and Linus are avoiding
> any comments in the patch itself doesn't speak well for your
> intentions to avoid argumentation.
>
> So I ask you again. Do you see something wrong with the patch?
>

Out-of-joke, the patch is now in an 'appliable' state.

You can add my:
Reviewed-by: Levente Kurusa <levex@linux.com>

--
Regards,
Levente Kurusa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: set_dumpable: fix the theoretical race with itself
http://groups.google.com/group/linux.kernel/t/60f0240f00deb328?hl=en
==============================================================================

== 1 of 4 ==
Date: Sat, Nov 16 2013 11:10 am
From: Oleg Nesterov


set_dumpable() updates MMF_DUMPABLE_MASK in a non-trivial way to
ensure that get_dumpable() can't observe the intermediate state,
but this all can't help if multiple threads call set_dumpable()
at the same time.

And in theory commit_creds()->set_dumpable(SUID_DUMP_ROOT) racing
with sys_prctl()->set_dumpable(SUID_DUMP_DISABLE) can result in
SUID_DUMP_USER.

Change this code to update both bits atomically via cmpxchg().

Note: this assumes that it is safe to mix bitops and cmpxchg. IOW,
if, say, an architecture implements cmpxchg() using the locking
(like arch/parisc/lib/bitops.c does), then it should use the same
locks for set_bit/etc.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
fs/exec.c | 49 +++++++++++++++----------------------------------
1 files changed, 15 insertions(+), 34 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index bb8afc1..613c9dc 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1621,43 +1621,24 @@ EXPORT_SYMBOL(set_binfmt);

/*
* set_dumpable converts traditional three-value dumpable to two flags and
- * stores them into mm->flags. It modifies lower two bits of mm->flags, but
- * these bits are not changed atomically. So get_dumpable can observe the
- * intermediate state. To avoid doing unexpected behavior, get get_dumpable
- * return either old dumpable or new one by paying attention to the order of
- * modifying the bits.
- *
- * dumpable | mm->flags (binary)
- * old new | initial interim final
- * ---------+-----------------------
- * 0 1 | 00 01 01
- * 0 2 | 00 10(*) 11
- * 1 0 | 01 00 00
- * 1 2 | 01 11 11
- * 2 0 | 11 10(*) 00
- * 2 1 | 11 11 01
- *
- * (*) get_dumpable regards interim value of 10 as 11.
+ * stores them into mm->flags.
*/
void set_dumpable(struct mm_struct *mm, int value)
{
- switch (value) {
- case SUID_DUMP_DISABLE:
- clear_bit(MMF_DUMPABLE, &mm->flags);
- smp_wmb();
- clear_bit(MMF_DUMP_SECURELY, &mm->flags);
- break;
- case SUID_DUMP_USER:
- set_bit(MMF_DUMPABLE, &mm->flags);
- smp_wmb();
- clear_bit(MMF_DUMP_SECURELY, &mm->flags);
- break;
- case SUID_DUMP_ROOT:
- set_bit(MMF_DUMP_SECURELY, &mm->flags);
- smp_wmb();
- set_bit(MMF_DUMPABLE, &mm->flags);
- break;
- }
+ unsigned long old, new;
+
+ do {
+ old = ACCESS_ONCE(mm->flags);
+ new = old & ~MMF_DUMPABLE_MASK;
+
+ switch (value) {
+ case SUID_DUMP_ROOT:
+ new |= (1 << MMF_DUMP_SECURELY);
+ case SUID_DUMP_USER:
+ new |= (1<< MMF_DUMPABLE);
+ }
+
+ } while (cmpxchg(&mm->flags, old, new) != old);
}

int __get_dumpable(unsigned long mm_flags)
--
1.5.5.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 4 ==
Date: Sat, Nov 16 2013 11:10 am
From: Oleg Nesterov


On 11/15, Kees Cook wrote:
>
> On Fri, Nov 15, 2013 at 12:36 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > unless I missed something, this is the fix, not cleanup ?
> >
> > If commit_creds()->set_dumpable(SUID_DUMP_ROOT) races with
> > sys_prctl()->set_dumpable(SUID_DUMP_DISABLE), we can get
> > SUID_DUMP_USER afaics.
> >
> > Yes, yes, even if I am right this race is very unlikely.
>
> Hm, yes, that is a fix then. I struggle to imagine it being
> exploitable (i.e. control over both threads, one at least already with
> a different cred, etc), but it certainly does look like a bug.

Yes, yes, sure, this is only theoretical.

OK, I am sending the patches to lkml. I didn't dare to keep your ack,
please review v2 (v1 confused bit-mask with bit-number, and in theory
we need ACCESS_ONCE).

It would be really nice if someone can ack the "it is safe to mix
bitops and cmpxchg" assumption mentioned in the changelog.


Alex, Josh, this also partly reverts 179899fd5dc780fe "coredump:
update coredump-related headers", I think fs/coredump.h buys nothing.

Oleg.

fs/coredump.c | 1 -
fs/coredump.h | 6 -----
fs/exec.c | 61 +++++--------------------------------------------
include/linux/sched.h | 25 ++++++++++++++-----
4 files changed, 24 insertions(+), 69 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 3 of 4 ==
Date: Sat, Nov 16 2013 11:10 am
From: Oleg Nesterov


Nobody actually needs MMF_DUMPABLE/MMF_DUMP_SECURELY, there
are only used to enforce the encoding of SUID_DUMP_* enum in
mm->flags & MMF_DUMPABLE_MASK.

Now that set_dumpable() updates both bits atomically we can
kill them and simply store the value "as is" in 2 lower bits.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
fs/exec.c | 18 +++---------------
include/linux/sched.h | 4 +---
2 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 613c9dc..5303005 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1620,8 +1620,7 @@ void set_binfmt(struct linux_binfmt *new)
EXPORT_SYMBOL(set_binfmt);

/*
- * set_dumpable converts traditional three-value dumpable to two flags and
- * stores them into mm->flags.
+ * set_dumpable stores three-value SUID_DUMP_* into mm->flags.
*/
void set_dumpable(struct mm_struct *mm, int value)
{
@@ -1629,24 +1628,13 @@ void set_dumpable(struct mm_struct *mm, int value)

do {
old = ACCESS_ONCE(mm->flags);
- new = old & ~MMF_DUMPABLE_MASK;
-
- switch (value) {
- case SUID_DUMP_ROOT:
- new |= (1 << MMF_DUMP_SECURELY);
- case SUID_DUMP_USER:
- new |= (1<< MMF_DUMPABLE);
- }
-
+ new = (old & ~MMF_DUMPABLE_MASK) | value;
} while (cmpxchg(&mm->flags, old, new) != old);
}

int __get_dumpable(unsigned long mm_flags)
{
- int ret;
-
- ret = mm_flags & MMF_DUMPABLE_MASK;
- return (ret > SUID_DUMP_USER) ? SUID_DUMP_ROOT : ret;
+ return mm_flags & MMF_DUMPABLE_MASK;
}

/*
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 838a3d9..828c00d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -326,10 +326,8 @@ extern int get_dumpable(struct mm_struct *mm);
#define SUID_DUMP_ROOT 2 /* Dump as root */

/* mm flags */
-/* dumpable bits */
-#define MMF_DUMPABLE 0 /* core dump is permitted */
-#define MMF_DUMP_SECURELY 1 /* core file is readable only by root */

+/* for SUID_DUMP_* above */
#define MMF_DUMPABLE_BITS 2
#define MMF_DUMPABLE_MASK ((1 << MMF_DUMPABLE_BITS) - 1)

--
1.5.5.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 4 of 4 ==
Date: Sat, Nov 16 2013 11:10 am
From: Oleg Nesterov


1. Remove fs/coredump.h. It is not clear why do we need it,
it only declares __get_dumpable(), signal.c includes it
for no reason.

2. Now that get_dumpable() and __get_dumpable() are really
trivial make them inline in linux/sched.h.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
fs/coredump.c | 1 -
fs/coredump.h | 6 ------
fs/exec.c | 18 ------------------
include/linux/sched.h | 21 +++++++++++++++++----
4 files changed, 17 insertions(+), 29 deletions(-)
delete mode 100644 fs/coredump.h

diff --git a/fs/coredump.c b/fs/coredump.c
index 9bdeca1..4bc92c7 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -40,7 +40,6 @@

#include <trace/events/task.h>
#include "internal.h"
-#include "coredump.h"

#include <trace/events/sched.h>

diff --git a/fs/coredump.h b/fs/coredump.h
deleted file mode 100644
index e39ff07..0000000
--- a/fs/coredump.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _FS_COREDUMP_H
-#define _FS_COREDUMP_H
-
-extern int __get_dumpable(unsigned long mm_flags);
-
-