[XCSSA] Update on microkernels
xcssa@xcssa.org
xcssa@xcssa.org
Thu, 8 Mar 2007 03:07:56 -0600
--zbGR4y+acU1DwHSi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 30, 2007 at 03:04:10PM -0600, xcssa-admin@xcssa.org wrote:
> Interesting list of microkernel OS's at the bottom=20
> of the page.
>
> Sorry if this was already posted here already; I can't remember.
>=20
> http://www.cs.vu.nl/~ast/reliable-os/
http://web.archive.org/web/20030803060051/http://www.cs.arizona.edu/people/=
bridges/os/full.html
Note that the monolithic kernel design of Linux is starting to show
some signs of age. I first began to understand the problems when I
was experimenting with encrypted file systems, and so it is only
reasonable that now the first obvious signs of trouble in the FOSS
movement are with file system designs; the Linux port of ZFS and other
projects like it are looking to architectures like FUSE
(http://fuse.sourceforge.net/), which are in essence microkernel
designs. The main objection to microkernels was that they are
inefficient; each time you cross a protection domain (kernel to
userspace, ring 0 to ring 3, one page table to another, whatever) you
incur a performance penalty. However, end-user desktops are
increasingly inexpensive, fast, and single-user (human users;
obviously the notion of "users" as part of the security architecture
is increasingly, not decreasingly, valid), so I think I'm willing to
spend a bit of the CPU time ensuring robustness.
However, it seems like servers are increasingly multi-user, and
increasingly burdened with more and more tasks, and so I wonder where
this is going. For example, most SSL-secured sites don't secure their
entire site with SSL because this means 2-3x as many servers for the
same population. However, sites which don't do this have http pages
that end up linking to the "secure" part of the site (shopping cart
and checkout stuff), despite the fact that the unsecured pages could
easily have been malicious pages that pointed to a compromised yet
SSL-secured server, so one of the purposes of SSL (dealing with
impostor sites that spoof DNS, or phishing) is basically nullified as
a consequence. That really only leaves encryption of the network
traffic as a benefit. Since the data in the SSL cert (owner, etc.) is
only verified against the domain name registration records, one could
get the same benefit by registering a public key in DNS and avoiding
the whole SSL certificate process altogether.
Back to OSes, of particular interest is the exo-kernel, which puts all
the policy decisions (page replacement policy, etc.) outside the
kernel, where they can be easily modified and optimized and
custom-tuned. Nanokernels go one step further than a microkernel in
making the kernel smaller and smaller. And a recent "Best Paper"
award in Usenix shows how to properly sandbox x86 binary code with a
very small penalty (< 20%), meaning that one can now consider
uploading user code into the kernel and safely executing it there.
--=20
Good code works. Great code can't fail. -><-
<URL:http://www.subspacefield.org/~travis/>
For a good time on my UBE blacklist, email john@subspacefield.org.
--zbGR4y+acU1DwHSi
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (OpenBSD)
iQIVAwUBRe/Sa2QVZZEDJt9HAQJdrg/8CUMFHvLq6C0D+7jAwuVgwqSWLRm+907B
M981vLFQRmHdOFmY0dJZYLXF5Xx7PIi2NhIGRhjeurZiotShIob6ch3Z2+eOl8X/
sOe2ybTcsi8G0cr8wiwr8ZT6rFXfTw7l7RhynamLYCSTShPVkMSBQs6so08e4sAa
yRBHCe3BEeCxxuQu6WokWD7hjyVPaMmZnNKg2Cx8UXux1lj3dkgRcVJ3mv/B4p1/
7M3PaLjdlyjwNIiLLVubN0wrSmGtNwTZbLqcSNWoJbJmjXecPDZ0WkH7VWnIbEXp
Rym4L0Rx9WObKaj8S9lb1XfhG9YqMv9DJxLU2X2mq7QHypAMYBFHk02FJP7Tm5TZ
KhJeMS2NK5mgTlMyT07ONI0T1zgQksFU5CVmXlH1eOZkL52Lmh7hB4rLalrVOIEk
uN//8jUl+q0E9jL9/B36gW+qSQtpxZIR3XAb0Jz2iV97Bh318DnyMquFKCbEs+ma
9DVKR9jCUmFGOpf9oehNNKDNPThLOArUy+S80DoRa0Jwmca/UQEoN9ynTUIrl3HM
P/TjtxSe7jDRUStraBX1usesu941qdqjrzDiWhOYotnfOcKdwcdGm6B2HAEYMsBF
VJ2m0iQv1MxNFvgNJPCxRNRBRvscs7uFfvZ8SFifWahHKHzql6a/tj2WmEwNwJGq
7fkIA9gwrB4=
=nLJC
-----END PGP SIGNATURE-----
--zbGR4y+acU1DwHSi--