From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: laijs@cn.fujitsu.com
Cc: akpm@linux-foundation.org, joe@perches.com,
keescook@chromium.org, geert@linux-m68k.org, jkosina@suse.cz,
viro@zeniv.linux.org.uk, davem@davemloft.net,
linux-kernel@vger.kernel.org, mingo@elte.hu,
peterz@infradead.org, rostedt@goodmis.org, tglx@linutronix.de
Subject: Re: [PATCH] Change task_struct->comm to use RCU.
Date: Tue, 25 Feb 2014 21:54:01 +0900 [thread overview]
Message-ID: <201402252154.HAE13049.QFFSMVOFOOtLJH@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <530BF6B4.3040206@cn.fujitsu.com>
Lai Jiangshan wrote:
> CC scheduler people.
>
> I can't figure out what we get with this patch.
>
OK. Welcome to this thread. I'll explain you what is going on.
Current problem:
printk("%s\n", task->comm) is racy because "%s" format specifier assumes that
the corresponding argument does not change between strnlen() and the for loop
at string() in lib/vsnprintf.c . If task->comm was "Hello Linux" until
strnlen() and becomes "Penguin" before the for loop, "%s" will emit
"Penguin\0nux" (note the unexpected '\0' byte and the garbage bytes).
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.
Proposed solution:
To fix abovementioned problem, I proposed commcpy() and "%pT" format
specifier which does
char tmp[16];
memcpy(tmp, task->comm, 16);
tmp[15] = '\0';
sprintf(buf, "%s", tmp);
instead of
sprintf(buf, "%s", task->comm);
.
Remaining problem:
Although the proposed solution will prevent the caller from emitting the
unexpected '\0' byte and the garbage bytes, memcpy(tmp, task->comm, 16) in
the proposed solution is not atomic. That is, "%pT" does not emit the '\0'
byte like "Penguin\0nux" but "%pT" still might emit "Penguininux".
To fix this problem, I proposed protecting memcpy(tmp, task->comm, 16) part
using RCU. This patch is a design for how the update side of task->comm will
look like if we use RCU approach.
Of course, this approach depends on that nobody prefers the speed of reading
task->comm over the atomicity of reading task->comm . If somebody strongly
objects on the cost of calling rcu_read_lock()/rcu_read_unlock() for the
atomicity, I'm fine without this patch.
next prev parent reply other threads:[~2014-02-25 12:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201402072303.DJD13007.JFFMSLHOOFQOtV@I-love.SAKURA.ne.jp>
[not found] ` <20140207140536.943daf965008b9428cdcb468@linux-foundation.org>
[not found] ` <201402081055.BGJ73403.tQMLFVOJSOOFFH@I-love.SAKURA.ne.jp>
[not found] ` <20140207180647.5944fe3d.akpm@linux-foundation.org>
[not found] ` <201402092327.JAD12489.QOLSFVMHJtFOOF@I-love.SAKURA.ne.jp>
2014-02-10 13:43 ` [PATCH (draft)] Change task_struct->comm to use RCU Tetsuo Handa
2014-02-17 11:27 ` [PATCH] " Tetsuo Handa
2014-02-24 23:51 ` Paul E. McKenney
2014-02-26 13:44 ` Tetsuo Handa
2014-02-26 15:26 ` Paul E. McKenney
2014-02-25 1:49 ` Lai Jiangshan
2014-02-25 10:05 ` Peter Zijlstra
2014-02-25 12:54 ` Tetsuo Handa [this message]
2014-02-25 14:46 ` Peter Zijlstra
2014-03-07 12:20 ` Tetsuo Handa
2014-03-07 15:54 ` Richard Guy Briggs
2014-03-08 12:43 ` Tetsuo Handa
2014-03-10 20:21 ` Richard Guy Briggs
2014-03-11 12:02 ` Tetsuo Handa
2014-03-11 12:16 ` Tetsuo Handa
2014-03-11 13:55 ` James Morris
2014-03-24 15:43 ` Richard Guy Briggs
2014-03-27 17:20 ` [PATCH] LSM: Pass comm name via get_task_comm() [was: Re: [PATCH] Change task_struct->comm to use RCU.] Richard Guy Briggs
2014-03-27 18:06 ` Stephen Smalley
2014-09-19 3:30 ` Richard Guy Briggs
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=201402252154.HAE13049.QFFSMVOFOOtLJH@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=geert@linux-m68k.org \
--cc=jkosina@suse.cz \
--cc=joe@perches.com \
--cc=keescook@chromium.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
/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.