All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Roland McGrath <roland@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Richard Henderson <rth@twiddle.net>,
	wezhang@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: Q: sys_personality() && misc oddities
Date: Wed, 26 May 2010 14:36:22 +0200	[thread overview]
Message-ID: <20100526123622.GA26033@redhat.com> (raw)
In-Reply-To: <20100525193348.83F1549A54@magilla.sf.frob.com>

On 05/25, Roland McGrath wrote:
>
> I don't think we're ever going to need or want a 64-bit personality word.
> (There are still 10 bits unused in the middle for more flags.)

OK,

> Though the high bit might be set on 32-bit, there still should not really
> be a danger of misinterpreting a value as an error code--as long as we
> haven't used up all 10 of those middle bits.  The test userland (glibc)
> uses is not "long < 0" but "u_long > -4095UL".  So as long as at least
> one bit in 0xff00 remains clear, it won't match.

Yes, libc itself is fine. But from the application's pov, personality()
returns int, not long.

> For 64-bit you want to avoid sign-extension of the old value just so it
> looks valid (even though it won't look like an error code).  I think the
> most sensible thing is to change the task_struct field to 'unsigned int'.

it is already 'unsigned int' ;)

> I think the 0xffffffff check is intended specifically for personality(-1)
> to be a no-op that returns the old value, and nothing more.

I think the same.

> OTOH, this:
>
> 		set_personality(personality);
> 		if (current->personality != personality)
> 			return -EINVAL;
>
> will then both do the job in set_personality() and return -EINVAL, when
> some high bits are set.

Yes! and despite the fact it returns -EINVAL, current->personality was
changed. This can't be right.

> So, perhaps you are right about checking high
> bits.  Then I'd make it:
>
> 	if ((int) personality != -1) {
> 		if (unlikely((unsigned int) personality != personality))
> 			return -EINVAL;

Well. Think about personality(0xffffffff - 1). It passes both checks
and we change current->personality. Then the application calls
personality() again, we return the old value, and since the user-space
expects "int" it gets -2.

How about

	if (personality != 0xffffffff) {
		if (personality >= 0x7fffffff)
			return -EINVAL;
		set_personality(personality);
	}

? Now that personality always fits into "insigned int" we don't need
to recheck current->personality == personality, and "< 0x7fffffff"
gurantees that "int old_personality = personality(whatever)" in user
space can be never misinterpeted as error.

As for the other oddities, they need the separate patches. Or we can
just leave this code alone ;)

Oleg.


  reply	other threads:[~2010-05-26 12:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-25 14:17 Q: sys_personality() && misc oddities Oleg Nesterov
2010-05-25 19:33 ` Roland McGrath
2010-05-26 12:36   ` Oleg Nesterov [this message]
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=20100526123622.GA26033@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.