Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!uhccux!munnari.oz.au!bruce!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.arch Subject: Randomised Instruction Set Computer Keywords: viruses Message-ID: <3131@goanna.cs.rmit.oz.au> Date: 2 Jun 90 09:08:38 GMT Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 52 This is an obviously crazy idea, but is it crazy enough to work? The problem with viruses that attach to ordinary programs is that (a) the virus has the power to write into code files (b) the virus can determine in advance _what_ to write 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. The trouble with that was that once you managed to jemmy 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.) Obviously, it would be possible to strengthen this system. But even then, things like the sendmail bug could still be exploited. The crazy idea, then, is to ensure that a virus can't be sure of knowing what bit pattern to generate in order to realise its effect. What if we tried to make a computer hard to effect by giving it a randomised instruction set? Suppose you had a RISC machine with, say, 64 genuine instructions encoded in a 7 bit field, the remaining 64 being mapped to "illegal opcode" and that the machine had an on-chip memory of 128x7 bits, so that instruction decoding went through this memory? Suppose that there were a system call "trust such&such a code file" which generated two random permutations: - one affecting the opcodes in instructions - one affecting the order of bytes within a code page then when a program was to be run the decoding matrix would be set from the opcode permutation and whenever a code page was fetched from the code file it would be unscrambled using the byte order permutation (but the opcodes would _not_ be unscrambled). The "trust this code file" system call would presumably insert checksums and such into the file as well. Obviously, this device would slow a chip down. Existing on-chip caches are bigger, but they're not in quite the same path. Even slowing down by a factor of 2 might be worth while for battlefield systems. The problem then comes back at the level of interpretive languages, alas. Anyway, is this idea crazy enough to work? _Can_ a virus spread when each program appears to use a different instruction set? -- "A 7th class of programs, correct in every way, is believed to exist by a few computer scientists. However, no example could be found to include here."