Re: A Layered Kernel: Proposal

[Mike Fedyk]

Grigor Gatchev wrote:
> On Tue, 24 Feb 2004, Mike Fedyk wrote:
> > Not true.  What you are asking for is userspace protection to kernel
> > modules.  You won't get that unless you use a micro-kernel approach, or
> > run different parts of the kernel on different (to be i386 arch
> > specific) ring in the processor.  Once you get there, you have to deal
> > with the various processor errata since not many OSes use rings besides
> > 0 and 3 (maybe ring 1?).
>
>
> These are two possible approaches. Still another is to have the lowest
> layer export functions for memory handling - thus only the lowest layer
> will have to run in ring 0 (almost all arch that support Linux have a
> corresponding ability), and will handle the protection requests from the
> upper layers... Other approaches exist, too. A discussion may help to
> clarify which is the best.

And you get an effective "context switch" even if you're not crossing 
process boundaries.  (it could be argued that different layers on 
seperate rings are effectively now a "process"...)

> > > User nesting: The traditional Unix user management model has two levels:
> > > superuser (root) and subusers (ordinary users). Subusers cannot create
> > > and administrate their subusers, install system-level resources, etc.
> > > Running, however, a subuser in their own virtual machine and Personality
> > > layer as its root, will allow tree-like management of users and resources
> > > usage/access. (Imagine a much enhanced chroot.)
> >
> > That is differing security models, and it's being worked on with (I
> > forget the term) the security module framework.
>
>
> Within a layered kernel scheme, this tree-like model is very natural and
> simple: all protection is provided by the standard kernel mechanisms. Of
> course, it maybe can be improved; that is what the discussion is for.
>
>
> > > Platforming: It is much easier to write only a Personality layer than an
> > > entire kernel, esp. if you have a layer interface open standard as a
> > > base. Respectively, it's easier to write only a Resources layer, adding a
> > > new hardware to the "Supported by Linux" list. This will help increasing
> > > supported both hardware and platforms. Also, thus you may run any
> > > platform on any hardware, or many platforms concurrently on the same
> > > hardware.
> >
> > There is arch specific, and generic setions of the kernel source tree
> > already.  How do you want to improve upon that?
>
>
> Currently, Linux supports (actually, is) only one, Unix-descended
> platform. With a layered model, an emulator, eg. Wine, could be easily
> rewritten as a Personality layer, and this would turn it instantly into
> a free Windows. A modification of the Linux sofware and tools could
> produce a free Solaris. Some people may like a free OS/2, QNX, VxWorks
> etc. Other platforms will became easier to create and test, thus helping
> the free software evolution. On most architectures, you will be able to
> emulate another processor right in the kernel, either directly, or by a
> code emulator: all other will go then much easier. Much more advantages
> exist...

One way or another, you'd have to have a "personality".  With Linux 
there is one in the kernel, and possibly many in userspace.  You won't 
find many here that will agree it should be any other way.

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