Personality

Personality

[Carsten Langgaard]

The include/linux/personality.h file has changed between the 2.4.3 and
the 2.4.18 kernel.
Now there is a define of personality (#define personality(pers) (pers &
PER_MASK), but that breaks things for the users, if they include this
file.
The user wishes to call the glibc personality function (which do the
syscall), and not use the above definition.

So I guess we need a "#ifdef __KERNEL__" around some of the code in
include/linux/personality.h (at least around the define of personality),
which then has to go into the glibc kernel header files.

Any comments ?

/Carsten


--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: Personality

[Ralf Baechle]

On Tue, Jul 16, 2002 at 10:34:58AM +0200, Carsten Langgaard wrote:

> The include/linux/personality.h file has changed between the 2.4.3 and
> the 2.4.18 kernel.
> Now there is a define of personality (#define personality(pers) (pers &
> PER_MASK), but that breaks things for the users, if they include this
> file.
> The user wishes to call the glibc personality function (which do the
> syscall), and not use the above definition.
> 
> So I guess we need a "#ifdef __KERNEL__" around some of the code in
> include/linux/personality.h (at least around the define of personality),
> which then has to go into the glibc kernel header files.

The general policy about such problems is to not use kernel include files
from user applications directly.  Hjl - maybe time for <sys/personality.h>?

  Ralf

Re: PATCH: Add sys/personality (Re: Personality)

[Carsten Langgaard]

Thanks.
Now that we are at it, what should personality return in case it's called with a
value, which isn't defined in the personality.h file.
Should it return -EINVAL ?
I don't think, that is the case at the moment, I believe you can set personality
to anything.

/Carsten


"H. J. Lu" wrote:

> On Tue, Jul 16, 2002 at 12:36:32PM +0200, Ralf Baechle wrote:
> > On Tue, Jul 16, 2002 at 10:34:58AM +0200, Carsten Langgaard wrote:
> >
> > > The include/linux/personality.h file has changed between the 2.4.3 and
> > > the 2.4.18 kernel.
> > > Now there is a define of personality (#define personality(pers) (pers &
> > > PER_MASK), but that breaks things for the users, if they include this
> > > file.
> > > The user wishes to call the glibc personality function (which do the
> > > syscall), and not use the above definition.
> > >
> > > So I guess we need a "#ifdef __KERNEL__" around some of the code in
> > > include/linux/personality.h (at least around the define of personality),
> > > which then has to go into the glibc kernel header files.
> >
> > The general policy about such problems is to not use kernel include files
> > from user applications directly.  Hjl - maybe time for <sys/personality.h>?
> >
>
> Here is a patch.
>
> H.J.
>
>   ------------------------------------------------------------------------
>
>    glibc-personality.patchName: glibc-personality.patch
>                           Type: Plain Text (text/plain)

Re: PATCH: Add sys/personality (Re: Personality)

[Carsten Langgaard]

"H. J. Lu" wrote:

> On Tue, Jul 16, 2002 at 09:16:48PM +0200, Carsten Langgaard wrote:
> > Thanks.
> > Now that we are at it, what should personality return in case it's called with a
> > value, which isn't defined in the personality.h file.
> > Should it return -EINVAL ?
> > I don't think, that is the case at the moment, I believe you can set personality
> > to anything.
> >
>
> Like this?
>

No, I don't think the patch is correct.
I don't know how this actually should work, maybe someone who do know can help out
here.
But it look like the idea is, that we have a default execution domain (linux), which
have pers_low = 0 (PER_LINUX) and pers_high = 0.
If one want other execution domains, one much call the register_exec_domain to
register the execution domain and personality.
So if personality is call with a value that isn't register, it then accept the
personality and sets the execution domain to the default settings (which is linux).
So the question is should personality, return -EINVAL, if it got a personality value
which hasn't been registered or should it accept the personality, but set the
execution domain to the default setting ?
If the later is true, should it also accept values outside the values defined in the
personality.h file ?

So what should the following user calls return, if not registered in the kernel?

personality(PER_BSD):
personality(0x47):

Could someone with a better understand than I, please comment this.

>
> H.J.
> ---
> --- kernel/exec_domain.c.per    Mon Jun 10 10:05:27 2002
> +++ kernel/exec_domain.c        Tue Jul 16 19:06:13 2002
> @@ -223,7 +223,8 @@ sys_personality(u_long personality)
>
>         if (personality != 0xffffffff) {
>                 set_personality(personality);
> -               if (current->personality != personality)
> +               if (personality < current->exec_domain->pers_low
> +                   || personality > current->exec_domain->pers_high)
>                         return -EINVAL;
>         }
>

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: Personality

[Daniel Jacobowitz]

On Tue, Jul 16, 2002 at 10:34:58AM +0200, Carsten Langgaard wrote:
> The include/linux/personality.h file has changed between the 2.4.3 and
> the 2.4.18 kernel.
> Now there is a define of personality (#define personality(pers) (pers &
> PER_MASK), but that breaks things for the users, if they include this
> file.
> The user wishes to call the glibc personality function (which do the
> syscall), and not use the above definition.
> 
> So I guess we need a "#ifdef __KERNEL__" around some of the code in
> include/linux/personality.h (at least around the define of personality),
> which then has to go into the glibc kernel header files.
> 
> Any comments ?

Why is the user program including <linux/personality.h> in the first
place?

The right thing to do here is to provide the necessary bits in a glibc
header, probably in bits/personality.h or so.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Personality

[Carsten Langgaard]

Daniel Jacobowitz wrote:

> On Tue, Jul 16, 2002 at 10:34:58AM +0200, Carsten Langgaard wrote:
> > The include/linux/personality.h file has changed between the 2.4.3 and
> > the 2.4.18 kernel.
> > Now there is a define of personality (#define personality(pers) (pers &
> > PER_MASK), but that breaks things for the users, if they include this
> > file.
> > The user wishes to call the glibc personality function (which do the
> > syscall), and not use the above definition.
> >
> > So I guess we need a "#ifdef __KERNEL__" around some of the code in
> > include/linux/personality.h (at least around the define of personality),
> > which then has to go into the glibc kernel header files.
> >
> > Any comments ?
>
> Why is the user program including <linux/personality.h> in the first
> place?
>

It need some personality type defines.

>
> The right thing to do here is to provide the necessary bits in a glibc
> header, probably in bits/personality.h or so.
>

Agree, that is probably the right way to do it.

>
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com