From owner-freebsd-current Thu Aug 6 15:02:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA12066 for freebsd-current-outgoing; Thu, 6 Aug 1998 14:37:18 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA11857 for ; Thu, 6 Aug 1998 14:36:32 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA06591; Thu, 6 Aug 1998 14:36:09 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd006564; Thu Aug 6 14:36:04 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id OAA24396; Thu, 6 Aug 1998 14:36:00 -0700 (MST) From: Terry Lambert Message-Id: <199808062136.OAA24396@usr07.primenet.com> Subject: Re: Spin-type OS issues, was: Re: Heads up on LFS To: reilly@zeta.org.au (Andrew Reilly) Date: Thu, 6 Aug 1998 21:36:00 +0000 (GMT) Cc: tlambert@primenet.com, tom@uniserve.com, current@FreeBSD.ORG In-Reply-To: <19980806090948.6680.qmail@gurney.reilly.home> from "Andrew Reilly" at Aug 6, 98 07:09:48 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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