Messages in this thread | | | Date | Tue, 19 Oct 1999 13:12:19 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: access_ok inside kernelspace |
| |
On Tue, 19 Oct 1999, Tigran Aivazian wrote:
> I agree that it should be (and is now) possible to use system calls from > within system calls (i.e. by going through int 0x80 via _syscallX(). > However, some of the examples you give have nothing to do with this issue.
there is no reason to go through int 0x80 if you know what system call you will be calling, obviously. But it's not a problem either ...
> > some users of this feature: exec() is using fop->read() > that is not going through _syscallX(), that is just using a function > pointer visible indirectly.
i was answering to your assertion that:
> > calling sys_function() functions directly doesn't look right: > > > > 1. what if one was to do some accounting of the system calls. Not > > going through the int 0x80 would break this. > > > > 2. what if one were to temporarily redirect some system calls to > > another handler (like timetravel.o module does). > > > > 3. probably other "what-ifs".
calling sys_function() funcions directly _is_ right. You can call sys_read() just as fine as you can call ->read(). You could even do an int $0x80 as well, but why should we, it's overhead.
i was not talking about _syscallX() and you were not talking about _syscallX() either in the above paragraph.
you raise a new point of:
> Of course the examples you gave are valid usages of kernel functions > via indirect pointers but NOT of using the system calls.
there _no_ difference. I dont know why you think that the sys_ functions are in any way different, they are kernel functions which can be called by any other kernel function. For example sys_uselib() calls sys_open(). vt_ioctl() uses sys_ioperm(). It's perfectly fine! Usually we do not call the 'base' functions because it often just contains checks we'd pass anyway (and the kernel is trusted anyway) - but sometimes we pass information along (from user-space) that should be validated by the top-level syscall function.
you are also raising the issue of why doesnt the kernel use the system-call entry trap to execute system calls. The only reason: it already knows the address of the function, it doesnt have to multiplex. There might be rare cases where the system-call-number is not known in advance (iBCS2?) and it might be better to simple wrap it into a trap, but that should work as well.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |