> But there are privilege switches.
Of course, they are unavoidable. However, they are as fast as the one
needed to make kernel syscalls.
=20
> Let me get the gist of the idea.
> To accelerate UML, and wine type applications:
> 1) setup segments with restricted limits, so their children cannot
> write into their supervisor process even though they share a mm.
> 2) load a special system call table that switches processor modes
> when any system call is activated.
>=20
> Unless I am mistaken all of the above can be accomplished without
> using the cpus multiple rings of privilege. Which would allow nesting
> only limited by the address space reduction of each task.
You also need:
3) Prevent less privileged subtasks from loading segments belonging to
more privileged ones
This can be done in hardware using the x86 privilege rings, at the
cost of limitations on the number of subtasks and the inability to have
protected pairs of subtasks where none is more privileged than the other.
Of course it is also possible to do this in the kernel, or in a
privileged user-mode task using LDT/TLS system calls, by modifying
descriptor tables on interprivilege jumps but this is obviously
significantly slower.
Anyway hardware-based and kernel-based privilege separation can
perfectly coexist.
--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE9vDw5djkty3ft5+cRAl1AAJ9363B25LcAlmcMTHlx6ZIB7QEUPACeOGd7
KtNK6C9/irGP/inOc3K/ZYA=
=nvjO
-----END PGP SIGNATURE-----
--C7zPtVaVf+AK4Oqc--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/