Date: Thu, 6 Aug 1998 21:36:00 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: reilly@zeta.org.au (Andrew Reilly) Cc: tlambert@primenet.com, tom@uniserve.com, current@FreeBSD.ORG Subject: Re: Spin-type OS issues, was: Re: Heads up on LFS Message-ID: <199808062136.OAA24396@usr07.primenet.com> In-Reply-To: <19980806090948.6680.qmail@gurney.reilly.home> from "Andrew Reilly" at Aug 6, 98 07:09:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I just thought that I would point out that I thought the > interesting thing about Spin was not that it was written in Modula-3, > but rather that the designers were trying to avoid the overhead of > process-to-kernel virtual address translation by keeping both the > kernel, the extensions, and the user processes in the one address > space. (Yes, just like MacOS and Win3.1...) > > It seemed to me that they were trying to do this _safely_ by pushing > the checks that prevent processes from diddling with data that didn't > belong to them into the system compiler, resolved at compile time, > rather than using the more traditional approach of physically > segregating the address spaces. A more clever approach than this is the Chorus approach, which tends to limit protection domain crossing. Another clever approach that is becoming less useful as time goes on, and which is insufficient for security reasons is statistical protection in a very large address space. This works by making it a 1 in 2^32 chance (for a 32 bit allocation space within a 64 bit address space) for you to get a valid page at random. Thus there is no need to cross protection domains. This approach fails in the case of intentional acts of sabotage (ie: a determined attack, which is not a possible failure mode in normal operation). Another approach that is rather clever, but which requires protection domains is encapsulation, either via Capabilites (as in EROS) or via process encapsulation (as in Flux). 8-). I rather like the statistical protection model. You could pretty much represent all of the RAM on the Internet today as a 96 bit address, with a minimally 1 in 32 bit chance of a protection violation. This is a rather nifty idea... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808062136.OAA24396>