Re: kernel stack challenge

[Sergiy Lozovsky]

--- Horst von Brand <vonbrand@xxxxxxxxxxxx> wrote:
> Sergiy Lozovsky <serge_lozovsky@xxxxxxxxx> said:
> 
> [LISP inside the kernel?!]
> 
> > Basically there are two reasons.
> > 
> > 1. Give system administrator possibility to change
> > security policy easy enough
> 
> SELinux

To create a new 'security model' one should write a C
program within Selinux user space security server.
People like to use higher level languages.
 
> >                             without C programminig
> > inside the kernel (we should not expect system
> > administartor to be a kernel guru).
> 
> As 97.572% of the job has to be done in userland
> anyway, place your
> checks/high-level language/GUI frobnitzer in there
> at will. Compile to a
> compact, easy-to-handle, digitally signed, binary
> blob and stuff _that_
> into the kernel as needed.

I'm not ready to put a binary compiled with Common
Lisp or PERL (if it exists) compilers into the kernel.
At the same time I want people to benefit from using
high level langages (even kernel gurus don't use
Assembler all the time, higher level languages is
easier to use and less lines of code to write).

.....

> > 2. Protect system from bugs in security policy
> created
> > by system administrator (user).
> 
> Sounds like you are demanding a solution to Turing's
> test here... and also
> to the halting problem.

I didn't claim that I solve all problems on earth :-)
What I can claim:
1. Some kernel parts can be developed with language of
higher level than C.
2. Problems with such parts can be to some extent be
encapsulated within VM (no, it's not 100% fool prof
for sure), but it helps.
3. Code can be easily debugged in the user space
(running with user space VM) and used in the kernel
after that.
 
> >                                 LISP interpreter
> is a
> > LISP Virtual Machine (as Java VM).
> 
> So what? If the policy just leaves out everybody, or
> lets anybody fool
> around with the hardware, you are royally screwed in
> any case.

I didn't get the question.

> >                                    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.
> 
> If it is running in userspace, why do you place the
> interpreter in the kernel?

LISP code is located in the kernel. Application issues
a system call LISP program checks arguments of this
call. If LISP program fails (crashes) - VM will return
default value which is EACCESS, so application will
get 'access denied'. (and will fail, probably).

Serge.

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/
-
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/