This chunk from linux-2.6-utrace.patch breaks PTRACE_SYSEMU, which UML
rather relies on.
@@ -514,9 +514,6 @@ syscall_trace_entry:
movl %esp, %eax
xorl %edx,%edx
call do_syscall_trace
- cmpl $0, %eax
- jne resume_userspace # ret != 0 -> running under PTRACE_SYSEMU,
- # so must skip actual syscall
movl PT_ORIG_EAX(%esp), %eax
cmpl $(nr_syscalls), %eax
jnae syscall_call
If the point of this patch was to completely remove ptrace support,
with later patches adding it back, then that chunk should be added
back in utrace-ptrace-compat.patch.
Jeff
--
Work email - jdike at linux dot intel dot com
> This chunk from linux-2.6-utrace.patch breaks PTRACE_SYSEMU, which UML
> rather relies on.
PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP are implemented in a different
way (see kernel/ptrace.c), which does not require that assembly code.
(It also works for free on other arch's if you want to #define the
constants there.)
Do you have a test case for PTRACE_SYSEMU that does not work right?
Thanks,
Roland
On Tue, May 22, 2007 at 11:46:11PM -0700, Roland McGrath wrote:
> Do you have a test case for PTRACE_SYSEMU that does not work right?
UML, obviously. Below is a smaller test. orig_eax is wrong, so you
can't read the system call number from the process.
With kernel-2.6.20-1.2948, it prints out a bunch of -1's. On FC5
kernels, you get more reasonable numbers.
Jeff
--
Work email - jdike at linux dot intel dot com
#include <stdlib.h>
#include <stdio.h>
#include <asm/unistd.h>
#include <sys/mman.h>
#include <sys/ptrace.h>
#include <asm/ptrace.h>
#include <sys/wait.h>
#define PTRACE_SYSEMU 31
#define PAGE_SIZE 4096
static inline long stub_syscall0(long syscall)
{
long ret;
__asm__ volatile ("int $0x80" : "=a" (ret) : "0" (syscall));
return ret;
}
static void child(void)
{
if(ptrace(PTRACE_TRACEME, 0, 0, 0) < 0){
perror("traceme");
exit(1);
}
kill(getpid(), SIGUSR1);
stub_syscall0(__NR_getpid);
}
int main(void)
{
void *stack;
unsigned long sp, regs[FRAME_SIZE];
int pid, n, status;
stack = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if(stack == MAP_FAILED){
perror("mmap");
exit(1);
}
sp = (unsigned long) stack + PAGE_SIZE - sizeof(void *);
pid = fork();
if(pid < 0)
perror("fork");
else if(pid == 0){
child();
}
else {
while(1){
n = waitpid(pid, &status, WUNTRACED);
if(n < 0){
perror("waitpid");
exit(1);
}
n = ptrace(PTRACE_GETREGS, pid, 0, regs);
if(n < 0){
perror("PTRACE_GETREGS");
exit(1);
}
printf("Status 0x%x orig_eax 0x%x\n", status,
regs[ORIG_EAX]);
if(ptrace(PTRACE_SYSEMU, pid, 0, 0)){
perror("PTRACE_SYSEMU");
exit(1);
}
}
}
return 0;
}
On Tue, May 22, 2007 at 11:46:11PM -0700, Roland McGrath wrote:
> (It also works for free on other arch's if you want to #define the
> constants there.)
(Forgot to mention...) sweet
Jeff
--
Work email - jdike at linux dot intel dot com
> UML, obviously. Below is a smaller test. orig_eax is wrong, so you
> can't read the system call number from the process.
Oops! I overlooked the need to preserve the orig_eax value, though its
necessity is obvious. This makes me wonder about those previous
reports that UML was working OK.
I refined the test case a little and that's in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241408
I've fixed this in the latest utrace patch set. I also wired up
sysemu on x86_64. This means 32-bit processes calling ptrace now
support it for full compatibility with native i386, which the vanilla
kernel does not. It also means it works for 64-bit ptrace calls,
whether operating on a 64-bit or a 32-bit target process.
Thanks,
Roland
On Fri, May 25, 2007 at 06:35:13PM -0700, Roland McGrath wrote:
> Oops! I overlooked the need to preserve the orig_eax value, though its
> necessity is obvious. This makes me wonder about those previous
> reports that UML was working OK.
The one from me was on x86_64, where PTRACE_SYSEMU isn't an issue yet.
> I've fixed this in the latest utrace patch set. I also wired up
> sysemu on x86_64. This means 32-bit processes calling ptrace now
> support it for full compatibility with native i386, which the vanilla
> kernel does not. It also means it works for 64-bit ptrace calls,
> whether operating on a 64-bit or a 32-bit target process.
Beautiful!
Jeff
--
Work email - jdike at linux dot intel dot com