On May 1, 10:45 pm, Thomas ****in <****...@[EMAIL PROTECTED]
> wrote:
> According to Robert Spykerman <robert.spyker...@[EMAIL PROTECTED]
>:
>
> > I was wondering why linus was stuffing parameters in registers to make
> > linux syscalls, instead of pu****ng to the stack. I must ask a linux
> > kernel hacker.
>
> The kernel and the application code (so-called "userland") do not run
> with the same privilege levels (the kernel code is allowed to tinker
> with the hardware, not the userland). A system call is a jump between
> the two worlds, usually through a software interrupt or an equivalent
> mechanism. That jump entails a "stack switch", which means that the
> kernel code obtains its own stack (the stack pointer register value is
> saved, and the value for the kernel recovered during the switch; the
> reverse operation occurs when the system call returns). To access
> the userland stack, the kernel must first recover the userland stack
> pointer.
>
> Besides, the userland is not trusted by the kernel. The stack pointer
> could be bogus, or point to a part of the memory which the kernel can
> physically access (with its "kernel rights") but the userland cannot.
> Before accessing the user stack, the kernel would have to check whether
> that memory area is safe, which is doable (and actually done for system
> calls such as read() or write() which exchange data chunks with the
> userland) but somewhat complex and expensive. Besides, the kernel really
> needs a safe stack of its own (the userland stack could be concurrently
> modified from another thread, hence the kernel cannot safely store its
> own data in it).
>
> Hence it is safer and simpler to exchange data through registers when
> possible. As an added bonus, this means that the userland code needs not
> maintain a C-like stack, if it runs code written in a language which
> does not have that concept, or would like to reuse the stack pointer
> register for other usages (except for signals, but there is the
> sigaltstack() system call for that).
>
> --Thomas ****in
Ok points taken, the only thing is I guess if you want to do syscalls
the linux way on an IA-32 you kind of are starved of registers and (I
guess depending on code) you may have to save them first, then load
up EAX et al with the function call parameters then syscall...
This contrasts with OSX / BSD where you push the syscall parameters to
the userland stack and the kernel picks them up. I have to admit,
this seems to me slightly more convenient way of doing it.
I don't really know how expensive PUSH immediates or PUSH addresses
actually are I admit, offhand but I expect given the convenience they
apparently offer, they must be expensive.
Whichever is actually more efficient I do not know... I suspect it
depends on coding style.
Do you have any opinion on this (I'm just bloody curious)?
As you probably realize Thomas, my interest in syscalls is all in the
setting of trying to ****t Albert's ciforth/lina.
By the way, I've been warned by at least one person in the know at
Apple not to use int 0x80 syscalls on OS X, which apparently have been
left in for 'legacy code'. Nevertheless I got some pointers to where
in the source to look.
Does this sort of taboo exist on other *nixes as well? (I ask because
I'm still very much a nix nub/scrub)
The apple guys have warned me, but some BSD guys apparently have no
qualms in direct syscalls...
http://www.int80h.org/bsdasm/
Anyway, if I am not making sense I need to go to bed to reboot and fix
the memory leak in my brain. Any ideas on how to keep my brain real
time and mission critical graciously accepted :P
Robert Spykerman
|
