Subject: More SchemeOS Brain Dumps

From: Moshe Zadka <[email-masked]>
Date: Tue, 23 May 2000 08:42:28 +0300 (IDT)

Well, the goal of every operating system writer is not to provide as much
functionality as it can: it is to provide as little functionality as is
possible to get away with.

In that spirit, my goal is to have an OS without:

 -- Processes
 -- Security
 -- Threads 
 -- File system
 -- Etc.

How?

Well, processes are easy: there is only *one* SchemeVM "process". After
initialization is complete, it uses the built-in function

(set-timer <proc>) 

To have a procedure that the SchemeVM will call on every "timer
interrupt", with the current continuation (the currently executing
function) as an argument. This will enable the scheduler to be just a
scheme procedure, which is part of the initialization code for the
SchemeOS environment.

That gives us primitives to implement both "processes" and "threads"
inside Scheme, and because scheme is "safe" (as opposed to C), it is
possible to do so without ugly race conditions.

Now, all this would be well and good if this was a
single-user-all-powerful-win95-like OS. But it's not (necessarily). And
yet, we don't want any security in the kernel. So (and just to prove I
have enough MIT genes) I realized that the most general security model is
also one of the simplest, and that is the "sandbox" model. I.e., have a
new builtin function

(call-with-sandbox <proc> <symbols> <thunk>), will call thunk, but
whenever <thunk> tries to find a symbol outside the current environment,
which is in the <symbols> lists, (<proc> <symbol>) is called to get the
value, instead of the normal enviroment lookup. This can be done, e.g., by
having a special pointer in the enviroment list.

Note that suddenly, we don't need any notion of "security", nor of "IPC", 
which can all be done via simple calls-across-namespaces, since there is a
single address space.

--
Moshe Zadka <[email-masked]>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com

---

From: [email-masked]
Date: Tue, 23 May 2000 08:51:50 +0300

> which can all be done via simple calls-across-namespaces, since there is a

How efficient do you think it'll be?
IPC is considered the single most important bottleneck in MKs. Are we making
this bottleneck better or worse?

--
Chen Shapira	Web Developer and Linux Activist
The algorithm for finding the longest path in a graph is NP-complete.
For you systems people, that means it's *real slow*.

---

From: Moshe Zadka <[email-masked]>
Date: Tue, 23 May 2000 09:03:23 +0300 (IDT)

> this bottleneck better or worse?

Much better -- I don't need any serialization, because there aren't
multiple address spaces to deal with -- this isn't really IPC, this is
simply procedure calls in Scheme

---

From: Omer Mussaev <[email-masked]>
Date: Tue, 23 May 2000 08:52:32 +0300

> In that spirit, my goal is to have an OS without:

My view: (not opposite, but with different accents):

We should have 3+ tier architecture:
mk to have all the dirty work
metakernel to have competent message/object/cc passing, first-order
    scheduling, and Unix emulation.
stack of "reflective" vms. (there the '+' comes in)

Each vm will represent a process group, and will be able to fork
more vm's.

Now, what is a relation of vm and process? a process is a scheme
closure, which can be evaluated in and only in context of it's
respective vm. the vm will enable those processen to share "local
environment", and to request "foreign environments".

"local environment" is represented as 2 continuations - one for
data and one for control. "foreign" is one - we do not have
direct access to data there. "foreign" ones will be useful for
shared services, like filesystems, networking, remote debuging,
whatever.

vm's are scheduled by metakernel. closures are scheduled non-preemptively.

the "reflection" part comes true when we state that each vm will store all
its children's respective local envs. Thus, on failure, we will be able
to restore each child at will.

> ------------------------------------------------------------------------
> Failed tests, classes skipped, forgotten locker combinations.
> Remember the good 'ol days
> http://click.egroups.com/1/4053/9/_/_/_/959060582/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> [email-masked]

--
Omer Mussaev    051-308-214   mailto:[email-masked]
systems programmer, Mercury Interactive/RND/Conduct/core

---

From: Omer Mussaev <[email-masked]>
Date: Tue, 23 May 2000 08:57:43 +0300

Omer Mussaev wrote:

>     scheduling, and Unix emulation.

I intended to say that metakernel is not a single entity, but rather a
collection
of services, which include both system's parts, and user's services. Think of
it as HIRD part of HURD.

---

From: Moshe Zadka <[email-masked]>
Date: Tue, 23 May 2000 10:12:23 +0300 (IDT)

> mk to have all the dirty work

Is "dirty work" defined as "lowe level access"? Then can you explain why
it is not simply easier to put this functionality in the vm?

>     scheduling, and Unix emulation.

Unix emulation should come much, much later, via user-level functionality.

Personally, I'm a bit afraid of "heavy mesage passing", because of the
serialization overhead. I'd much prefer to figure out a way not to have so
much  cross-adress-space-communication. Seems the easiest solution is to
have one address space.

> shared services, like filesystems, networking, remote debuging,

Much too complicated, IMHO.

> vm's are scheduled by metakernel. closures are scheduled non-preemptively.

Hmmmmm....I'm not sure I like any kind of co-operation assumed. Note that
one of the nice things in the sandbox/preemptive combo, is that you can
easily run untrusted code.

---

From: "Gaal Yahas" <[email-masked]>
Date: Tue, 23 May 2000 08:39:59 -0000

--- In [email-masked], Moshe Zadka <moshez@m...> wrote:
> Well, processes are easy: there is only *one* SchemeVM "process".
> After initialization is complete, it uses the built-in function
> 
> (set-timer <proc>) 
> 
> function) as an argument. This will enable the scheduler to be just
> a scheme procedure, which is part of the initialization code for
> the SchemeOS environment.

Sounds like you're getting non-preemtive multitasking here. How does
the scheduler jump to a different procedure when the current one's
time is up? What is your handle on a context anyway, if not a process?
That is, say I originally create a procedure p and init it. It runs,
and in less than its maximum alloted time, calls another procedure b.
Will your schedule look up a call stack to find that b has been called
by p? In what sense can you then say that p is not "really" a process?

> possible to do so without ugly race conditions.

Is it? What if I'm touching one global in two different procedures?

> I realized that the most general security model is also one of the
> simplest, and that is the "sandbox" model. I.e., have a new builtin
> function
> 
> whenever <thunk> tries to find a symbol outside the current 
> environment, which is in the <symbols> lists, (<proc> <symbol>)
> is called to get the value, instead of the normal enviroment 
> lookup. This can be done, e.g., by having a special pointer in\
> the enviroment list.

> Note that suddenly, we don't need any notion of "security", nor 
> of "IPC", which can all be done via simple calls-across-namespaces,
> since there is a single address space.

I am certainly yet to understand everything you're planning to do,
but it seems to me that problems of security (I'll leave IPC aside)
still exist by another name. Who does decisions about a "process"'s
priviledges? Can a procedure that started with permissions to one
set of symbols gain the right to access a different set? How? I
imagine you have an idea of some protocol by which a called proc
may talk with its caller and ask for these privileges: sure, but how
is this essentially different from putting security in a kernel?

Gaal

PS: I'm writing this from eGroups's site. I apologize for any wierd
linebreaks in quoting above.

-- 
believing is seeing
[email-masked]
http://www.forum2.org/gaal/

---

From: Moshe Zadka <[email-masked]>
Date: Tue, 23 May 2000 12:24:03 +0300 (IDT)

On Tue, 23 May 2000, Gaal Yahas wrote:

> time is up?

Well, since it's a user-level process, it's not for the kernel to know,
but it simply calls a stored continuation.

> What is your handle on a context anyway, if not a process?

A continuation. A CONTINUATION. I've said it about 50 times in my last
post. For a good introduction on continuations, consult any advanced
scheme book.

> In what sense can you then say that p is not "really" a process?

In the sense that it does not have a seperate address space.

> Is it? What if I'm touching one global in two different procedures?

You'll have a bug. But the system will not crash. Mutexes will be simply
(set-timer #f). Of course, you might send-box set-timer away and have
a higer level mutex creation mechanism. But that's, again, a library
issue.

> priviledges?

Whoever called the procudure. Don't think "processes", think "thunks"

> Can a procedure that started with permissions to one

Loads of ways: e.g., you can replace the security model wihtout rebooting.
I'm trying to write an a good kernel which can be used reliably for a
number of things.
For one thing, sand-boxing procedures will allow me to have a good way to
deal with ILOVEYOU.
--
Moshe Zadka <[email-masked]>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com