Re: User-mode Linux (Was: modify syscall nr on-the-fly)
- From: "Yuriy Tsibizov" <yuriy.tsibizov@xxxxxxxxx>
- Date: Wed, 22 Aug 2007 13:42:13 +0400
2007/8/21, Yuriy Tsibizov <yuriy.tsibizov@xxxxxxxxx>:[...]
2007/8/20, Kostik Belousov <kostikbel@xxxxxxxxx>:Updated registers are available via *frame.
On Sat, Aug 18, 2007 at 02:01:26PM +0400, Yuriy Tsibizov wrote:
I'm trying to get user-mode Linux to run under FreeBSD Linux emulation (on
i386).
User-mode Linux in it's start-up tests tries to modify syscall number (to be
called by kernel) on-the-fly
(http://fxr.watson.org/fxr/source/arch/um/os-Linux/start_up.c?v=linux-2.6).
It forks a child thread that stops
(using SIGSTOP), calls getpid() (that will be intercepted by parent thread
using PTRACE_SYSCALL)
and return some value based on getpid() results. Main thread waits for
SIGSTOP in child process and
enables PTRACE_SYSCALL (I have some code that implements it. It makes some
incompatible changes
to PT_SYSCALL that will break FreeBSD applications, but works for Linux
apps). When main thread
catches SIGTRAP (generated by ptrace) it tries to modify EAX of child thread
(with PTRACE_PEEKUSR
and PTRACE_POKEUSR) to replace getpid syscall with getppid.
is it possible to get updated EAX (and other registers as well) in
syscall(...) after ptracestop(...) in PTRACESTOP_SC(...) returns?
Hope for your help,
Yuriy.
If I understand right what you want, I doubt that existing code would
allow you to change syscall number in debugger process for debuggee.
You shall look at the sys/i386/i386/trap.c, syscall() function [adjust
as needed for other arches]. It calculates callp before doing PTRACESTOP_SC,
as well as copies the syscall arguments into the kernel address space.
Yes, I know this. I'm going to recalculate callp after PTRACESTOP_SC.
And, there will be no need to copyin from user space -- all syscalls
parameters are passed in registers (it will be used only for processes
running under Linux emulation).
With some hacks (some return codes needed by user-mode Linux are
hardcoded into kernel) it loads:
I'll need two more flags in p_stops to add two optios:
- respect PTRACE_(OLD)SETOPTIONS PTRACE_O_TRACESYSGOOD (generate
SIGTRAP | 0x80 instead of plain SIGTRAP)
- use Linux PTRACE_SYSCALL conventions (clear S_PT_SCE and S_PT_SCX in
PTRACESTOP_SC)
to make it more than just a set of hacks to run single program.
PTRACE_(PEEK|POKE)USR seems to need small rewrite too.
patch (against -CURRENT) is available on
http://chibis.persons.gfk.ru/linux/ptrace.diff
You will need to rebuild both kernel an linux module.
Yuriy.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: User-mode Linux (Was: modify syscall nr on-the-fly)
- From: Roman Divacky
- Re: User-mode Linux (Was: modify syscall nr on-the-fly)
- References:
- User-mode Linux (Was: modify syscall nr on-the-fly)
- From: Yuriy Tsibizov
- User-mode Linux (Was: modify syscall nr on-the-fly)
- Prev by Date: Re: linuxolator problem on amd64
- Next by Date: Re: linuxolator problem on amd64
- Previous by thread: User-mode Linux (Was: modify syscall nr on-the-fly)
- Next by thread: Re: User-mode Linux (Was: modify syscall nr on-the-fly)
- Index(es):
Relevant Pages
|
|