OSDev.org

Is there any benefit to using int instead of call inside of a kernel?

INT (or SYSCALL/SYSENTER/SWI) are used to use kernel services from userland.
User code should not be allowed to just call kernel functions directly, as the kernel code should not be directly user accesible (it might have sensitive information).
They're slower than a plain call, because they have to do a mode switch and have a fixed entrypoint, but are much more secure and do not depend on the kernel implimentation (if direct calls were used, the programs would need to be relinked for each different version of the kernel).

thepowersgang wrote:User code should not be allowed to just call kernel functions directly

Well, as a matter of fact, it's not "should not" but "can't". Userspace's using a ring 3 code segment, and kernel functions require ring 0 to execute. You have to switch cs selector on kernel call, it's mandatory (and change it back on return).

About speed: int is the slowest. Plain call is fast, but syscall can be even faster. That's because of the fact that a plain call has an immediate relative address that has to be parsed and relocated, while syscall use a precalculated absolute address stored right inside the cpu (no memory lookup and calculation needed). Furthermore, syscall expects specific GDT, which simplifies a lot (no need to parse gdt entries, just alter selectors), and it does not check many things that an interrupt call or a plain call would. Intel and AMD manuals both describe this in detail, you can check it if you're in doubt.

About security: int calls are safer, you have to do precaution and extra checks for syscall (see latests sysret exploit on win and bsds). It worth mentioning, that you should use IST mechanism if you want syscall to be safe (only available for long mode).

GAT wrote:Is there any benefit to using int instead of call inside of a kernel?

As an answer to your actual question, it may be useful if doing module-like development in the kernel. Then you get the same benefits of not requiring relinking if modules are compiled separately. It is slower than direct calls but you know that.

Antti wrote:

GAT wrote:Is there any benefit to using int instead of call inside of a kernel?

As an answer to your actual question, it may be useful if doing module-like development in the kernel. Then you get the same benefits of not requiring relinking if modules are compiled separately. It is slower than direct calls but you know that.

You can get the same benefits in a number of ways without using ints. One way is to code internal calls as invalid instructions, and patching them to direct-calls at runtime invalid insttruction fault handler. Another is like traditional DLL resolution at load-time. A third way (in a segmented kernel), is to code a far call via invalid selector (0-3 for instance), and then patching at runtime to a far-call. All of these allow the flexibility of runtime module resolution without the costs of ints. After the initial patch / relocation, standard calls are used.

It can be especially helpful during the early part of kernel creation to use INTs. They are very simple to code. I am currently using INTs to implement the "yield()/sleep()/block()" functions in both ring 3 and ring 0. It would probably run faster in ring 0 if I used a direct call into the scheduler, with a lot of carefully coded ASM -- but that is an optimization to handle later.

Currently in my kernel i am using call to deal with yields and the like for threads, so if int is slower than call then I think I'll just stick with call.

I would say the interface(call, INT, sysenter, syscall) does not matter much.
You would need a call interface internally, and you can encapsulate it with any or all of the above methods.