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

[Ivan Godard]

We're a processor startup with a new architecture that we will be porting
Linux to. The bulk of the port will be straightforward (well, you know what
I mean), except for the protection model supported by the hardware.  How
would you extend/mod the kernel if you had hardware that:

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
4) no "supervisor mode"
5) inter-space references require grant of access (transitive) by the
accessed space; grants can be entire space or any contiguous subspace
6) inter-space reference has same performance as intra-space
7) you can call across space boundaries in a way that changes the governing
space and consequently the protection environment. Thus both code and data
of a server process or DLL may be non-addressable by an app process, but the
app can call a function (controllably) in the server/DLL and that function
will run in the protection environment of the server/DLL, not that of the
app, though it will run in the app's stack (in the app's address space) with
no task switch. Return unwinds the change. This with full protection both
ways - neither the app nor the server/DLL can klobber each other.
Performance is the same as a conventional intra-space call/return.
8) OS calls are not traps, just inter-space calls, again with full
protection.
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.
10) Drivers can have their own individual space(s) distinct from those of
the kernel and the apps. Buggy drivers cannot crash the kernel.


We could of course ignore the hardware model and emulate a conventional
processor (and might, as a first step of the port), but this would discard
significant reliability/performance improvements that the hardware could
provide.

Is this model so alien to the existing Kernel that the best approach is to
peel off a kernel tarball and create a new kernel, to be maintained in
isolation forever? Or would this work fit into planned/expected kernel work
dealing with protection models, interrupts, trap handling and the like? What
about partitioning the kernel into disjoint (and mutually protected)
components like IP stack, password/security, FS etc?

We will not be beginning this port for six months or so - the compiler has
to come up first :-)  So this question is more to get some sense of the lay
of the land rather than any immediate help. We know that there is a lot of
know-how and strong opinions concentrated in the kernel development crew,
and we want to gain from that and also to contribute what is currently
budgeted as some 10 engineer-years of work upcoming to the general
improvement if it can be done. Alternatively we might be too wierd to be
worth bothering with for the group, and so we should do it on our own and
not try to fit with the "Linux way of doing things".

Comments please?

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/