[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140307155415.GB16640@madcap2.tricolour.ca>
Date: Fri, 7 Mar 2014 10:54:15 -0500
From: Richard Guy Briggs <rgb@...hat.com>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc: peterz@...radead.org, paulmck@...ux.vnet.ibm.com,
laijs@...fujitsu.com, akpm@...ux-foundation.org, joe@...ches.com,
keescook@...omium.org, geert@...ux-m68k.org, jkosina@...e.cz,
viro@...iv.linux.org.uk, davem@...emloft.net,
linux-kernel@...r.kernel.org, mingo@...e.hu, rostedt@...dmis.org,
tglx@...utronix.de, linux-security-module@...r.kernel.org
Subject: Re: [PATCH] Change task_struct->comm to use RCU.
On 14/03/07, Tetsuo Handa wrote:
> Peter Zijlstra wrote:
> > https://lkml.org/lkml/2011/5/17/516
> Thank you for pointing that thread out. I found the following comment in that
> thread.
>
> Linus Torvalds wrote:
> | What folks?
> |
> | I don't think a new lock (or any lock) is at all appropriate.
> |
> | There's just no point. Just guarantee that the last byte is always
> | zero, and you're done.
> |
> | If you just guarantee that, THERE IS NO RACE. The last byte never
> | changes. You may get odd half-way strings, but you've trivially
> | guaranteed that they are C NUL-terminated, with no locking, no memory
> | ordering, no nothing.
> > > Likewise, audit_log_untrustedstring(ab, current->comm) is racy.
> > > If task->comm was "Hello Linux" until audit_string_contains_control() in
> > > audit_log_n_untrustedstring() returns false, and becomes "Penguin" before
> > > memcpy() in audit_log_n_string() is called, memcpy() will emit "Penguin\0nux"
> > > into the audit log, which results in loss of information (e.g. SELinux
> > > context) due to the unexpected '\0' byte.
> >
> > I expect the audit people don't like this? Also, how do audit and the
> > LSM crap things interact? I thought they were both different piles of
> > ignorable goo?
>
> I think the audit people do not like loss of information. Some of LSM modules
> are using audit subsystem for recording security related events. An example is
> shown later.
This is true, however since comm it untrusted because it can be modified
by the user audit doesn't trust it anyways, so who cares?
> > How about you do what you're supposed to do when you want a reliable
> > ->comm and use get_task_comm()?
>
> I always want a reliable ->comm . But get_task_comm() is not for calling from
> vsnprintf(), for somebody might read task's commname from NMI context.
> I tried to use RCU for reading from vsnprintf() but Linus will not accept it.
- RGB
--
Richard Guy Briggs <rbriggs@...hat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists