From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,af0c6ea85f3ed92d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.136.40 with SMTP id px8mr10566489pbb.1.1329612451240; Sat, 18 Feb 2012 16:47:31 -0800 (PST) MIME-Version: 1.0 Path: wr5ni41644pbc.0!nntp.google.com!news2.google.com!eweka.nl!lightspeed.eweka.nl!feeder.erje.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: Arbitrary Sandbox Date: Sun, 19 Feb 2012 00:47:29 +0000 (UTC) Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: Lf0Nl3CcQzx+ocHx9cmuGg.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Tom's custom newsreader Date: 2012-02-19T00:47:29+00:00 List-Id: > I've never used a Burroughs machine, but it seems to me that a design > that requires compilers to run in a privileged mode is just wrong. > A goal is to avoid having too much code in privileged mode, and > compilers are complicated beasts. There was no "privileged mode" or "user mode". Files on disk had various security privileges, and one possibility was "this is a code file" while another possibility was "this is a compiler and it's allowed to create a file with 'code file' security". > I talked to some folks who wrote a compiler (I don't remember which > language, might have been Ada) for one of those machines, and they said > it was a nightmare, because when there's a bug, instead of the compiler > crashing, or the compiler-generated program crashing, the entire system > would crash. This was a multi-user system, so one minor mistake by one > member of the compiler team disrupts the work of the whole team. The B5500 came out in the early sixties. It was one of the first designed for multiprogramming and time sharing. It still was capable of "batch" operation, in which crashing the machine meant crashing your job, which was the only one on the machine. When we tested new OS changes at UW, we did it at night, after all the batch jobs were done and the time-sharing users were gone. If an OS change caused a crash, we rebooted. I imagine the Burroughs compiler writers lived under the same situation, except that they could work in the daytime on their own "development" machine. I suspect that's the way compiler writers work today, each with his own (rebootable) development machine Most OS changes did not causes crashes, just undesirable behavior. Most compiler bugs don't cause machine crashes, just program errors. Since the B5500 had segments with descriptors and hardware checked indexing, a bad program would more likely generate a fault ("exception") than crash the whole system. BTW, the only real problem we had with bad user programs was one grad student who had heard about "virtual memory" and wrote his program to use large arrays. Unfortunately he accessed them column-wise, while they were stored row-wise, so his program swapped horribly. In 1970 it would have taken a very smart compiler indeed to prevent that problem. We've spent the last half-century making computers faster, with modest, or sometimes negative, progress on preventing or catching software bugs, so the number of executed bugs/second must be orders of magnitude larger.