Re: Kernel support for peer-to-peer protection models...

From: Ivan Godard
Date: Sun Mar 28 2004 - 15:21:33 EST



----- Original Message -----
From: "Pavel Machek" <pavel@xxxxxx>
To: "Ivan Godard" <igodard@xxxxxxxxxxx>
Cc: "Linux Kernel Mailing List" <linux-kernel@xxxxxxxxxxxxxxx>
Sent: Sunday, March 28, 2004 10:54 AM
Subject: Re: Kernel support for peer-to-peer protection models...


> Hi!
>
> > > Strange system.... If an application does not grant kernel access to
> > > its space, how is kernel supposed to do its job? For example, that
> > > "paranoid DLL" becomes unswappable, then?
> >
> > Pretection is in the *virtual* space, not physical. The physical-page
> > manager (who has the TLB and underlying mapping tables in its space) can
see
> > and deal with any physical address, which in turn has the usual aliasing
> > relationship with virtual addresses. Of course, physical is just one of
the
> > virtual spaces (and is distinguished solely by the one-to-one
> > virtual-physical mapping). So the protection can be penetrated by anyone
who
> > can see the underlying physical page - but that's always true.
>
> Aha, so some part of kernel exist that has "absolute right". Ok, now I
> can imagine that it can work.

The "boot process" comes up with unlimited access to everything and the
virt2phys direct mapped. As it forks procesess it can arbitrarily restrict
their vision, transitively, and set the translation tables any way it wants.
What I've sketched is one model, where a particular virtual space is used to
map physical and the kernel is broken up into distinct address spaces with
protection boundaries between, and each driver and app in ots own space. But
you could emulate a conventoional, with the kernel and the drivers all in
one space (and mutually vulnerable), or others.

> > > If most changes are in arch/, it should be acceptable...
> >
> > I fear that it might be more extensive than that :-)
>
> Well, make patch and lets see... That means that 2.8 needs to be your
> target. If impact outside of arch is not "total rewrite", you might
> have a chance. If it is "total rewrite".... well you just need to be
> very clever.

How badly would the average driver break if it did not have direct data
access to kernal data structures? Calls into the kernel and direct access by
the called functions are OK.

Ivan


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