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,LOTS_OF_MONEY 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.231.202 with SMTP id ti10mr16487348pbc.5.1329794993767; Mon, 20 Feb 2012 19:29:53 -0800 (PST) MIME-Version: 1.0 Path: wr5ni49791pbc.0!nntp.google.com!news1.google.com!eweka.nl!lightspeed.eweka.nl!feeder.erje.net!news.albasani.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: Arbitrary Sandbox Date: Tue, 21 Feb 2012 03:29:49 +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-21T03:29:49+00:00 List-Id: > -- a design that requires compilers to have special privileges > is a bad idea, whether you call that a "mode" or a "per-file privilege > attribute" or whatever. Catching/preventing bugs earlier rather than later is a good idea. If the regular compiler doesn't generate I/O instructions or bad instruction sequences, then the hardware doesn't need a "user" mode to detect those at run-time. You've pushed back the detection so it's done essentially at the time you give a particular programmer the security status of being able to use the fancy, I/O Op generating, systems programmer compiler. Modern computers are designed to run as executable code any sequence of bits that anyone, including fools and knaves, gives them. That means you have to delay protection till run time, with things like user/kernel mode. > >... I imagine the Burroughs compiler writers lived under the > > same situation, except that they could work in the daytime on their > > own "development" machine. > The ones I was talking about _shared_ a machine. So rebooting it > disrupted the entire project, not just one programmer. I think we're talking different eras of computing here. In the mid '60s very few people had their own development machines - they were million dollar mainframes (with only a few hundred kilobytes of core) and were shared. At that time very few machines ran multiprogramming - they were in effect rebooted between each batch job. Things like memory protection (eg, Burroughs' "descriptor") were new and rare so there was no alternative to rebooting when a program crashed hard. OTOH, a reboot took seconds, not minutes.