Hi,
I have some ideas, which I think:
- Wouldn't be too hard to implement,
- And would give Linux a distinctive advantage over competing
platforms such as Solaris or Windows, when executing Java or .NET code
Basic functionality:
- Enable some user processes to execute user code in kernel mode. This
would reduce the need for context switches, especially for programs
which spend a great deal of time making system calls.
- However, this could threaten system stability if the user process'
code had bugs in it. So the functionality ought to be restricted only
to trusted processes.
So lets define a new capability: CAP_KERNELMODE meaning the process
can enter kernel mode.
New system call: syskernelmode(int flag). Provides a means of a user
process to enter/exit kernel mode execution. Flag turns kernel mode
on/off. Only can be called by processes with the CAP_KERNELMODE
capability.
Mono & Java
The kernel of an operating system provides isolation and protection
between processes, partially since traditional programming languages
such as C provide no such protection. However, some newer languages
such as Java and Mono/CLI/.NET do. Thus, for programs written in such
a system, it should be safe (assuming the security and safety
mechanisms provided by the language are sufficiently complete and the
runtime is bug-free) to run them in kernel mode, without the OS'
protection mechanisms being exercised, relying instead on the
guarantees of safety provided by the compiler.
Also, in both Java and the CLI, the ability is provided to develop
software in a mixture of Java/C#/whatever, and traditional programming
languages such as C, which do not provide the same safety guarantees.
Thus the same process may contain some code which we want to allow to
run in kernel mode, and some code which we don't.
So, I would propose controlling the ability to run in kernel mode on a
page-by-page basis. So with each page, the following flag would be
associated or not: KERNELTRUST, indicating the code contained in this
page is trusted to run in kernel mode. Now, JITed bytecode can be put
in KERNELTRUST pages, and allowed to run in kernel mode by calling
syskernelmode; but native code pages will not have KERNELTRUST, and
attempts by them to call syskernelmode will fail.
A few other considerations:
- As well as CAP_KERNELMODE capability, we should have another one
CAP_KRNLMODEBYPAGE, indicating that the CAP_KERNELMODE capability
extending only to KERNELTRUST pages of a process.
- KERNELTRUST pages should all be set read/only, so native code cannot
overwrite them.
One problem is preventing native code from jumping to the middle of a
function in a KERNELTRUST page; it should only be able to reach them
through valid entry points. One solution might be to have a
syskerneljump(void * address) system call, which enters kernel mode
and jumps to address, but only if address is declared in executable
file to be a valid entry point in a KERNELTRUST page. Then, a
KERNELTRUST page would only be privileged if entered via
syskerneljump, which checks that a valid entry point is being called.
Finally, attributes can be added to functions in the programming
language (Java or C#)
* AlwaysKernelMode – function should always execute in kernel mode; if
called in user mode, context switch to kernel mode.
* AlwaysUserMode – function should always execute in user mode; if
called in kernel mode, context switch to user mode.
* UseCallersMode – execute in whatever mode (kernel or user) the caller was in.
If a process has CAP_KRNLMODEBYPAGE, these attributes should only be
respected for native code JITed for verifiable managed code (to use
the CLI terminology); but if CAP_KERNELMODE is set, the attributes can
be respected for native (i.e. C language) code also.
Cheers
Simon Kissane
Hi
Having posted the below to this list, Denis Vlasenko pointed out to me
(in an email) that I should have said "user<->kernel" switch, not
context switch. Yep, my mistake. He argues that is not that big. Of
course its no where near as big as a context switch. But its still
something.
Also, I found a website by someone who had this idea before me (and
unlike me, actually implemented it!).
"Kernel Mode Linux" by Toshiyuki Maeda
http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/
Main difference is, that rather thinking in terms of Java or Mono
support, he is thinking in terms of another system he calls "Typed
Assembly Language". Same basic idea though...
Cheers
Simon Kissane
On Sat, 16 Oct 2004 14:11:32 +1000, Simon Kissane <[email protected]> wrote:
> Hi,
>
> I have some ideas, which I think:
> - Wouldn't be too hard to implement,
> - And would give Linux a distinctive advantage over competing
> platforms such as Solaris or Windows, when executing Java or .NET code
[snip]
--
Simon Kissane
http://simonkissane.blogspot.com/
Why would I care ? I need the MMU for paging and to avoid fragmentation
of the system. If I have the MMU on then memory protection checks are
free.
Except in 4G/4G mode syscalls are extremely cheap too nowdays.
Alan
On Sat, 2004-10-16 at 00:11, Simon Kissane wrote:
> Hi,
>
> I have some ideas, which I think:
> - Wouldn't be too hard to implement,
> - And would give Linux a distinctive advantage over competing
> platforms such as Solaris or Windows, when executing Java or .NET code
Last time I checked Java code still ran a lot slower than the native
equivalent. If you are trying to speed up your Java apps then improving
the JVM would be a much better use of your time.
The kernel is just another program, the same code will run just as fast
in kernel mode as in user mode.
Lee
On Saturday 16 October 2004 15:59, Simon Kissane wrote:
> Hi
>
> Having posted the below to this list, Denis Vlasenko pointed out to me
> (in an email) that I should have said "user<->kernel" switch, not
> context switch. Yep, my mistake. He argues that is not that big. Of
> course its no where near as big as a context switch. But its still
> something.
>
> Also, I found a website by someone who had this idea before me (and
> unlike me, actually implemented it!).
> "Kernel Mode Linux" by Toshiyuki Maeda
> http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/
> Main difference is, that rather thinking in terms of Java or Mono
> support, he is thinking in terms of another system he calls "Typed
> Assembly Language". Same basic idea though...
Nice page. Doubly nice considering that they have working code.
However, it does not mention how much of a speedup they achieved.
--
vda
On Sun, 17 Oct 2004 22:53:28 +0300, Denis Vlasenko
<[email protected]> wrote:
> On Saturday 16 October 2004 15:59, Simon Kissane wrote:
> > Also, I found a website by someone who had this idea before me (and
> > unlike me, actually implemented it!).
> > "Kernel Mode Linux" by Toshiyuki Maeda
> > http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/
> Nice page. Doubly nice considering that they have working code.
We looked at it briefly as part of a discussion in the office about
user mode device drivers, not really that seriously - one of those
lunchtime things. In the end it's far better to just mmap /dev/mem and
be done with it anyway. Other than that I can see little use for this.
Machines without an MMU running uclinux effectively run like this
anyway.
Jon.
Alan Cox <[email protected]> wrote:
> Why would I care ? I need the MMU for paging and to avoid
> fragmentation of the system. If I have the MMU on then memory
> protection checks are free.
>
> Except in 4G/4G mode syscalls are extremely cheap too nowdays.
Yes, but kernel mode support in user programs would allow user mode
device drivers to do stuff that currently cannot be done at all from user
space such as handling interrupts and scheduling DMA operations.
Just think about how nice it would be if the kernel level DRI driver
modules that are currently completely separate from the user space X
drivers could be all in one place? Then users would no longer have to
worry about making sure they upgrade their kernel so it has the correct
kernel module installed at the same time that they upgrade X or get new
drivers for their X server.
IMHO I am not sure how much speedup you would gain from kernel mode Linux
for user space programs (it might surprise us, or maybe it isn't much),
but the ability to support user mode device drivers would be good IMHO,
especially for graphics.
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
On Llu, 2004-10-18 at 20:50, Kendall Bennett wrote:
> Alan Cox <[email protected]> wrote:
>
> > Why would I care ? I need the MMU for paging and to avoid
> > fragmentation of the system. If I have the MMU on then memory
> > protection checks are free.
> >
> > Except in 4G/4G mode syscalls are extremely cheap too nowdays.
>
> Yes, but kernel mode support in user programs would allow user mode
> device drivers to do stuff that currently cannot be done at all from user
> space such as handling interrupts and scheduling DMA operations.
DMA doesn't need the kernel's help except for when you want to manage
security - DRI is quite special in that way. A driver to provide
mmapable DMA memory is trivial. IRQ's are *much* harder because you have
to clear the IRQ source in the IRQ handler, but people have code that
does this and then sends signals.