Re: [User-mode-linux-devel] Performance enhancement idea / security issue...

[Chris L. <sa...@sk...>]

How would security be reduced by having an alternate system call entry
point?  Isn't the kernel is the one auditing the arguments passed into the
kernel?  If so, using 'ud2' to get into the kernel would be the same as
using a tracing thread... tracing is disabled on entrance, because we
'know' we are in safe code...

-Chris


On Fri, 7 Jul 2000, Jeff Dike wrote:

> sa...@sk... said:
> > 1. Instead of changing EAX to make the syscall do a getpid, why not
> > just add 2 to the EIP to skip over the int 80? 
> 
> Because the EIP += 2 has already happened.  I think the processor bumps the ip 
> to the next instruction before the current one starts executing.  When a 
> process is in a system call, its eip is already bumped to the following 
> instruction.
> 
> To see what's going on here, look at arch/i386/entry.S at the trace_sys label:
> 
> tracesys:
> 	movl $-ENOSYS,EAX(%esp)
> 	call SYMBOL_NAME(syscall_trace) *****
> 	movl ORIG_EAX(%esp),%eax
> 	cmpl $(NR_syscalls),%eax
> 	jae tracesys_exit
> 	call *SYMBOL_NAME(sys_call_table)(,%eax,4)
> 	movl %eax,EAX(%esp)		# save the return value
> tracesys_exit:
> 	call SYMBOL_NAME(syscall_trace)
> 	jmp ret_from_sys_call
> badsys:
> 	movl $-ENOSYS,EAX(%esp)
> 	jmp ret_from_sys_call
> 
> When the tracing thread is reading out the system call and changing it to 
> getpid, the child is at the '*****' line above.  Notice that it's going to 
> execute a system call, unless the syscall number is changed to be illegal, and 
> that the saved eip plays no part here.
> 
> If you did fiddle the registers, they would take effect when the process 
> leaves the kernel (from ret_from_sys_call) and those registers are restored.
> 
> sa...@sk... said:
> > 2. Additionally, why not change that int 80 to be "ud2" or some other
> > opcode that will cause a SIGILL?  When receiving a sigill, just check
> > for the magic opcode and if it is set, do the syscall... this would
> > have the advantage that the ptrace/c-switch overhead would be
> > reduced... 
> 
> re...@cs... said:
> > If the idea is to increase the performance, why not no change the "int
> > $80" for a "call um_syscall". um_syscall can "communicate" when it's
> > strictly necessary.
> 
> These ideas break security if tracing is turned off as a result.  A hostile 
> process could unmodify itself (or generate the system call dynamically) and 
> get access to the host.
> 
> That's not necessarily fatal.  We could have a slow, secure jail mode and a 
> fast non-secure mode.  But I think that there are plenty of ways of speeding 
> things up and keeping it secure.  I would think about putting things like this 
> in after I was reasonably convinced that secure mode was about as fast as it 
> was going to get, and also that relaxing security would provide noticeable 
> speed gains.
> 
> If anyone is interested in starting a uml performance project, I would suggest 
> the following:
> 
> Make sure that all of the system calls that uml makes into the host can't 
> block.  This moves all idle time into the idle thread where it belongs, and 
> where it can be more easily seen.  It also gives the kernel a chance to do 
> something else.  I think this is already the case, but I haven't done the 
> audit to make sure.
> 
> Profile it and see what's taking all the time and fix it. (As an aside here, 
> if someone were to make profile and test coverage configurable like debugging 
> is now, I would put it in :-)
> 
> Make the block driver able to have multiple operations in flight at once.  
> Right now, there is a single io thread, so there can be one io in flight at a 
> time.
> 
> My long-term plan for system calls is to eliminate the tracing thread 
> altogether.  There are two aspects to this - making threads able to 
> PTRACE_CONT and PTRACE_SYSCALL themselves, and allowing threads to intercept 
> their own system calls.
> 
> Allowing threads to PTRACE_CONT and PTRACE_SYSCALL themselves would speed up 
> system calls somewhat and probably significantly speed up fault handling and 
> signal delivery.
> 
> Letting threads intercept their own system calls would involve adding a second 
> slow system call path to the host.  This would just deliver a signal 
> (SIGSYSCALL, say) to the thread, and the SIGSYSCALL handler would (in uml's 
> case) enter the kernel and do the system call.
> 
> These two would eliminate context switching back and forth between the tracing 
> thread and the others.  uml might have a chance of getting within reasonable 
> distance of native performance at that point.
> 
> If anyone wants to start looking at the mods needed in the native kernel for 
> this, we could have something to propose reasonably early in 2.5.
> 
> 				Jeff
> 
> 
> 
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
>