Personality
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:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com
Quoted 8 lines · Carsten Langgaard
The
include/linux/personality.hfile 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.
Quoted 5 lines
So I guess we need a "#ifdef
__KERNEL__" around some of the code ininclude/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.
Signature · 2 lines
Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Quoted 9 lines · Daniel Jacobowitz
Quoted 8 lines · Carsten Langgaard
The
include/linux/personality.hfile 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.
Quoted 9 lines
Quoted 5 lines
So I guess we need a "#ifdef
__KERNEL__" around some of the code ininclude/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.
Quoted 4 lines
The right thing to do here is to provide the necessary bits in a glibc header, probably in
bits/personality.hor so.
Agree, that is probably the right way to do it.
Quoted 4 lines
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com
Quoted 11 lines · Carsten Langgaard
The
include/linux/personality.hfile 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 ininclude/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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: PATCH: Add sys/personality (Re: Personality)
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
Quoted 27 lines · H. J. Lu
Quoted 10 lines · Ralf Baechle
Quoted 8 lines · Carsten Langgaard
The
include/linux/personality.hfile 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.Quoted 7 lines
Quoted 3 lines
So I guess we need a "#ifdef
__KERNEL__" around some of the code ininclude/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)
Quoted 7 lines · 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 thepersonality.hfile.
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?
H.J.
---
exec_domain.c renamed from exec_domain.c.per +2 -1
@@ -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 ; }
Re: PATCH: Add sys/personality (Re: Personality)
Quoted 11 lines · H. J. Lu
Quoted 7 lines · 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 thepersonality.hfile.
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.
Quoted 6 lines
H.J.
---
exec_domain.c Tue Jul 16 19:06:13 2002 sys_personality(u_long personality) · line 230
Quoted 9 lines
exec_domain.c Tue Jul 16 19:06:13 2002 renamed from exec_domain.c.per Mon Jun 10 10:05:27 2002 +2
-1@@ -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:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com