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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no 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.213.68 with SMTP id nq4mr10316659pbc.2.1329602025640; Sat, 18 Feb 2012 13:53:45 -0800 (PST) Path: wr5ni41161pbc.0!nntp.google.com!news2.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Arbitrary Sandbox Date: Sat, 18 Feb 2012 23:53:44 +0200 Organization: Tidorum Ltd Message-ID: <9qakv8Fn6oU1@mid.individual.net> References: <9qac7gFk0nU1@mid.individual.net> Mime-Version: 1.0 X-Trace: individual.net AYIs8BYNwVm2r+UmTt2DmwDxc3d2DzwOaoR4WTBFQhBAc9Z/5o Cancel-Lock: sha1:w4Ev7HJ/zJORapiTPj0FU+CboyY= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-02-18T23:53:44+02:00 List-Id: On 12-02-18 22:06 , tmoran@acm.org wrote: >> I seem to remember that the Burroughs mainframe computers had rather >> poor hardware-level protections. A buggy or malicious compiler could >> generate code that had harmful effects that were not restricted to the >> user running the code, if I remember correctly. A consequence was that >> an ordinary user was not allowed to create a compiler; special >> privileges were required to label a program as a "compiler" and thus let >> it generate executable code. > > The Burroughs philosophy was to design hardware and software together, > which included doing different kinds of checks in different, appropriate, > places. Right. I did not mean to be critical of Burroughs; it is one example of dividing checks between SW and HW. Current systems have a different division, which is better in some respects -- illegal code has limited effects, so anyone can develop and experiment with compilers -- but worse in other respects, such as less checks on pointer arithmetic. > Bad code could be prevented by a correct compiler, so an > arbitrary generator of bit streams couldn't call its output "executable > code". Indexing out of range couldn't be prevented by a compiler, so it > was checked at run time by hardware. And so forth. Yes. The ideal is that all illegalities are detected at some level. But today, in Ada and other languages, we have cases of erroneous execution, undefined behaviour, and so on, that are not detected at all, and simply lead to wrong results or weird crashes. I wish that hardware could detect more of them. > In five years supporting a B5500 at U of Wisconsin, I never saw a core > dump caused by a compiler generating bad code. (Unfortunately, Burroughs > added to their Algol "stream procedures" which were unchecked string > operations - those were the source of most problems.) No disagreement from me. I liked the Burroughs systems at the U of Helsinki, and I don't remember hearing of any problems. (I was an ordinary and minor user, not a sysadmin.) But perhaps there would have been more problems if I and other students in the compiler-implementation course had been allowed to run our experimental compilers as real compilers, not just as MIXAL generators :-) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .