[PATCH] futex: avoid kernel taint caused by get_robust_list

[Paul Gortmaker]

commit ec0c4274e33c0373e476b73e01995c53128f1257 ("futex: Mark
get_robust_list as deprecated") added these two WARN_ONCE calls.

However, WARN_ONCE taints the kernel, and we shouldn't be allowing
any user who wanders by to do this. For example, the system fuzzer
"trinity" uses the tainted state as a metric for when to stop,
assuming that it has caused significant wreckage (and indeed
that tool is what actually led me to this change).

The ability to deprecate this code has been called into question[1],
but if that remains to be finalized, then making this change in the
interim seems to make sense.

[1] http://lkml.indiana.edu/hypermail/linux/kernel/1208.0/01081.html

Cc: Dave Jones <da...@redhat.com>
Cc: Richard Weinberger <ric...@nod.at>
Cc: Kees Cook <kees...@chromium.org>
Cc: Thomas Gleixner <tg...@linutronix.de>
Cc: sta...@vger.kernel.org # 3.4+
Signed-off-by: Paul Gortmaker <paul.go...@windriver.com>
---

[Alternatively, someone can simply apply Richard's original revert:
http://permalink.gmane.org/gmane.linux.kernel.hardened.devel/506
Either way, I think the WARN_ONCE needs to go away. ]

kernel/futex.c | 2 +-
kernel/futex_compat.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 19eb089..e1aede2 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2471,7 +2471,7 @@ SYSCALL_DEFINE3(get_robust_list, int, pid,
if (!futex_cmpxchg_enabled)
return -ENOSYS;

- WARN_ONCE(1, "deprecated: get_robust_list will be deleted in 2013.\n");
+ printk_once(KERN_WARNING "deprecated: get_robust_list will be deleted in 2013.\n");

rcu_read_lock();

diff --git a/kernel/futex_compat.c b/kernel/futex_compat.c
index 83e368b..618d2db 100644
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -142,7 +142,7 @@ compat_sys_get_robust_list(int pid, compat_uptr_t __user *head_ptr,
if (!futex_cmpxchg_enabled)
return -ENOSYS;

- WARN_ONCE(1, "deprecated: get_robust_list will be deleted in 2013.\n");
+ printk_once(KERN_WARNING "deprecated: get_robust_list will be deleted in 2013.\n");

rcu_read_lock();

--
1.8.1.2

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

[Kees Cook]

On Fri, Feb 15, 2013 at 7:54 AM, Paul Gortmaker
<paul.go...@windriver.com> wrote:
> commit ec0c4274e33c0373e476b73e01995c53128f1257 ("futex: Mark
> get_robust_list as deprecated") added these two WARN_ONCE calls.
>
> However, WARN_ONCE taints the kernel, and we shouldn't be allowing
> any user who wanders by to do this. For example, the system fuzzer
> "trinity" uses the tainted state as a metric for when to stop,
> assuming that it has caused significant wreckage (and indeed
> that tool is what actually led me to this change).
>
> The ability to deprecate this code has been called into question[1],
> but if that remains to be finalized, then making this change in the
> interim seems to make sense.
>
> [1] http://lkml.indiana.edu/hypermail/linux/kernel/1208.0/01081.html
>
> Cc: Dave Jones <da...@redhat.com>
> Cc: Richard Weinberger <ric...@nod.at>
> Cc: Kees Cook <kees...@chromium.org>
> Cc: Thomas Gleixner <tg...@linutronix.de>
> Cc: sta...@vger.kernel.org # 3.4+
> Signed-off-by: Paul Gortmaker <paul.go...@windriver.com>

I Acked the original revert. I thought there was agreement that it was
needed for checkpointing to work?

-Kees

--
Kees Cook
Chrome OS Security

[Paul Gortmaker]

On 13-02-15 11:18 AM, Kees Cook wrote:
> On Fri, Feb 15, 2013 at 7:54 AM, Paul Gortmaker
> <paul.go...@windriver.com> wrote:
>> commit ec0c4274e33c0373e476b73e01995c53128f1257 ("futex: Mark
>> get_robust_list as deprecated") added these two WARN_ONCE calls.
>>
>> However, WARN_ONCE taints the kernel, and we shouldn't be allowing
>> any user who wanders by to do this. For example, the system fuzzer
>> "trinity" uses the tainted state as a metric for when to stop,
>> assuming that it has caused significant wreckage (and indeed
>> that tool is what actually led me to this change).
>>
>> The ability to deprecate this code has been called into question[1],
>> but if that remains to be finalized, then making this change in the
>> interim seems to make sense.
>>
>> [1] http://lkml.indiana.edu/hypermail/linux/kernel/1208.0/01081.html
>>
>> Cc: Dave Jones <da...@redhat.com>
>> Cc: Richard Weinberger <ric...@nod.at>
>> Cc: Kees Cook <kees...@chromium.org>
>> Cc: Thomas Gleixner <tg...@linutronix.de>
>> Cc: sta...@vger.kernel.org # 3.4+
>> Signed-off-by: Paul Gortmaker <paul.go...@windriver.com>
>
> I Acked the original revert. I thought there was agreement that it was
> needed for checkpointing to work?

There were several acks in the original thread, but for some unknown
reason (at least unknown to me and Richard), it never made it in tree...

P.
--

>
> -Kees

[Kees Cook]

Hi Andrew,

Is this revert something you would be willing to take?

-Kees

On Fri, Feb 15, 2013 at 8:32 AM, Paul Gortmaker

--
Kees Cook
Chrome OS Security

[Richard Weinberger]

Am Fri, 15 Feb 2013 08:41:27 -0800
schrieb Kees Cook <kees...@chromium.org>:

> Hi Andrew,
>
> Is this revert something you would be willing to take?

It looks like the patch[0] never made it into linux-kernel@ for whatever
reasons. :-(

Thanks,
//richard

[1] http://permalink.gmane.org/gmane.linux.kernel.hardened.devel/506