Spectre & Meltdown

[Chuck Guzis]

On 1/13/2018 3:24 PM, Fred Cisin via cctalk wrote:
> (I'm unaware of any punch-card attacks, but trojans were possible when
> people used prior subroutines).
Depends on what you mean "attack".  CDC 6000 SCOPE had two PP programs
(which could be invoked via user control card).

One was "RPV"--reprieve job.   The purpose was to recover control after
a program error so that appropriate cleanup by the user could be
performed.   It was effective for *any* error, including operator
killing the job.

The other was "RSJ", reschedule job.  Usually, this was used when a
device or resource wasn't available--basically, it would put a job back
into the input queue and terminate the caller.

Unless, of course, the caller had included an RPV call also, in which
case it was something like the sorcerer's apprentice--you'd get *two*
copies of the job, which would then spawn 4 more copies, etc.  Operator
drop just exacerbated the situation, and eventually, the input queue
would be full of the malicious job and all available PPUs would be
allocated to doing nothing but RSJs and RPVs.

The only way out of the situation was to deadstart the system without
recovering the input queue.

After a couple of incidents of this, a memo came down from on high
saying that anyone attempting this gambit would be subject to discipline
and/or termination.   I think someone also did an EDITLIB and renamed
both RPV and RSJ and kept the new names on a "need to know" basis.

--------------

Another gambit I recall made use of a new I/O call in SCOPE 3.4, called
"Read List String".  Basically, the point of it was to streamline loader
(linkage editor) operation by presenting CIO and, by extension, the disk
stack processor overlay, 1SP with a list of disk addresses and lengths
to be read.   1SP would dutifully go through the list, advancing its
list pointer (so that the caller could keep track of progress).  It was
very effective and bypassed a lot of ancillary PP code.

Some enterprising fellow wondered what might happen, if his CP program
kept track of the READLS progress and kept backing the pointer up every
time it advanced.   Since 1SP attempted to complete an entire I/O
request before terminating, it never terminated and kept the disk busy
basically forever.

That one was fixed by checking the user's control point area for the
"DROP" flag--something that should have been done from the outset.

-----------------------

All of this reminds me of a trick that I witnessed on a Model 40 running
DOS/360.   Some guy wrote a chained CCW set with a TIC back to the
beginning of the list of CCBs that rang the bell on the 1052 operator's
console and locked the keyboard.   The din panicked at least one
operator who pulled the "Emergency Stop" big red button.

But then DOS/360 was easy to fool--it wasn't even much of a challenge.

Good times...

--Chuck