[uml-devel] Re: Bad handling of invalif systemcalls

[Bodo Stroesser <bstroesser@fujitsu-siemens.com>]

Jeff Dike wrote:
> bstroesser@fujitsu-siemens.com said:
> 
>>AFAICS, the only solution for this is using the PTRACE_O_TRACESYSGOOD
>>option. This option seems to be specific for linux, but the problem
>>maybe is specific for linux, too. 
> 
> 
> Another solution is to read the instruction.
It's a bit tricky to do this, if the vsyscall-page is in use. Then you also
have to know the address of the return-point for "sysenter", which the
kernel uses.
Also, the tracer thread at the moment has no access to the code of the process!
I tapped into this trap while trying to simplify the singlestepping even more by
moving the opcode-check from kernel_do_signal() to is_syscall().
So I reverted the change ...

> 
> However TRACESYSGOOD is cleaner.  My only concern is whether that limits the
> hosts that UML will run on.  If TRACESYSGOOD has been around for the 2.4
> series, then that's OK.
2.4 supports it, at least in the newer versions. I looked for it before patching.

> 
> I would be tempted to #define SIGSYSCALL (SIGTRAP + 0x80) or something just
> to make the +0x80 bit less magic-looking.
Yes. I used the 0x80, because I didn't find a definition for this in the
header files from /usr/include. So, if the host linux doesn't use a
     #define THIS_IS_A_SYSCALL_INTERCEPTION 0x80
I decided not to do it also. But feel free to change this.

> 
> 
>>For the third patch I'm quite anxious, that there could go something
>>wrong when using the debugger. I don't understand much about this.
>>Maybe someone else could look into this? 
> 
> 
>  				if(!tracing && (debugger_pid != -1)){
>  					child_signal(pid, status);
>  					continue;
>  				}
>  				tracing = 0;
> 				if(do_syscall(task, pid))
> 					sig = SIGUSR2;
> 
> OK, what this says is
> 	if we are running in the kernel, not userspace (!tracing)
> 	and we are debugging UML (debugger_pid != -1)
> 	then we fake the syscall-traced gdb into thinking the SIGTRAP was sent
> 	to the process
> 
> 	Otherwise we call do_syscall, which will check the syscall number 
> 	and return true if it thinks it's handling a syscall.  In that case,
> 	we hit the process with SUGUSR2 in order to force it into the UML
> 	syscall handler.
> 
> So, if we get SIGTRAP + 0x80, we know we have a syscall, and the debugging
> stuff can just go away.  You can look at this sort of mathematically, and
> say SIGTRAP + 0x80 => tracing, so that if(!tracing...) can just be deleted.
No. The processes in UML-TT, no matter if they run in userspace or execute the
kernel, always are ptraced processes and PTRACE_O_TRACESSYSGOOD now will be
set permanently. So, if the debugger does an syscall-trace, it will expect an
SIGTRAP, but what happens is an (SIGTRAP|0x80). Since I didn't want to change
the debugger, I masked the 0x80.
For breakpoints or singlestep-traps, the signal still will be SIGTRAP only.

Maybe it would make sense, to change the debugger-code. It could accept
(SIGTRAP|0x80) and give it to the real debugger as SIGTRAP normally. Also, it
could accept a ptrace(PTRACE_SETOTIONS,,,PTRACE_O_TRACESYSGOOD) and after this
it could relay the (SIGTRAP|0x80) without change.

> 
> Similarly, do_syscall will always return true, so you don't need to check its
> return, which you have removed.
> 
> In the SIGTRAP case, you might as well inline do_sigtrap.  One line functions
> are pretty much a waste.  In any case, I don't understand why you're doing
> that.  orig_eax should already be -1.
Yes. Inlining is a good idea.
You are right, orig_eax on the processes stack is -1. But this *has* to be saved
in the tt-regs structure for later use. What I'm doing is the same that
     UPT_SYSCALL_NR(TASK_REGS(task)) = PT_SYSCALL_NR(proc_regs);
does in the case of a systemcall. I used "-1" instead of "PT_SYSCALL_NR(proc_regs)"
because it *is* the same in this situation.
> 	
> 				Jeff
> 



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel