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

[Ivan Godard]

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


> Hi!
>
> On So 27-03-04 17:32:06, Ivan Godard wrote:
> > > > 1) had a large number of distinguishable address spaces
> > > > 2) any running code had two of these (code and data environment) it
> > could
> > > > use arbitrarily, but access to addresses in others was arbitrarily
> > protected
> > > > 3) flat, unified virtual addresses (64 bit) so that pointers,
including
> > > > inter-space pointers, have the same representation in all spaces
> > >
> > > Hmm, will it be possible to have UML?
> >
> > If by UML you mean Uniform Modelling Language, I don't understand where
the
> > protection model has any impact. UML models flow, permissions are
somewhat
> > superimposed, just like file permissions in a UML model on any
> > machine.
>
> I meant "User Mode Linux" == linux running under linux. Someone
> probably has an URL.

Sorry - I plead ignorance :-)  As the protection is recursive and
transitive, I suppose that you could do this. When the UMK (user mode
kernel) went to change the "real" machine it would get a protection fault
that would be handled by the KMK, emulating the effect. Getting it right and
also performant would be tricky though - is UML a necessary feature?

> > > > 9) Hardware interrupts are involuntary inter-space calls. They do
not
> > > > require locking (assuming the handler is re-entrant - and if not
then
> > only
> > > > from themselves), nor task switch, nor disabling other interrupts.
The
> > > > handler runs in the stack of whoever got interrupted, which
(depending
> > on
> > > > interrupt priorities) could be another interrupt, on an interrupt,
...
> > on an
> > > > app, all mutually protected.
> > >
> > > How do you implement ptrace if apps are protected from kernel?
> >
> > Anybody can make all or part of themselves visible to anybody else. If
you
> > start up an app in your space, you can grant visibility to a debugger in
> > another space. But this applies only to you. For example, suppose that
your
> > app calls a paranoid server DLL passing in a function, and the DLL in
turn
> > calls back your function. Then your stack will have a hunk of you (that
you
> > can see and expose to the debugger), then a hunk of DLL function
activations
> > (which are opaque to you AND the debugger unless you can talk the DLL
into
> > exposing itself), and then another hunk of you again (and again visible
to
> > you and the debugger). The DLL and you (and your debugger) are mutually
> > protected.
> >
> > To do this on a conventional system requires that the DLL runs as a
server
> > process, and getting it to do something for you requires a roundtrip
through
> > the dispatcher. For us it's a simple subroutine call, just as if the DLL
> > were un-paranoid and had been linked into your code. Clearer?
>
> 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.


> If you have "enough" paranoid DLLs, you can then bring the machine
> down due to lack of real memory :-).

No.

> > > > 10) Drivers can have their own individual space(s) distinct from
those
> > of
> > > > the kernel and the apps. Buggy drivers cannot crash the kernel.
> > >
> > > Well... buggy drivers can usually program DMA to do crashing for them.
> >
> > Nope. The DMA has the same permissions as the driver that starts it.
>
> So normal PCI cards are not allowed, or do you have some kind of
> IOMMU?

Nope. Apertures in the memory controller. We looked at doing I/O in virtual,
but the extra traffic on the pins was too expensive (although it did permit
I/O onto paged memory). But it's easy to give each IO its own aperture base,
just by adding a few more high-order bits to the address, and the controller
can make sure that each DMA stays in its aperture. Sort of a poor-man's MMU
:-)

> > > That would be pretty big rewrite...
> > >
> > > Anyway, I believe you *do* want linux on it, if only as a test load.
> >
> > We definitely want Linux. The question is whether Linux will want the
result
> > of our port, or (in finer detail) what parts could we do in what way to
be
> > useful to other people.
>
> If most changes are in arch/, it should be acceptable...

I fear that it might be more extensive than that :-)

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/