lkml.org 
[lkml]   [1998]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Differences between FreeBSD and Linux system call mechanism
Date
Followup to:  <Pine.LNX.3.95.980903141003.347A-100000@chaos.analogic.com>
By author: "Richard B. Johnson" <root@chaos.analogic.com>
In newsgroup: linux.dev.kernel
> [SNIPPED]
>
> When you are in user-mode in an ix86, there is no such thing as a
> "jump" to the kernel. You either "trap" to the kernel, you execute a
> call through a call-gate, or you load a TSS to execute a task-switch to
> kernel-mode code.
>

The SYSENTER instruction is pretty much a jump to the kernel.

> In any event, your task ceases to exist when the kernel executes. If it
> were not for "features" provided by the kernel such as items that persist
> (files, pipes, shared memory, etc), isolation between the kernel and user-
> mode tasks is perfect because they don't exist at the same time.

It doesn't "cease to exist". Switching to kernel space does NOT cause
a task switch. Rather, we say that task XXXX is executing in kernel
mode. This may sound like a nitpick, but is a very important
difference when you do kernel-mode programming.
> The kernel executes functions on behalf of user-mode tasks. How you get
> this to happen is dependent upon the system architecture. Linus chose
> to execute interrupt 80 hex (which was used by BASIC in MS-DOS).
> Since an interrupt is a privileged instruction, when it occurs in
> user-mode code, a trap occurs. Kernel software, pointed to by the
> IDT handling 80 hex, analyzes the user-mode requests and performs
> them on behalf of the user-code code. The nature of the interrupt
> handling code allows the interrupted task to be restarted since
> the context of the interrupted task is saved.

INT is *not* a privileged instruction. If it was, it would cause a
General Protection Fault (#GP). It doesn't; if the interrupt gate has
the appropriate ring brackets (which, of course, the INT 0x80 gate
does), it will allow the gate to be crossed.

> You need not issue an interrupt to get the attention of the kernel.
> User-mode code could execute any privileged instruction. For instance,
> the runtime library could execute the CLI instruction. This would
> trap to the #GP(0) (General Protection) handler in the kernel at which
> time the kernel could analyze the user-mode request. This is certainly
> not what #GP(0) was provided for, but it could work.

CLI would suck since if the process have IOPL=3 (available via system
call for root processes) CLI is no longer a privileged operation.
However, this is pretty much how DOSEMU works: by trapping privileged
instructions and emulating them. The x86 provides a special "V86"
mode which makes emulating an 8086 easier.

> Using a TSS from user-mode, i.e., LTR will not directly load the
> TSS because LTR is also a privileged instruction. It will also
> trap at a #GP(0) unless the TSS is not present. In that case a
> page-fault trap occurs.

LTR is a privileged instruction and as such will #GP(0) regardless of
whether or not *anything* is present in memory. Incidentally, LTR
never actually touches the pointed-at TSS so even if it is not present
will not #PF.

> In any event, such a TSS should never be accessible from user-mode
> or else one could deliberately damage the OS. It would have to be
> faulted-in so the kernel could supply the real one, not one trashed
> from user-mode code.

A TSS, or a descriptor table, writable from user space would be like a
kernel writable from user space: this OS is not and cannot be secure.

> These extra "indirection" steps may actually slow the request for
> kernel services although this is not necessarily so because, for
> instance, a page-fault has been optimized to be very fast since
> it commonly occurs.

It WILL slow the request down (a system call is *much* slower than an
intraprivilege function call), but there is no alternative.

> Any time saved in executing kernel function calls by executing
> code in "strange" ways may be lost as soon as a kernel function
> needs to access something provided by user-mode code such as
> a pointer to a buffer or even a register value itself. It's
> the total time that counts, not the time to make the transition
> from user-mode to the kernel.

This isn't true; the kernel is perfectly able to access anything from
the process as in user space; it is still the same process, just
running in kernel mode.

> There is work being done on a new "SysCall" method. Time will
> tell if it is really faster. My guess is that it will be 6 of
> one-kind and 1/2 dozen of another. Personally I prefer a
> software interrupt because it seems as though this is what
> the ix86 CPUs were designed to use.

SYSENTER is *much* faster, mainly because it doesn't try to muck with
segments. Design decisions that made sense on the i286 (which is
from when most of the segment crap came) no longer make sense.

-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables

-
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.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2011 Jasper Spaans