Re: kernel stack challenge

[Sergiy Lozovsky]

--- Valdis.Kletnieks@xxxxxx wrote:
> On Mon, 05 Apr 2004 13:33:10 PDT, you said:
> 
> > I don't know how it is possible (if it is - it's
> easy
> > to fix). All LISP print functions print
> information
> > into the buffer of limited size. (LISP program has
> no
> > access to the format or buffer length arguments of
> > snprintf). When buffer is full or string has an \n
> at
> > the end - VM calls printk.
> 
> That's how it's *supposed* to work when everything
> is working *correctly*.
> 
> Now re-do your example, and assume there's a *BUG*
> in the VM.  For instance,

Here is a main idea. I can put a lot of effort to
debug VM once. I (and others) are not destined to do
such kind of debugging (with C inside the kernel)
after that. It's like with JAVA VM - it's hard to
debug VM, but it should be done once - after that JAVA
program can't use a pointer to a nonallocated memory.
Those who continue to use C - should be careful with
pointersin each program.

> what happens if there's a fencepost error on "buffer
> is full"?  All that takes
> is one line that says 'if (ptr > bufsize)' rather
> than 'if (ptr >= bufsize)'.
> 
> Yes, proper encapsulation *helps*.  But it's

Exactly. :-) i'm not claiming that I solve all
problems. But this technology helps to make
development of some kernel parts easier. Encapsulation
helps and you can easily debug LISP program in the
userspace before loading it into the kernel.

No matter what particular LISP program does - it can't
crash the kernel - C code can do that easily.

Serge.

> certainly *NOT* any sort of
> guarantee that *all* bugs will be stopped.  For
> comparison, read up on the Java
> VM - although it does a very good job of sandboxing
> a Java program, there
> *have* been bugs and exploits found over the
> years....
> 
> 

> ATTACHMENT part 2 application/pgp-signature 



__________________________________
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/