Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ames!haven!udel!burdvax!barry
From: barry@PRC.Unisys.COM (Barry Traylor)
Newsgroups: comp.arch
Subject: Re: Randomised Instruction Set Computer
Summary: The B6700 lives!
Keywords: viruses
Message-ID: <14060@burdvax.PRC.Unisys.COM>
Date: 7 Jun 90 04:30:37 GMT
References: <3131@goanna.cs.rmit.oz.au>
Followup-To: not necessary, really
Organization: Unisys Corporation, Paoli Research Center; Paoli, PA
Lines: 62

In article <3131@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> ...
>The Burroughs B6700 MCP distinguished between object code files and
>ordinary files.  A program could not create an object code file unless
>it had a special "I'm a compiler" privilege, and a program could only
>acquire that privilege when the operator at a console typed a special
>command.  

I can't thank-you enough for mentioning this.  The B6700 lives on as the
Unisys "A Series".

>The trouble with that was that once you managed to jemmy (sic) that
>lock the whole system was wide open.  Also, although I never tried this,
>you _could_ restore an object file from a backup tape, and there would
>have been no great difficulty in forging backup tapes, so it seems that
>it might have been possible to create object programs by writing "raw"
>tapes and then restoring from them.  (You couldn't forge a _compiler_
>this way, as compiler privilege was _not_ restored.)

Both of these require breaking PHYSICAL security.  Some significant work
has been done on these systems in the area of security.  Users may set up
their system in such a way that very special privilege is required to
import "unknown" code files or change a valid code file into a compiler.

BTW, part of our security has always seemed to rely on the relative
obscurity of our systems, although they have been strengthened to not rely
on this anymore ;->.

>Obviously, it would be possible to strengthen this system.

This has been done.  One thing you don't mention is that there is no way to
modify the in-core image of an executing code file, i.e. any modifications
to the address space cannot affect the in-core code.  I believe this is one
of the methods used by R. Morris (sp?), Jr.  

>But even then, things like the sendmail bug could still be exploited.

I don't think so, unless the perpetrater has broken fundamental physical
security or the security administrator is a spy for IBM (8-)=  (seriously,
I'm just kidding).

>...
>The "trust this code file" system call would presumably insert checksums
>and such into the file as well.

How is this any more secure than the A Series method?  It still requires
adequate security in the operating system.

>...
>The problem then comes back at the level of interpretive languages, alas.

Alas.

>
>Anyway, is this idea crazy enough to work?  _Can_ a virus spread when each
>program appears to use a different instruction set?

For both questions:  uh... I don't think so (my personal opinion).

Barry Traylor
Unisys Large A Series Engineering (love those mainframes!)
barry@prc.unisys.com