Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: Context switching on RISC chips
Message-ID: <5482@bd.sei.cmu.edu>
Date: 3 Jan 90 13:55:26 GMT
References: <3167@iitmax.IIT.EDU> <28573@amdcad.AMD.COM> <52104@srcsip.UUCP>
Reply-To: firth@sei.cmu.edu (Robert Firth)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 33

In article <28573@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes:

>#  3) Saving/Restoring Live Registers Only (like your #2).  In systems
>#     where security (covert channels) is not an issue

In article <52104@srcsip.UUCP> shankar@src.honeywell.com (Subash Shankar) writes:

>Why does security affect things here?

Here's a simple example.  (Mnemonics have been changed to protect
the innocent.)

You get hold of the login processing code of the Mugwump IV multi-user
operating system.  That code reads an 8-character password, scrambles
it, and checks it.  It just so happens that, on exit from the code,
the clear password is still lying around in <R6,R7>.

You write a short program that does this

	loop
	   get myself time sliced
	   read <R6,R7>
	   write the value to a file
	end loop

Every so often, by pure chance, the OS scheduler will resume your
program immediately after executing the login process.  Every time
that happens, you will have captured a password.  The registers
<R6,R7> are the covert channel by means of which information leaks
from the login process to your program.  An OS that saved and restored
only live registers would not save and restore them, so leaving
the channel open.  (The registers aren't live because there is no
write to them anywhere in the program.)