13 Jan
2018
13 Jan
'18
1:08 p.m.
I wrote about Spectre and Meltdown recently: INTEL took its time to inform
the world! Did it inform the world back in earlier days about potential
flaws? Not to blame INTEL only: What about Zilog, etc.? Or did pre-Internet
era protect us computer-classic users? What about running emulation
software as I?ve been doing with ADAM?
Happy computing!
Murray J
13 Jan
13 Jan
1:13 p.m.
I wrote about Spectre and Meltdown recently: INTEL
took its time to
inform the world! Did it inform the world back in earlier days about
potential flaws? Not to blame INTEL only: What about Zilog, etc.? Or
Yes, of course it did. The famous Pentium FDIV bug comes immediately to mind. Of course
pre-internet days and everything being online all the time security was a whole lot
easier. If you could keep someone out of the building your data was secure. Now a day all
it takes is a bad JS on a site to compromise you...
-Ali
1:22 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Murray
McCullough via cctalk
Sent: 13 January 2018 18:09
To: cctalk <cctalk at classiccmp.org>
Subject: Spectre & Meltdown
I wrote about Spectre and Meltdown recently: INTEL took its time to inform
the world! Did it inform the world back in earlier days about potential flaws?
Not to blame INTEL only: What about Zilog, etc.? Or did pre-Internet era
protect us computer-classic users? What about running emulation software
as I?ve been doing with ADAM?
It delayed telling the world to allow time for OS providers to apply fixes. This is now
standard and the delays are defined...
http://abcnews.go.com/Technology/wireStory/intel-fixing-security-vulnerabil…
but it looks like in this case it leaked early. Similar bugs affect ARM, AMD and PowerPC
but nothing from them either. IBM won't tell the world (it will tell customers, but I
am not a customer) if and how it affects Z.
Happy computing!
Murray J
Dave
1:36 p.m.
On Jan 13, 2018, at 1:22 PM, Dave Wade via cctalk
<cctalk at classiccmp.org> wrote:
...
It delayed telling the world to allow time for OS providers to apply fixes. This is now
standard and the delays are defined...
http://abcnews.go.com/Technology/wireStory/intel-fixing-security-vulnerabil…
but it looks like in this case it leaked early. Similar bugs affect ARM, AMD and PowerPC
but nothing from them either. IBM won't tell the world (it will tell customers, but I
am not a customer) if and how it affects Z.
There are two bugs that are largely unrelated other than the fact they both start from
speculative execution. One is "Meltdown" which is specific to Intel as far as
is known. The other is "Spectre" which is a pretty much unavoidable side effect
of the existence of speculative execution and appears to apply to multiple architectures.
There may be variations; I assume some designs have much shorter speculation pipelines
than others and if so would be less affected.
Meltdown has a software workaround (it could also be fixed in future chips by changing how
speculative loads work, to match what other companies did). Spectre needs software fixes,
possibly along with microcode changes (for machines that have such a thing). You're
likely to hear more when the fixes are available; it would not make sense to have much
discussion before then for the reason you mentioned at the top.
paul
3:56 p.m.
On Jan 13, 2018 11:36 AM, "Paul Koning via cctalk" <cctalk at
classiccmp.org>
wrote:
On Jan 13, 2018, at 1:22 PM, Dave Wade via cctalk
<cctalk at classiccmp.org>
wrote:
...
It delayed telling the world to allow time for OS providers to apply
fixes. This is
now standard and the delays are defined...
fixing-security-vulnerability-chips-52122993
but it looks like in this case it leaked early. Similar bugs affect ARM,
AMD and
PowerPC but nothing from them either. IBM won't tell the world (it
will tell customers, but I am not a customer) if and how it affects Z.
There are two bugs that are largely unrelated other than the fact they both
start from speculative execution. One is "Meltdown" which is specific to
Intel as far as is known. The other is "Spectre" which is a pretty much
unavoidable side effect of the existence of speculative execution and
appears to apply to multiple architectures. There may be variations; I
assume some designs have much shorter speculation pipelines than others and
if so would be less affected.
Meltdown has a software workaround (it could also be fixed in future chips
by changing how speculative loads work, to match what other companies
did).
Sorta. A 10% performance hit and tthe workaround is extensive. So it's
forcing everyone to eat a shit sandwich to work around it.
Spectre needs software fixes, possibly along with microcode changes (for
machines that have such a thing). You're likely to hear more when the
fixes are available; it would not make sense to have much discussion before
then for the reason you mentioned at the top.
Spectre for Intel requires microcode changes and OS level changes to cope,
and changes to the compiler for retpoline support. The os guys need to talk
about their piece a lot, so it needs disclosure as well... it's a smaller
shit sandwich in terms of performance hit...
Warner
3:51 p.m.
On Jan 13, 2018 11:22 AM, "Dave Wade via cctalk" <cctalk at
classiccmp.org>
wrote:
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Murray
McCullough via cctalk
Sent: 13 January 2018 18:09
To: cctalk <cctalk at classiccmp.org>
Subject: Spectre & Meltdown
I wrote about Spectre and Meltdown recently: INTEL took its time to inform
the world! Did it inform the world back in earlier days about potential
flaws?
Not to blame INTEL only: What about Zilog, etc.? Or
did pre-Internet era
protect us computer-classic users? What about running emulation software
as I?ve been doing with ADAM?
It delayed telling the world to allow time for OS providers to apply fixes.
This is now standard and the delays are defined...
http://abcnews.go.com/Technology/wireStory/intel-
fixing-security-vulnerability-chips-52122993
Linux, Windows and Mac got notified early November. FreeBSD just before
Christmas with no time to cope. All other BSDs and OpenSolaris found out on
release :(.
But this embargo was super long. Intel found out in June...
Warner
but it looks like in this case it leaked early. Similar bugs affect ARM,
AMD and PowerPC but nothing from them either. IBM won't tell the world (it
will tell customers, but I am not a customer) if and how it affects Z.
Happy computing!
Murray J
Dave
1:31 p.m.
On Jan 13, 2018, at 1:08 PM, Murray McCullough via
cctalk <cctalk at classiccmp.org> wrote:
I wrote about Spectre and Meltdown recently: INTEL took its time to inform
the world!
Of course, and for good reason. The current practice has been carefully crafted by the
consensus of security vulnerability workers. That is: when a vulnerability is discovered,
the responsible party is notified confidentially and given a reasonable amount of time to
produce a fix before the issue is announced publicly. There's a big incentive for
that response to happen and typically it does. If the issue is ignored, the announcement
happens anyway along with public shaming of the part who didn't bother to respond.
With this approach, a fix can often be released concurrently with the disclosure of the
issue, which dramatically reduces the oppportunity for criminals to take advantage of the
problem. This isn't a case of being nice to Intel; it's an attempt to benefit
Intel's customers.
If you read the Meltdown and Spectre papers (by the researchers who discovered the
problem, not the news rags reporting on it) you'll see this policy mentioned in
passing.
paul
6:24 p.m.
On Sat, 13 Jan 2018, Murray McCullough via cctalk wrote:
I wrote about Spectre and Meltdown recently: INTEL
took its time to inform
the world! Did it inform the world back in earlier days about potential
flaws? Not to blame INTEL only: What about Zilog, etc.? Or did pre-Internet
era protect us computer-classic users? What about running emulation
software as I???ve been doing with ADAM?
Happy computing!
Few emulations are exact enough to duplicate all bugs.
Q: Should an emulator do an exact imitation, or should it work the way
that it is s'posed to? (behavior? or specs?)
Pre-internet protected against most web based malware. But, there are
instances of virus software ever since people exchanged files and disks.
(I'm unaware of any punch-card attacks, but trojans were possible when
people used prior subroutines)
Most prevalent were boot-sector virus attacks and executable file virus
attacks. As software became too eager to help provide dancing kangaroos
and yodelling jellyfish, harmful macros in "productivity software" macro
capabilities also started to surface.
Internet made it much easier to acquire a trojan that would mess you up.
Although reduction in sneaker-net has virtually eliminated boot-sector
spread.
How fast SHOULD the public response be?
If they become aware of that kind of flaw, and can delay public knowledge
until they have patches, they significantly reduce the risk of actual
instances of malware using the exploits.
Note: AFAIK, no examples of actual use of Spectre nor Meltdown have yet
been encountered.
If Microsoft had been in less of a rush, would they still have shipped
patches that gave a BSOD with AMD processors?
After public announcement, there ARE people actively working on developing
malware using it.
Similarly, after the Michelangelo Virus media panic, one of the variants
later encountered was a fairly obvious "wannabe" consisting of
"Stoned"
patched to behave like the publicized Michelangelo behavior. The
"thousands or millions of computers will be destroyed" was bogus.
(BTW, the name "Michelangelo" was based on looking at a calendar to see
what was special about March 6. If McAfee had had a Texas calendar,
instead of a KQED (PBS) one, then it would have been named "Alamo")
Intel made some mistakes in handling the FDIV bug. First, they made the
assumption that the bug would be amazingly rarely encountered due to their
calculations of probability of randomly hitting "winning" combinations of
numerator and denominator, but failed to allow for any of the "winning"
numbers happening to be more commonly used.
THEN, they offered replacements to anybody who could PROVE that it
actually affected their use of the machine. A more appropriate response
would have been, "We WILL replace all affected processors! BUT, there
aren't enough in stock right now to handle all immediately, so we will
START by replacing those for all who can prove that they are affected, and
then get to all others as we can manufacture more suitable replacements."
(Perhaps the majority of people would have already replaced their machine
before their turn came around! What is it? "a new machine every 18
months"?)
Many of the general public had been led to believe that it would produce
completely WRONG results, rather than the LOW ORDER bits of the mantissa
being incorrect. No, it was not capable of "causing the wrong amount of
sales tax to be charged!"
8:35 p.m.
> Although reduction in sneaker-net has virtually
eliminated boot-sector
> spread.
On Sun, 14 Jan 2018, Tapley, Mark wrote:
I never made that connection before! Glad you toed me.
There had already been some reduction. The first PCs with a hard disk
would always attempt to boot from floppy first. Once it was possible to
rearrange the boot sequence to try the hard disk first, we had a
substantial reduction in boot sector virus incidents.
MOST boot sector virus infections on hard disks could be trivially solved
by the [undocumented at that time] /MBR option of FDISK.COM
The "Alameda" Virus was first discovered [and thoroughly analyzed] in our
("Merritt College") lab.
(We had a good idea of who might have been the author)
One of the student workers at our sister college, "College Of Alameda",
who was brother of a guy who wrote a book on the subject, asked nicely for
naming rights.
A few years later, the administration informed me that they had waived the
computer literacy requirement for a student transferring to Yale. A few
months later, Yale "discovered" it, and named it "Yale Virus".
7:38 p.m.
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)
When I was using cards with our campus 360/50 MVT
system and you could
submit probably anything, a friend in EE (we were squatters in the CS
area) had worked a summer job and had a really nice program they'd ran
which now days would be called a text based football game.
All one had to do was stick a job card in front of a deck, and we
submitted our own? jobs via a 2501 which was in the hall outside the
computer room.? Users loaded and fed their own cards, so there was no
restriction on when the job ran.
He decided to get a listing and figured if he stuck a job card in front
if it and a couple of DD statements the job would blow up and he'd get a
listing.
All of the I/O was with WTO and WTOR.? The operator that afternoon
quickly discovered that WTOs were not disabled by the sysgen, and worse,
there was only the single 1050 console, so the only way to get thru the
job and get other things running was to play a game.
And even worse, if he took too long, a fun feature of MVT and not
corrected in MVS was if a console channel went unavailable for too long,
the system would crash.? Luckily the game would print out a line, and a
blob of console messages would come out then ask for another move.
Took 10 minutes to lose a game.
The system administrators regenerated the system to add privilege and
authorization to jobs using WTOR which they'd missed.
We found other fun holes like that in MVT.
When we were put over to a VS/1 system via TSO terminals, a console
message monitor, and a password snarfing program was developed and ran
quite a lot via remote access (system and terminals were in different
cities).
That was all OS of course, and some of it was something that could be
disabled by sysgen options.? The password snarfing was not.
thanks
Jim
8:40 p.m.
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
9:37 p.m.
On 01/13/2018 05:40 PM, Chuck Guzis via cctalk wrote:
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.
Typo--not "CCB" but "CCW".
--Chuck
14 Jan
14 Jan
1:38 p.m.
On 01/13/2018 06:38 PM, jim stephens via cctalk wrote:
And even worse, if he took too long, a fun feature of MVT
and not corrected in MVS was if a console channel went
unavailable for too long, the system would crash. Luckily
the game would print out a line, and a blob of console
messages would come out then ask for another move.
Took 10 minutes to lose a game.
The system administrators regenerated the system to add
privilege and authorization to jobs using WTOR which
they'd missed.
We found other fun holes like that in MVT.
Yup, OS/360 had a number of holes wide enough to let 5 ocean
liners through, abreast. My favorite was the stock
exception handler for the SPIE (specify program
interruption exit) allowed you to change a program from
problem state to supervisor state. Nobody ever thought
anybody would ever abuse such a thing.
Jon
16 Jan
16 Jan
7:27 p.m.
New subject: Malware history was: Spectre & Meltdown
Enjoying the virus/malware history as its always interesting to see what people thought.
Tricks, boredom, etc cause interesting results.
For punch cards i thought someone was going to mention punching all the holes and jamming
the reader. I'm not sure if thats real but heard some folks had to check their opcodes
or it could potentially lead to that or flimsy card integrity if not.?
Did anyone here ever see animal or other shared system malware? Animal was just a
nondestructive trojan (other than potential to take up disk space) but interesting that
someone would run a program that appeared unexpected in their home folder.
-------- Original message --------
(I'm unaware of any punch-card attacks, but trojans were possible when
people used prior subroutines)
7:41 p.m.
New subject: Malware history was: Spectre & Meltdown
On Tue, Jan 16, 2018 at 4:27 PM, Sam O'nella via cctalk <
cctalk at classiccmp.org> wrote:
Enjoying the virus/malware history as its always
interesting to see what
people thought. Tricks, boredom, etc cause interesting results.
For punch cards i thought someone was going to mention punching all the
holes and jamming the reader. I'm not sure if thats real but heard some
folks had to check their opcodes or it could potentially lead to that or
flimsy card integrity if not.
Did anyone here ever see animal or other shared system malware? Animal was
just a nondestructive trojan (other than potential to take up disk space)
but interesting that someone would run a program that appeared unexpected
in their home folder.
-------- Original message --------
(I'm unaware of any punch-card attacks, but trojans were possible when
people used prior subroutines)
For CDC 6000 SCOPE, the second card in the job deck was
'ACCOUNT,name,password' (or something like that; it was a long time ago).
In a corner of the keypunch room was a large card recycling bin right next
to a card sorter. One would set the card sorter to pull out cards that had
an 'A' in column one, and shovel cards out of the bin into card sorter and
end up with a tidy pile of user accounts and passwords, Or so I've heard.
-- Charles
11:31 p.m.
New subject: Malware history was: Spectre & Meltdown
This isn't malware, but back in 1962 when I was taking a college class
in assembly language programming for the IBM 709, my innocence led to
the following.
Of course, I had, on the typewriter, for my high school years, always
typed ' backspace . to get an exclamation point. I did this in a
comment in my first punched card submittal using an 026 keypunch. The
program was rejected, and I lost $0.25 from my lab fee.
So my first real computer program was a flaming failure. Had to wait
for the 029 to be emphatic in punching.
Dave
On 1/16/18 4:27 PM, Sam O'nella via cctalk wrote:
Enjoying the virus/malware history as its always
interesting to see what people thought. Tricks, boredom, etc cause interesting results.
For punch cards i thought someone was going to mention punching all the holes and jamming
the reader. I'm not sure if thats real but heard some folks had to check their opcodes
or it could potentially lead to that or flimsy card integrity if not.
Did anyone here ever see animal or other shared system malware? Animal was just a
nondestructive trojan (other than potential to take up disk space) but interesting that
someone would run a program that appeared unexpected in their home folder.
-------- Original message --------
(I'm unaware of any punch-card attacks, but trojans were possible when
people used prior subroutines)
17 Jan
17 Jan
2:03 a.m.
New subject: Malware history was: Spectre & Meltdown
On 1/16/18 4:27 PM, Sam O'nella via cctalk wrote:
Enjoying the virus/malware history as its always
interesting to see
what people thought. Tricks, boredom, etc cause interesting results.
For punch cards i thought someone was going to mention punching all
the holes and jamming the reader. I'm not sure if thats real but heard
some folks had to check their opcodes or it could potentially lead to
that or flimsy card integrity if not.
Did anyone here ever see animal or other shared system malware? Animal
was just a nondestructive trojan (other than potential to take up disk
space) but interesting that someone would run a program that appeared
unexpected in their home folder.
Cards that were mostly holes were called "lace cards". Not uncommon to
see one punched (and offset if the punch had the feature) to indicate
the start of a punched output file--usually showing the file name or job
ID in "see-thru" fashion.
High-speed punches generally could be very noisy when punching lace
cards (or column/row binary) and prone to errors as they heated up. I'm
thinking of the CDC 415 punch as an example, but the 1402 could put out
quite a racket as well.
Never tried duping a lace card on an 029 or 514. It doubtless would have
been noisy as well.
--Chuck
2412
days inactive
2416
days old
17 comments
13 participants
participants (13)
-
barythrin＠gmail.com -
c.murray.mccullough＠gmail.com -
cclist＠sydex.com -
cctalk＠ibm51xx.net -
charles.unix.pro＠gmail.com -
cisin＠xenosoft.com -
classiccmp＠earthlink.net -
dave.g4ugm＠gmail.com -
elson＠pico-systems.com -
imp＠bsdimp.com -
jwsmail＠jwsss.com -
mtapley＠swri.edu -
paulkoning＠comcast.net