From: Oleg Nesterov <oleg@redhat.com>
To: Andi Kleen <andi@firstfloor.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Richard Henderson <rth@twiddle.net>,
Roland McGrath <roland@redhat.com>
Cc: wezhang@redhat.com, linux-kernel@vger.kernel.org
Subject: Q: sys_personality() && misc oddities
Date: Tue, 25 May 2010 16:17:20 +0200 [thread overview]
Message-ID: <20100525141720.GA2253@redhat.com> (raw)
Hello.
This code is really old, and I do not know whom should I ask. And,
despite the fact it is really trivial, I have no idea how to fix it.
And even more, I am not sure it actually needs fixes. I'd better ask
the questions. Please help ;)
First of all, task_struct->personality is "int", but sys_personality()
takes "long". This means that every comparison or assignment inside of
sys_personality() paths is not right.
Probably we need something like this trivial patch
--- x/kernel/exec_domain.c
+++ x/kernel/exec_domain.c
@@ -192,7 +192,9 @@ SYSCALL_DEFINE1(personality, u_long, per
{
u_long old = current->personality;
- if (personality != 0xffffffff) {
+ if (personality > 0xffffffff)
+ return -EINVAL;
+ else if (personality != 0xffffffff) {
set_personality(personality);
if (current->personality != personality)
return -EINVAL;
?
Or, perhaps we shouldn't allow personality >= int32_max = 0x7ffffff ?
Otherwise, on 32bit machine the value returned to the user-space can
look like -ESOMETHING.
Even on x86_64, in user-space it is declared as
int personality(unsigned long persona);
if the kernel returns the "large" old it looks negative to the user-space,
and the test-case thinks that the syscall failed but errno is not set.
This is the actual reason for the question. I am really surprized I
do not know how to close the redhat-internal bugzilla entry, the
problem is very trivial.
------------------------------------------------------------------------------
But there are other oddities I can't understand. Let's forget about
the sizeof(task_struct->personality), let's suppose it is "long" too.
And note that is was long before 97dc32cdb1b53832801159d5f634b41aad9d0a23
which did s/long/int/ to reduce the sizeof task_struct.
__set_personality(). What is the point to check
ep == current_thread_info()->exec_domain ? This buys nothing afaics.
IOW, it could be simplified:
int __set_personality(u_long personality)
{
struct exec_domain *oep = current_thread_info()->exec_domain;
current_thread_info()->exec_domain = lookup_exec_domain(personality);
current->personality = personality;
module_put(oep->module);
return 0;
}
Now let's look at the caller, sys_personality()
set_personality(personality);
if (current->personality != personality)
return -EINVAL;
but __set_personality() always sets current->personality = personality,
what is the point to check equality?
IOW, when we should return -EINVAL? Perhaps, lookup_exec_domain() should
return NULL instead of default_exec_domain when the search in exec_domains
fails? And probably we shouldn't change task->personality/exec_domain in
this case? It is really strange that sys_personality() can return -EINVAL
but change ->personality.
But this can probably break exec. alpha does set_personality(PER_OSF4)
but I do not see the corresponding register_exec_domain(). On the other
hand, I do not understand why it puts PER_OSF4 into PER_MASK. PER_OSF4
is only used by sys_osf_readv/sys_osf_writev.
Thanks,
Oleg.
next reply other threads:[~2010-05-25 14:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-25 14:17 Oleg Nesterov [this message]
2010-05-25 19:33 ` Q: sys_personality() && misc oddities Roland McGrath
2010-05-26 12:36 ` Oleg Nesterov
2010-05-26 20:31 ` Roland McGrath
2010-05-26 20:35 ` H. Peter Anvin
2010-05-27 15:35 ` [PATCH 0/3] (Was: Q: sys_personality() && misc oddities) Oleg Nesterov
2010-05-27 15:35 ` [PATCH 1/3] sys_personality: validate personality before set_personality() Oleg Nesterov
2010-05-27 16:39 ` Linus Torvalds
2010-05-27 17:15 ` Oleg Nesterov
2010-05-27 17:51 ` Linus Torvalds
2010-05-27 18:13 ` Oleg Nesterov
2010-05-27 18:18 ` Andi Kleen
2010-05-28 19:11 ` [PATCH 0/2] sys_personality fixes v2 Oleg Nesterov
2010-05-28 19:12 ` [PATCH 1/2] change sys_personality() to accept "unsigned int" instead of u_long Oleg Nesterov
2010-05-28 19:12 ` [PATCH 2/2] remove the bogus checks in sys_personality()->__set_personality() path Oleg Nesterov
2010-05-28 19:28 ` [PATCH 0/2] sys_personality fixes v2 Linus Torvalds
2010-05-28 19:58 ` H. Peter Anvin
2010-05-28 19:59 ` Oleg Nesterov
2010-05-27 15:36 ` [PATCH 2/3] sys_personality: make sure (int)personality >= 0 Oleg Nesterov
2010-05-27 20:02 ` H. Peter Anvin
2010-05-28 19:03 ` Oleg Nesterov
2010-05-27 15:36 ` [PATCH 3/3] __set_personality: no need to check the old ->exec_domain Oleg Nesterov
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=20100525141720.GA2253@redhat.com \
--to=oleg@redhat.com \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=rth@twiddle.net \
--cc=torvalds@linux-foundation.org \
--cc=wezhang@redhat.com \
/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.