Re: kernel stack challenge

[Timothy Miller <miller@techsource.com>]

Patrick J. LoPresti wrote:

>>It's a limited number of people who would actually write these
>>policies. If those people follow certain coding rules, then we CAN
>>have such bounds, by convention.  Yes, those bounds could be violated,
>>but if the programmer (not sysadmin -- they would never write these
>>things in LISP) breaks something, it's just a bug.
> 
> 
> Fair enough.  But then I wonder how many of Lisp's advantages you
> would lose.  I am having trouble imagining "statically bounded Lisp"
> without being so stylized as to hardly be Lisp at all.
> 

Given that the original author admits that the sysadmins using this 
would never actually write any LISP code, I too fail to see why LISP 
would be of any help here.

If you want to be compact and efficient, some really simple 
pseudo-language would do the job well enough.  Optimize for speed of 
execution and compactness of both interpreter and policy code, not for 
easy of writing in the language.

I mean, by choosing LISP, "ease of writing in the language" was thrown 
out the window to begin with!  :)

I think this points us in the direction of something like Forth.  Take 
OpenBoot for example.  I wrote Forth-like interpreters in Pascal when I 
was in highschool.

But if you DO want sysadmins to be able to write this, then something 
resembling shell script would be better.  It wouldn't be quite like 
shell scripting, but it would LOOK like it, and it would have to be 
compiled (by the program that you run to load the policy) into something 
compact and easy to interpret before being fed to the kernel.

Another possibility is to develop a set of tools that compile policies 
written in C into modules that are loaded/unloaded into the kernel 
dynamically.  :)   The compile process would be transparent to the user, 
because the "insert this policy" tool would run it through GCC (unless 
the cached .ko was already up to date, etc.).