This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Add x32 arch_prctl support


On Mon, May 21, 2012 at 6:37 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> I need more context...

When I added x32 ptrace to 3.4 kernel, I also include PTRACE_ARCH_PRCTL
support for x32 GDB  For ARCH_GET_FS/GS, it takes a pointer to int64.  But
at user level, ARCH_GET_FS/GS takes a pointer to int32.  So I have to add
x32 ptrace to glibc to handle it with a temporary int64 passed to kernel and
copy it back to GDB as int32.  Roland suggested that PTRACE_ARCH_PRCTL
is obsolete and x32 GDB should use fs_base and gs_base fields of
user_regs_struct
instead.  In this case, I won't add special handling for PTRACE_ARCH_PRCTL in
glibc and x32 ptrace in kernel should return EINVAL for PTRACE_ARCH_PRCTL
to avoid possible memory overrun when pointer to int32 is passed to kernel.

The question is how fast we can to get this patch

diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 685845c..cf11783 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1211,12 +1211,6 @@ static long x32_arch_ptrace(struct task_struct *child,
 					     0, sizeof(struct user_i387_struct),
 					     datap);

-		/* normal 64bit interface to access TLS data.
-		   Works just like arch_prctl, except that the arguments
-		   are reversed. */
-	case PTRACE_ARCH_PRCTL:
-		return do_arch_prctl(child, data, addr);
-
 	default:
 		return compat_ptrace_request(child, request, addr, data);
 	}

into Linux kernel.

> "H.J. Lu" <hjl.tools@gmail.com> wrote:
>
>>On Mon, May 21, 2012 at 4:53 PM, Roland McGrath <roland@hack.frob.com>
>>wrote:
>>>> The goes back to user uint32_t vs kernel uint64_t:
>>>>
>>>> http://sourceware.org/ml/libc-alpha/2012-05/msg01519.html
>>>>
>>>> The difference is movq vs movl. ?There is no need for movq
>>>> since x32 will only pass unsigned 32-bit value to kernel.
>>>
>>> I see. ?That one byte in a rarely-used call is not reason enough to
>>> make the code uglier.
>>
>>Also since all inlined arguments will be casted to "long int",
>>using unsigned long long int or uint64_t is quite strange.
>>
>>>> Thanks. ?But since x32 kernel takes PTRACE_ARCH_PRCTL, I
>>>> still need x32 ptrace to either handle it properly or set EINVAL
>>>> when PTRACE_ARCH_PRCTL is passed.
>>>
>>> It was my proposal that the kernel be changed to refuse
>>PTRACE_ARCH_PRCTL
>>> in a ptrace call made from an x32 task.
>>>
>>
>>Adding Peter. ?The x32 PTRACE_ARCH_PRCTL change is in kernel 3.4.
>>Peter, how hard to remove it from kernel?
>>
>>--
>>H.J.
>



-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]