Spectre & Meltdown

On 1/13/2018 3:24 PM, Fred Cisin via cctalk wrote: 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