Re: kernel stack challenge
From: Timothy Miller
Date: Mon Apr 05 2004 - 15:53:23 EST
Sergiy Lozovsky wrote:
1. Give system administrator possibility to change
security policy easy enough without C programminig
inside the kernel (we should not expect system
administartor to be a kernel guru). Language of higher
lavel make code more compact (C - is too low level,
that's why people use PERL for example or LISP). Lisp
was chosen because of very compact VM - around 100K.
And you expect your sysadmins to know LISP? I would hardly think of
LISP as any kind of simplification to anything.
I mean, I like the language and all, but it is in no way "simpler" than
C and it's definately not appropriate for in-kernel stuff.
2. Protect system from bugs in security policy created
by system administrator (user). LISP interpreter is a
LISP Virtual Machine (as Java VM). So all bugs are
incapsulated and don't affect kernel. Even severe bugs
in this LISP kernel module can cause termination of
user space application only (except of stack overflow
- which I can address). LISP error message will be
printed in the kernel log.
In theory, we could develop the kernel in a language that does all sorts
of protection, garbage collection, run-time checking, etc. Kernel
developers choose not to because the performance hit would be HORRIBLE.
Now... that doesn't mean you can't do kernel-level stuff in LISP. You
just don't do it _in_ the kernel. Given the absolutely MASSIVE overhead
you're already incurring by using a LISP interpreter, having to
context-switch into user space won't hurt in the least. So, what you do
is have a C-based stub in the kernel which passes stuff off to the
user-space LISP daemon which calls back into the kernel for accessing
devices, etc.
THAT would be a much better way of doing this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/