Re: kernel stack challenge

[Timothy Miller <miller@techsource.com>]

Patrick J. LoPresti wrote:

> Whether it is a good idea in this context is another question.  My
> concern is that it is hard (impossible?) to bound the memory
> consumption, both stack AND heap, of a Lisp program statically.  I
> would expect such bounds to be important for an implementation of a
> security model.  With a Lisp program, you cannot be sure under what
> conditions it will exceed whatever space you have alloted for it.
> Which means that, although it cannot crash the kernel, it cannot be
> used to build a reliable system, either...
> 

I think 100K is rather large for an interpretor to be included in the 
kernel, but putting that aside...

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.

Mostly it would be kernel programmers who write the policies, and those 
would appear in some /etc directory, put there by Red Hat, and 
selectable by admins using some GUI.

Someone writing a policy which caused the VM to explode would be no 
different from nVidia writing a kernel driver which did it more directly.

The advantage of scripting the policy (which is essentially what this 
is) is that they could be switchable more dynamically, and they could 
refer to kernel structures more abstractly.