[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-code
Subject:    Re: [osol-code] Tracing 32bit sys call in kernel module
From:       James Carlson <carlsonj () workingcode ! com>
Date:       2011-10-11 11:41:05
Message-ID: 4E942B51.5090903 () workingcode ! com
[Download RAW message or body]

Neo wrote:
> > That overwrites (and loses) the pointer assigned to "old_call_c" from
> > the sysent[] array. Are you sure you don't want to define an
> > "old_call_32_c" variable?
> 
> The "old_call_c" doesn't get overwritten. There are no issues with the given type \
> of implementation.

Writing two things into the same variable sounds like an overwrite, but,
hey, what do I know?

> My main problem is, 
> I have mapped "SYS_mkdir" system call to my customized "new_mkdir" method.
> My machine as well as OS are 64bit. So,
> 1) If I run a 64 bit application which calls mkdir syscall, it will successfully \
> get trapped to my new_mkdir method as my machine+OS is 64 bit. 2) But if I run an \
> 32bit application which does mkdir, it doesn't get trapped in my new_mkdir method. 
> So, tracing 32bit sys calls on 64 bit platform is the basic issue.

If tracing really is the basic issue, then stop here: Open Solaris comes
with several flexible and usable tracing tools -- dtrace, truss, and
kmdb (mdb -K).  Use them.  They're your friends.  Hacking at the syscall
table is not your friend.  (And, really, is best done from within the
kernel sources.)

If overriding the mkdir behavior of a known set of applications is your
goal, then consider using an LD_PRELOAD to interpose on the higher-level
library call.  It'll be far less problematic.

Otherwise, it doesn't sound like you've adequately described what your
"basic issue" really is.

> > You might also want to look more closely at the way 'struct sysent' is
> > constructed in usr/src/uts/common/os/sysent.c
> 
> I saw the struct sysent and struct sysent32 from sysent.c file.
> According to that, I guess the implementation of both the structs are proper in the \
> code snippet at beginning of this thread.  
> When I see code in systrace.c, I can see the implementation of macro "#ifdef \
> _SYSCALL32_IMPL". I think that somewhere this macro will help me doing so.
> 
> Can you please provide  some more pointer on the same front?

The only difference I can see between them (using dtrace to examine the
kernel's behavior) is that one goes through unix`syscall_trap and the
other through unix`syscall_trap32 on SPARC, and on x86/x64 one goes
through unix`sys_syscall and the other through
unix`_sys_sysenter_post_swapgs.

If that's not what you see, and if you're not willing to take the advice
to stay away from hacking the syscall table from within an independent
kernel module, then I guess you're on your own.  Good luck ...

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code


[prev in list] [next in list] [prev in thread] [next in thread]