17 Sep
2019
17 Sep
'19
6:55 a.m.
"Spectre" is one of two notorious bugs of modern CPUs involving speculative
execution. I rather doubt that VAX is affected by this but I suspect others here have a
lot more knowledge.
paul
Begin forwarded message:
From: coypu at sdf.org
Subject: VAX + Spectre
Date: September 17, 2019 at 5:32:42 AM EDT
To: port-vax at netbsd.org
So, this is a bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
GCC would like to know if VAX needs Spectre-related work.
Are any of the VAXes ever made capable of speculative execution? the
first tech for doing it was in 1967, so not entirely far-fetched.
17 Sep
17 Sep
7:47 a.m.
New subject: [Simh] VAX + Spectre
It might be worth asking on comp.os.vms as well, it?s one of the few USENET groups that
seems to still be active.
Zane
On Sep 17, 2019, at 6:55 AM, Paul Koning
<paulkoning at comcast.net> wrote:
"Spectre" is one of two notorious bugs of modern CPUs involving speculative
execution. I rather doubt that VAX is affected by this but I suspect others here have a
lot more knowledge.
paul
Begin forwarded message:
From: coypu at sdf.org <mailto:coypu at sdf.org>
Subject: VAX + Spectre
Date: September 17, 2019 at 5:32:42 AM EDT
To: port-vax at netbsd.org <mailto:port-vax at netbsd.org>
So, this is a bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811>
GCC would like to know if VAX needs Spectre-related work.
Are any of the VAXes ever made capable of speculative execution? the
first tech for doing it was in 1967, so not entirely far-fetched.
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh 
8:06 a.m.
"Spectre" is one of two notorious bugs of
modern CPUs involving speculative
execution. I rather doubt that VAX is affected by this but I suspect others
here have a lot more knowledge.
However, even speculative execution isn't enough to make Spectre possible or
feasible. For example, the PowerPC G3 and 7400 CPUs speculatively execute,
but because indirect branches can only be done on special-purpose registers
and the G3 and 7400 halt speculative execution until the SPR is loaded with
the destination address, this means they won't speculatively execute after
any indirect branch in code and makes them resistant to the currently known
variants of Spectre.
Given how weird the VAX can be in some respects, I wouldn't be surprised if
similar idiosyncratic behaviours exist that confound such attacks similarly.
http://tenfourfox.blogspot.com/2018/01/actual-field-testing-of-spectre-on.h…
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- When you're in it up to your ears, keep your mouth shut. -------------------
8:42 a.m.
New subject: [Simh] Fwd: VAX + Spectre
Paul - be careful. All CPU's post the IBM AGS that used branch prediction
are suspect. Russ Robelen (who was the 360/50 lead, worked on 360/90 and
lead AGS) has the speculative executing patent. I tweaked him when it all
came out and said - look at what you did.
What Russ and team are great ideas and we all have used them since they
first published about it. And the fact is that it took 40 years before
someone even proposed that it was an issue and could become security
exploit (by some folks in German at a security conference) and it Google 18
months to reduce it to practice.
?
On Tue, Sep 17, 2019 at 9:55 AM Paul Koning <paulkoning at comcast.net> wrote:
"Spectre" is one of two notorious bugs of
modern CPUs involving
speculative execution. I rather doubt that VAX is affected by this but I
suspect others here have a lot more knowledge.
paul
Begin forwarded message:
*From: *coypu at sdf.org
*Subject: **VAX + Spectre*
*Date: *September 17, 2019 at 5:32:42 AM EDT
*To: *port-vax at netbsd.org
So, this is a bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
GCC would like to know if VAX needs Spectre-related work.
Are any of the VAXes ever made capable of speculative execution? the
first tech for doing it was in 1967, so not entirely far-fetched.
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
10:40 a.m.
New subject: [Simh] Fwd: VAX + Spectre
Yes, I understand that a number of ISAs are vulnerable. The original paper by Kocher
clearly mentions both x86 and ARM.
The reason I forwwarded the question is that I'm not aware enough of all the VAX
variants to answer whether there are any VAXen with speculative execution. If no, then
we're done, the answer is easy. (That was the case when the question was asked for
PDP11s.) But if yes, then it becomes necessary to read the paper carefully to see if any
of the prerequisites are implemented in some VAX, and if yes, what the fix might look
like.
I'm reasonably comfortable assuming that the somewhat-related "Meltdown"
vulnerability doesn't show up in VAX, because that issue requires a designer who'd
implement page access checking in a way I would not expect a DEC engineer to do.
paul
On Sep 17, 2019, at 11:42 AM, Clem Cole <clemc at
ccc.com> wrote:
Paul - be careful. All CPU's post the IBM AGS that used branch prediction are
suspect. Russ Robelen (who was the 360/50 lead, worked on 360/90 and lead AGS) has the
speculative executing patent. I tweaked him when it all came out and said - look at what
you did.
What Russ and team are great ideas and we all have used them since they first published
about it. And the fact is that it took 40 years before someone even proposed that it was
an issue and could become security exploit (by some folks in German at a security
conference) and it Google 18 months to reduce it to practice.
?
On Tue, Sep 17, 2019 at 9:55 AM Paul Koning <paulkoning at comcast.net> wrote:
"Spectre" is one of two notorious bugs of modern CPUs involving speculative
execution. I rather doubt that VAX is affected by this but I suspect others here have a
lot more knowledge.
paul
Begin forwarded message:
From: coypu at sdf.org
Subject: VAX + Spectre
Date: September 17, 2019 at 5:32:42 AM EDT
To: port-vax at netbsd.org
So, this is a bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
GCC would like to know if VAX needs Spectre-related work.
Are any of the VAXes ever made capable of speculative execution? the
first tech for doing it was in 1967, so not entirely far-fetched.
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh 
10:49 a.m.
New subject: [Simh] Fwd: VAX + Spectre
On Tue, Sep 17, 2019, 6:40 PM Paul Koning via cctalk <cctalk at classiccmp.org>
wrote:
Yes, I understand that a number of ISAs are
vulnerable. The original
paper by Kocher clearly mentions both x86 and ARM.
The reason I forwwarded the question is that I'm not aware enough of all
the VAX variants to answer whether there are any VAXen with speculative
execution. If no, then we're done, the answer is easy. (That was the case
when the question was asked for PDP11s.) But if yes, then it becomes
necessary to read the paper carefully to see if any of the prerequisites
are implemented in some VAX, and if yes, what the fix might look like.
Early Vaxen are immune. Latter day ones require careful analysis since they
have some out of order things. I'm not expert enough to know for sure,
though, and the latter day stuff is half remembered from marketing material
for one of the final generations of Vax big iron before Alpha drove that
away... But I don't think many of these old beasts are still running even
if my half remembered stuff is right...
I'm reasonably comfortable assuming that the somewhat-related "Meltdown"
vulnerability doesn't show up in VAX, because that
issue requires a
designer who'd implement page access checking in a way I would not expect a
DEC engineer to do.
I'm agree.
Warner
paul
On Sep 17, 2019, at 11:42 AM, Clem Cole <clemc
at ccc.com> wrote:
Paul - be careful. All CPU's post the IBM AGS that used branch
prediction are
suspect. Russ Robelen (who was the 360/50 lead, worked on
360/90 and lead AGS) has the speculative executing patent. I tweaked him
when it all came out and said - look at what you did.
What Russ and team are great ideas and we all have used them since they
first
published about it. And the fact is that it took 40 years before
someone even proposed that it was an issue and could become security
exploit (by some folks in German at a security conference) and it Google 18
months to reduce it to practice.
?
On Tue, Sep 17, 2019 at 9:55 AM Paul Koning <paulkoning at comcast.net>
wrote:
"Spectre" is one of two notorious bugs
of modern CPUs involving
speculative execution. I rather doubt that VAX is
affected by this but I
suspect others here have a lot more knowledge.
paul
Begin forwarded message:
From: coypu at sdf.org
Subject: VAX + Spectre
Date: September 17, 2019 at 5:32:42 AM EDT
To: port-vax at netbsd.org
So, this is a bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
GCC would like to know if VAX needs Spectre-related work.
Are any of the VAXes ever made capable of speculative execution? the
first tech for doing it was in 1967, so not entirely far-fetched.
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh 
11:35 a.m.
New subject: [Simh] Fwd: VAX + Spectre
On 9/17/19 1:49 PM, Warner Losh via cctalk wrote:
On Tue, Sep 17, 2019, 6:40 PM Paul Koning via cctalk
<cctalk at classiccmp.org>
wrote:
I see this as a question of the number of angels that can dance on the
point of a pin. But could GCC compile code that has system access to
do nasties is a more complex question. Then again how does it get
system prives to start with?
First VAX represents more than a dozen different implementations from
the 780 though the many CMOS versions so what might be an issue for one
is likely not for another. The other half is the OS in use may be
sufficiently able to keep rogue processes confined. Of course there
are the LAVC and bus connected multi-cpu clustered systems.
In the end its mostly meaningless as the only reliable way to take a VAX
down is trip on the power cord, assuming you can get to it.
Allison
Yes, I understand that a number of ISAs are
vulnerable. The original
paper by Kocher clearly mentions both x86 and ARM.
The reason I forwwarded the question is that I'm not aware enough of all
the VAX variants to answer whether there are any VAXen with speculative
execution. If no, then we're done, the answer is easy. (That was the case
when the question was asked for PDP11s.) But if yes, then it becomes
necessary to read the paper carefully to see if any of the prerequisites
are implemented in some VAX, and if yes, what the fix might look like.
Early Vaxen are immune. Latter day ones require careful analysis since they
have some out of order things. I'm not expert enough to know for sure,
though, and the latter day stuff is half remembered from marketing material
for one of the final generations of Vax big iron before Alpha drove that
away... But I don't think many of these old beasts are still running even
if my half remembered stuff is right...
I'm reasonably comfortable assuming that the somewhat-related "Meltdown"
vulnerability doesn't show up in VAX, because
that issue requires a
designer who'd implement page access checking in a way I would not expect a
DEC engineer to do.
I'm agree.
Warner
paul
>
>> On Sep 17, 2019, at 11:42 AM, Clem Cole <clemc at ccc.com> wrote:
>>
>> Paul - be careful. All CPU's post the IBM AGS that used branch
> prediction are suspect. Russ Robelen (who was the 360/50 lead, worked on
> 360/90 and lead AGS) has the speculative executing patent. I tweaked him
> when it all came out and said - look at what you did.
>>
>> What Russ and team are great ideas and we all have used them since they
> first published about it. And the fact is that it took 40 years before
> someone even proposed that it was an issue and could become security
> exploit (by some folks in German at a security conference) and it Google 18
> months to reduce it to practice.
>> ?
>>
>> On Tue, Sep 17, 2019 at 9:55 AM Paul Koning <paulkoning at comcast.net>
> wrote:
>> "Spectre" is one of two notorious bugs of modern CPUs involving
> speculative execution. I rather doubt that VAX is affected by this but I
> suspect others here have a lot more knowledge.
>>
>> paul
>>
>>> Begin forwarded message:
>>>
>>> From: coypu at sdf.org
>>> Subject: VAX + Spectre
>>> Date: September 17, 2019 at 5:32:42 AM EDT
>>> To: port-vax at netbsd.org
>>>
>>> So, this is a bug report:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
>>>
>>> GCC would like to know if VAX needs Spectre-related work.
>>> Are any of the VAXes ever made capable of speculative execution? the
>>> first tech for doing it was in 1967, so not entirely far-fetched.
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
11:48 a.m.
New subject: [Simh] Fwd: VAX + Spectre
On Sep 17, 2019, at 2:35 PM, allison via cctalk
<cctalk at classiccmp.org> wrote:
The issue with Spectre (and Meltdown, on the small set of architectures where that
applies) is that it discloses supposedly protected data to unprivileged processes. It
isn't a case of playing games starting from system privs; it's a case of learning
secret data (perhaps passwords from freed buffers) that were intended to be invisible to
your process.
I'd recommend the full academic paper on these attacks by Kocher et al. to anyone with
a serious interest in processor architectures -- which fits much of the membership of
these lists. Even if you don't work with machines that have this issue, or now that
it has been fixed in places where it does apply, it still is a marvelous piece of work and
understanding how it works is a great learning exercise.
I could easily imagine a computer science exam question "Describe in one paragraph
the specific design error that enabled the Meltdown attack".
paul
> ...
I see this as a question of the number of angels that can dance on the
point of a pin. But could GCC compile code that has system access to
do nasties is a more complex question. Then again how does it get
system prives to start with? 
12:08 p.m.
New subject: Vulnerabilities (Was: [Simh] Fwd: VAX + Spectre
On Tue, 17 Sep 2019, Paul Koning via cctalk wrote:
I could easily imagine a computer science exam
question "Describe in one
paragraph the specific design error that enabled the Meltdown attack".
I used to have some related questions in my microcomputer operating
systems class. One student (who later became my best friend and buddy)
skipped the technical details and said, "The primary design error for
MacOS and Windoze (sic) is that they placed a lower priority on security,
than on being able to transparently and without user action, add
smell-o-vision, dancing kangaroos and yodelling jellyfish."
(YES, that's where I got that phrase from.)
12:28 p.m.
New subject: Vulnerabilities (Was: [Simh] Fwd: VAX + Spectre
On 9/17/19 3:08 PM, Fred Cisin via cctalk wrote:
On Tue, 17 Sep 2019, Paul Koning via cctalk wrote:
Fred,
I love it.
My feeling is if you don't stop the mongrel hordes at the door you've
lost. After all wasn't it Vonada that indicated computer are at best
partially tested?
Allison
I could easily imagine a computer science exam
question "Describe in
one paragraph the specific design error that enabled the Meltdown
attack".
I used to have some related questions in my microcomputer operating
systems class.? One student (who later became my best friend and buddy)
skipped the technical details and said, "The primary design error for
MacOS and Windoze (sic) is that they placed a lower priority on
security, than on being able to transparently and without user action,
add smell-o-vision, dancing kangaroos and yodelling jellyfish."
(YES, that's where I got that phrase from.) 
1:58 p.m.
New subject: Vulnerabilities (Was: [Simh] Fwd: VAX + Spectre
On Tue, 17 Sep 2019 at 21:09, Fred Cisin via cctalk
<cctalk at classiccmp.org> wrote:
One student (who later became my best friend and
buddy)
skipped the technical details and said, "The primary design error for
MacOS and Windoze (sic) is that they placed a lower priority on security,
than on being able to transparently and without user action, add
smell-o-vision, dancing kangaroos and yodelling jellyfish."
?
Windows _is_ Bells and Whistles, plus a couple of
gongs.
Don't forget the horns, the custard pies and the water-powered whirling
knives.
-- mlooney and Red Drag Diva
?
--
Liam Proven - Profile: https://about.me/liamproven
Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
6:17 p.m.
New subject: Vulnerabilities (Was: [Simh] Fwd: VAX + Spectre
On 9/17/2019 1:08 PM, Fred Cisin via cctalk wrote:
On Tue, 17 Sep 2019, Paul Koning via cctalk wrote:
I say the concept of a) Time sharing and B) GUI and c) 8 bit bytes
and D) the C programming language have caused computer architecture
to go to dogs ...
Lets not forget some FORTH chips have been to known to meltdown
without any attacks just unlucky coding.
Ben.
Is true the yodelling jellyfish makes me wait 45 seconds for pop up
window to open after clicking on a menu item like "OPEN FILE"?
I could easily imagine a computer science exam
question "Describe in
one paragraph the specific design error that enabled the Meltdown
attack".
I used to have some related questions in my microcomputer operating
systems class.? One student (who later became my best friend and buddy)
skipped the technical details and said, "The primary design error for
MacOS and Windoze (sic) is that they placed a lower priority on
security, than on being able to transparently and without user action,
add smell-o-vision, dancing kangaroos and yodelling jellyfish."
(YES, that's where I got that phrase from.)
11:01 a.m.
New subject: [Simh] Fwd: VAX + Spectre
I can simplify the question a bit. I have to be careful as I work for
Intel and I've been involved with a small bit of it on our end and some of
the lawyers are a bit touchy about the whole situation. So I need to add
- these opinions are my own not necessarily my employers.
Basically, if you have a CPU and microcode design that is post the IBM AGS
that uses any type of branch prediction or speculative execution, the
processor is now suspect. But you need to do the analysis originally
proposed in the German paper. It helps to have the google teams work next
to you when you do that analysis because you now have a recipe for how to
apply the ideas, but that is not the only way to apply them. Before then,
nobody had thought about the problem.
While you point out the attack is carried out in the Google paper using the
MMU, the attack is against the internal instruction predictor. Since the
original Google paper, a number of other ways of attacks against the
microcode have been reduced to practice by other teams.
In the case of the Vax ISA, the original 780 and 750, I do not believe any
attempt at prediction was in the microcode, but that would take someone
like Bob to verify. In all cases, I was never part of the Vax CPU
development, so I'm not going to be able to answer/I really don't know.
But I observe that by the time of the 9000 and the 8000 series Vaxen there
had been enough noise in the community, particularly by Patterson et al, in
the whole RISC vs. CISC front had certainly caught the attention in the CPU
designer's eyes. The techniques that were being considered were
completely and fully discussed in the open literature. I certainly had
read Cocke's and Russ's papers by then in grad school. I have to believe
the same was true of the folks in DEC's HW team. Certainly, by Alpha time
when I was around, those ideas were well-baked at DEC and I would be quite
surprised if a similar attack could not be performed against EV5 and EV6.
Bottom line, you need to really look at the microcode and very it.
Clem
?
On Tue, Sep 17, 2019 at 1:40 PM Paul Koning <paulkoning at comcast.net> wrote:
Yes, I understand that a number of ISAs are
vulnerable. The original
paper by Kocher clearly mentions both x86 and ARM.
The reason I forwwarded the question is that I'm not aware enough of all
the VAX variants to answer whether there are any VAXen with speculative
execution. If no, then we're done, the answer is easy. (That was the case
when the question was asked for PDP11s.) But if yes, then it becomes
necessary to read the paper carefully to see if any of the prerequisites
are implemented in some VAX, and if yes, what the fix might look like.
I'm reasonably comfortable assuming that the somewhat-related "Meltdown"
vulnerability doesn't show up in VAX, because that issue requires a
designer who'd implement page access checking in a way I would not expect a
DEC engineer to do.
paul
On Sep 17, 2019, at 11:42 AM, Clem Cole <clemc
at ccc.com> wrote:
Paul - be careful. All CPU's post the IBM AGS that used branch
prediction are
suspect. Russ Robelen (who was the 360/50 lead, worked on
360/90 and lead AGS) has the speculative executing patent. I tweaked him
when it all came out and said - look at what you did.
What Russ and team are great ideas and we all have used them since they
first
published about it. And the fact is that it took 40 years before
someone even proposed that it was an issue and could become security
exploit (by some folks in German at a security conference) and it Google 18
months to reduce it to practice.
?
On Tue, Sep 17, 2019 at 9:55 AM Paul Koning <paulkoning at comcast.net>
wrote:
"Spectre" is one of two notorious bugs
of modern CPUs involving
speculative execution. I rather doubt that VAX is
affected by this but I
suspect others here have a lot more knowledge.
paul
Begin forwarded message:
From: coypu at sdf.org
Subject: VAX + Spectre
Date: September 17, 2019 at 5:32:42 AM EDT
To: port-vax at netbsd.org
So, this is a bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
GCC would like to know if VAX needs Spectre-related work.
Are any of the VAXes ever made capable of speculative execution? the
first tech for doing it was in 1967, so not entirely far-fetched.
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh 
3:51 p.m.
New subject: [Simh] Fwd: VAX + Spectre
The main difference between Meltdown and the various Spectre problems was that Meltdown
didn't require you to find code that runs in protected space to cause the sideband
effects. Spectre required knowing about specific code running in protected mode to do the
dirty work for you. You just pass some tool, with privileged execution, the location you
want to probe and then watch the sideband effect.
This latest one is bad for a touch typer or those that always enter the password in the
same way. It looks for the timing of when you hit keys and then makes guesses on what keys
would typically take that length of time to type. Most any processor running multiple
users might be susceptible to this one. It does depend on the typical touch typer trained
person or at least one of the typical two finger typers. It works too good to let go by as
not an issue. Even dithering the processor's timer enough to avoid the other problems
isn't enough to hid this one. People type to slow compared to the processors cycle
time.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Clem Cole via cctalk
<cctalk at classiccmp.org>
Sent: Tuesday, September 17, 2019 11:01 AM
To: Paul Koning <paulkoning at comcast.net>
Cc: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>;
SIMH <simh at trailing-edge.com>
Subject: Re: [Simh] Fwd: VAX + Spectre
I can simplify the question a bit. I have to be careful as I work for
Intel and I've been involved with a small bit of it on our end and some of
the lawyers are a bit touchy about the whole situation. So I need to add
- these opinions are my own not necessarily my employers.
Basically, if you have a CPU and microcode design that is post the IBM AGS
that uses any type of branch prediction or speculative execution, the
processor is now suspect. But you need to do the analysis originally
proposed in the German paper. It helps to have the google teams work next
to you when you do that analysis because you now have a recipe for how to
apply the ideas, but that is not the only way to apply them. Before then,
nobody had thought about the problem.
While you point out the attack is carried out in the Google paper using the
MMU, the attack is against the internal instruction predictor. Since the
original Google paper, a number of other ways of attacks against the
microcode have been reduced to practice by other teams.
In the case of the Vax ISA, the original 780 and 750, I do not believe any
attempt at prediction was in the microcode, but that would take someone
like Bob to verify. In all cases, I was never part of the Vax CPU
development, so I'm not going to be able to answer/I really don't know.
But I observe that by the time of the 9000 and the 8000 series Vaxen there
had been enough noise in the community, particularly by Patterson et al, in
the whole RISC vs. CISC front had certainly caught the attention in the CPU
designer's eyes. The techniques that were being considered were
completely and fully discussed in the open literature. I certainly had
read Cocke's and Russ's papers by then in grad school. I have to believe
the same was true of the folks in DEC's HW team. Certainly, by Alpha time
when I was around, those ideas were well-baked at DEC and I would be quite
surprised if a similar attack could not be performed against EV5 and EV6.
Bottom line, you need to really look at the microcode and very it.
Clem
?
On Tue, Sep 17, 2019 at 1:40 PM Paul Koning <paulkoning at comcast.net> wrote:
Yes, I understand that a number of ISAs are
vulnerable. The original
paper by Kocher clearly mentions both x86 and ARM.
The reason I forwwarded the question is that I'm not aware enough of all
the VAX variants to answer whether there are any VAXen with speculative
execution. If no, then we're done, the answer is easy. (That was the case
when the question was asked for PDP11s.) But if yes, then it becomes
necessary to read the paper carefully to see if any of the prerequisites
are implemented in some VAX, and if yes, what the fix might look like.
I'm reasonably comfortable assuming that the somewhat-related "Meltdown"
vulnerability doesn't show up in VAX, because that issue requires a
designer who'd implement page access checking in a way I would not expect a
DEC engineer to do.
paul
On Sep 17, 2019, at 11:42 AM, Clem Cole <clemc
at ccc.com> wrote:
Paul - be careful. All CPU's post the IBM AGS that used branch
prediction are
suspect. Russ Robelen (who was the 360/50 lead, worked on
360/90 and lead AGS) has the speculative executing patent. I tweaked him
when it all came out and said - look at what you did.
What Russ and team are great ideas and we all have used them since they
first
published about it. And the fact is that it took 40 years before
someone even proposed that it was an issue and could become security
exploit (by some folks in German at a security conference) and it Google 18
months to reduce it to practice.
?
On Tue, Sep 17, 2019 at 9:55 AM Paul Koning <paulkoning at comcast.net>
wrote:
"Spectre" is one of two notorious bugs
of modern CPUs involving
speculative execution. I rather doubt that VAX is
affected by this but I
suspect others here have a lot more knowledge.
paul
Begin forwarded message:
From: coypu at sdf.org
Subject: VAX + Spectre
Date: September 17, 2019 at 5:32:42 AM EDT
To: port-vax at netbsd.org
So, this is a bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
GCC would like to know if VAX needs Spectre-related work.
Are any of the VAXes ever made capable of speculative execution? the
first tech for doing it was in 1967, so not entirely far-fetched.
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
5:19 p.m.
New subject: [Simh] Fwd: VAX + Spectre
On Sep 17, 2019, at 6:51 PM, dwight via cctalk
<cctalk at classiccmp.org> wrote:
...
This latest one is bad for a touch typer or those that always enter the password in the
same way. It looks for the timing of when you hit keys and then makes guesses on what keys
would typically take that length of time to type.
Speaking of timing, that reminds me of two amazing security holes written up in the past
few years. Nothing to do with the Spectre etc. issue.
One is the recovery of speech from an encrypted VoIP channel such as Skype, by looking at
the sizes of the encrypted data blocks. (Look for a paper named "Hookt on
fon-iks" by White et al.) The fix for this is message padding.
The other is the recovery of the RSA private key in a smartphone by listening to the sound
it makes while decrypting. The fix for this is timing tweaks in the decryption inner
loop. (Look for a paper by, among others, Adi Shamir, the S in RSA and one of the
world's top cryptographers.)
It's pretty amazing what ways people find to break into security mechanisms.
paul
18 Sep
18 Sep
12:42 a.m.
New subject: [Simh] Fwd: VAX + Spectre
On Wed, 18 Sep 2019 at 02:19, Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
... Wow.
*Wow.*
Thanks for those!
--
Liam Proven - Profile: https://about.me/liamproven
Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
...
Speaking of timing, that reminds me of two amazing security holes written up in the past
few years. Nothing to do with the Spectre etc. issue.
One is the recovery of speech from an encrypted VoIP channel such as Skype, by looking at
the sizes of the encrypted data blocks. (Look for a paper named "Hookt on
fon-iks" by White et al.) The fix for this is message padding.
The other is the recovery of the RSA private key in a smartphone by listening to the
sound it makes while decrypting. The fix for this is timing tweaks in the decryption
inner loop. (Look for a paper by, among others, Adi Shamir, the S in RSA and one of the
world's top cryptographers.)
It's pretty amazing what ways people find to break into security mechanisms. 
9:19 a.m.
New subject: [Simh] Fwd: VAX + Spectre
On Sep 18, 2019, at 12:42 AM, Liam Proven via cctalk
<cctalk at classiccmp.org> wrote:
On Wed, 18 Sep 2019 at 02:19, Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
... Wow.
*Wow.*
Thanks for those!
In the deep dark days of yore, I recall an actual demonstration of being able to
read/replicate the contents of the screen (CRT) of a PC by looking at the AC (e.g. mains)
that the PC was plugged into. Admittedly it was relatively low fidelity, but yikes!
TTFN - Guy
...
Speaking of timing, that reminds me of two amazing security holes written up in the
past few years. Nothing to do with the Spectre etc. issue.
One is the recovery of speech from an encrypted VoIP channel such as Skype, by looking at
the sizes of the encrypted data blocks. (Look for a paper named "Hookt on
fon-iks" by White et al.) The fix for this is message padding.
The other is the recovery of the RSA private key in a smartphone by listening to the
sound it makes while decrypting. The fix for this is timing tweaks in the decryption
inner loop. (Look for a paper by, among others, Adi Shamir, the S in RSA and one of the
world's top cryptographers.)
It's pretty amazing what ways people find to break into security mechanisms. 
9:59 a.m.
New subject: [Simh] Fwd: VAX + Spectre
On Wednesday (09/18/2019 at 09:19AM -0700), Guy Sotomayor Jr via cctalk wrote:
https://en.wikipedia.org/wiki/Van_Eck_phreaking
--
Chris Elmquist
On Sep 18, 2019, at 12:42 AM, Liam Proven via
cctalk <cctalk at classiccmp.org> wrote:
On Wed, 18 Sep 2019 at 02:19, Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
... Wow.
*Wow.*
Thanks for those!
In the deep dark days of yore, I recall an actual demonstration of being able to
read/replicate the contents of the screen (CRT) of a PC by looking at the AC (e.g. mains)
that the PC was plugged into. Admittedly it was relatively low fidelity, but yikes!
...
Speaking of timing, that reminds me of two amazing security holes written up in the
past few years. Nothing to do with the Spectre etc. issue.
One is the recovery of speech from an encrypted VoIP channel such as Skype, by looking at
the sizes of the encrypted data blocks. (Look for a paper named "Hookt on
fon-iks" by White et al.) The fix for this is message padding.
The other is the recovery of the RSA private key in a smartphone by listening to the
sound it makes while decrypting. The fix for this is timing tweaks in the decryption
inner loop. (Look for a paper by, among others, Adi Shamir, the S in RSA and one of the
world's top cryptographers.)
It's pretty amazing what ways people find to break into security mechanisms.
10:14 a.m.
New subject: [Simh] Fwd: VAX + Spectre
On Sep 18, 2019, at 9:59 AM, Chris Elmquist <chrise
at pobox.com> wrote:
On Wednesday (09/18/2019 at 09:19AM -0700), Guy Sotomayor Jr via cctalk wrote:
https://en.wikipedia.org/wiki/Van_Eck_phreaking
<https://en.wikipedia.org/wiki/Van_Eck_phreaking>
Cool!
Yea, I had to make a trip to a ?secure facility? once and there were entire ?tempest?
rooms with conditioned power and no external communications equipment. The room itself
(think *large*) was a faraday cage with a vault door that was kept closed when ever there
was sensitive stuff going on. Since I didn?t have a security clearance, the door was open
and everywhere I went there were red lights in the rooms/halls that I was in that would be
on to indicate that no sensitive information should be discussed (makes you feel really
wanted). ;-)
TTFN - Guy
On Sep 18, 2019, at 12:42 AM, Liam Proven via
cctalk <cctalk at classiccmp.org> wrote:
On Wed, 18 Sep 2019 at 02:19, Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
In the deep dark days of yore, I recall an actual demonstration of being able to
read/replicate the contents of the screen (CRT) of a PC by looking at the AC (e.g. mains)
that the PC was plugged into. Admittedly it was relatively low fidelity, but yikes!
> ...
Speaking of timing, that reminds me of two amazing security holes written up in the past
few years. Nothing to do with the Spectre etc. issue.
One is the recovery of speech from an encrypted VoIP channel such as Skype, by looking at
the sizes of the encrypted data blocks. (Look for a paper named "Hookt on
fon-iks" by White et al.) The fix for this is message padding.
The other is the recovery of the RSA private key in a smartphone by listening to the
sound it makes while decrypting. The fix for this is timing tweaks in the decryption
inner loop. (Look for a paper by, among others, Adi Shamir, the S in RSA and one of the
world's top cryptographers.)
It's pretty amazing what ways people find to break into security mechanisms.
... Wow.
*Wow.*
Thanks for those! 
22 Sep
22 Sep
6:18 p.m.
New subject: [Simh] Fwd: VAX + Spectre
On 18/09/2019, Guy Sotomayor Jr via cctalk <cctalk at classiccmp.org> wrote:
[...]
Yea, I had to make a trip to a ?secure facility? once
and there were entire
?tempest? rooms with conditioned power and no external communications
equipment.
We had a secure (but not tempest) room built for us by an authorised
contractor and they forgot to install A/C. It was unusable until a
portable A/C was placed in it with complicated baffles letting the hot
air out.
N.
6:24 p.m.
New subject: [Simh] Fwd: VAX + Spectre
On Sun, 22 Sep 2019, Nemo via cctalk wrote:
We had a secure (but not tempest) room built for us by
an authorised
contractor and they forgot to install A/C. It was unusable until a
portable A/C was placed in it with complicated baffles letting the hot
air out.
Nobody except a college administrator would build a computer room with no
temperture control.
Even at McMurdo, they had to have windows that opened.
17 Sep
17 Sep
noon
New subject: KiCad pcb file
Hello.
I'm looking for a PCB layout file / template of a 2 slot Unibus card,
which I want to use in KiCad.
Can someone help me with this?
Thank you,
Ed
--
Ik email, dus ik besta 😆
4:54 p.m.
New subject: KiCad pcb file
On 9/17/19 15:00, Ed Groenenberg via cctalk wrote:
Hello.
I'm looking for a PCB layout file / template of a 2 slot Unibus card,
which I want to use in KiCad.
Can someone help me with this?
Here's a KiCad template for a double-height QBUS card.? I haven't
verified it or cleaned it up but it ought to make a good starting point
and deleting the QBUS bits will be easy.? Eventually I'll need to do a
quad-height Unibus card too.
http://pdp10.froghouse.org/qsic/qbus-template.tar.gz
If you're building your own DEC boards, this is the best dimensional
diagram I've come across; I pulled it out of a uVAX manual.? The one bug
I've found in it is the "1.00?.010" in the corner where the edge fingers
start.? I think it's supposed to be "0.100?.010" but I'd double-check
that against other diagrams or measure a real board.
http://pdp10.froghouse.org/qsic/qbus-dimensions.pdf
18 Sep
18 Sep
2:09 p.m.
New subject: KiCad pcb file
We have to clean it up but we've got the pattern for a quad height
prototype board. I can share the outline and edge connectors once it's 100%
verified.
Thanks,
Jonathan
On Tue, Sep 17, 2019 at 7:54 PM David Bridgham via cctalk <
cctalk at classiccmp.org> wrote:
On 9/17/19 15:00, Ed Groenenberg via cctalk wrote:
Hello.
I'm looking for a PCB layout file / template of a 2 slot Unibus card,
which I want to use in KiCad.
Can someone help me with this?
Here's a KiCad template for a double-height QBUS card. I haven't
verified it or cleaned it up but it ought to make a good starting point
and deleting the QBUS bits will be easy. Eventually I'll need to do a
quad-height Unibus card too.
http://pdp10.froghouse.org/qsic/qbus-template.tar.gz
If you're building your own DEC boards, this is the best dimensional
diagram I've come across; I pulled it out of a uVAX manual. The one bug
I've found in it is the "1.00?.010" in the corner where the edge fingers
start. I think it's supposed to be "0.100?.010" but I'd double-check
that against other diagrams or measure a real board.
http://pdp10.froghouse.org/qsic/qbus-dimensions.pdf
19 Sep
19 Sep
5:57 p.m.
New subject: KiCad pcb file
I know someone out west who makes boards for DEC systems. If you want ,
I'll look for his contact info this weekend.
Paul
On Wed, Sep 18, 2019 at 4:09 PM systems_glitch via cctalk <
cctalk at classiccmp.org> wrote:
We have to clean it up but we've got the pattern
for a quad height
prototype board. I can share the outline and edge connectors once it's 100%
verified.
Thanks,
Jonathan
On Tue, Sep 17, 2019 at 7:54 PM David Bridgham via cctalk <
cctalk at classiccmp.org> wrote:
On 9/17/19 15:00, Ed Groenenberg via cctalk
wrote:
Hello.
I'm looking for a PCB layout file / template of a 2 slot Unibus card,
which I want to use in KiCad.
Can someone help me with this?
Here's a KiCad template for a double-height QBUS card. I haven't
verified it or cleaned it up but it ought to make a good starting point
and deleting the QBUS bits will be easy. Eventually I'll need to do a
quad-height Unibus card too.
http://pdp10.froghouse.org/qsic/qbus-template.tar.gz
If you're building your own DEC boards, this is the best dimensional
diagram I've come across; I pulled it out of a uVAX manual. The one bug
I've found in it is the "1.00?.010" in the corner where the edge fingers
start. I think it's supposed to be "0.100?.010" but I'd double-check
that against other diagrams or measure a real board.
http://pdp10.froghouse.org/qsic/qbus-dimensions.pdf
20 Sep
20 Sep
5:55 a.m.
New subject: KiCad pcb file
Paul,
Sure! Always good to have more contacts in industry.
Thanks,
Jonathan
On Thu, Sep 19, 2019 at 8:57 PM Paul Anderson via cctalk <
cctalk at classiccmp.org> wrote:
I know someone out west who makes boards for DEC
systems. If you want ,
I'll look for his contact info this weekend.
Paul
On Wed, Sep 18, 2019 at 4:09 PM systems_glitch via cctalk <
cctalk at classiccmp.org> wrote:
We have to clean it up but we've got the
pattern for a quad height
prototype board. I can share the outline and edge connectors once it's
100%
verified.
Thanks,
Jonathan
On Tue, Sep 17, 2019 at 7:54 PM David Bridgham via cctalk <
cctalk at classiccmp.org> wrote:
> On 9/17/19 15:00, Ed Groenenberg via cctalk wrote:
> > Hello.
> >
> > I'm looking for a PCB layout file / template of a 2 slot Unibus card,
> > which I want to use in KiCad.
> >
> > Can someone help me with this?
>
>
> Here's a KiCad template for a double-height QBUS card. I haven't
> verified it or cleaned it up but it ought to make a good starting point
> and deleting the QBUS bits will be easy. Eventually I'll need to do a
> quad-height Unibus card too.
>
> http://pdp10.froghouse.org/qsic/qbus-template.tar.gz
>
> If you're building your own DEC boards, this is the best dimensional
> diagram I've come across; I pulled it out of a uVAX manual. The one
bug
> I've found in it is the
"1.00?.010" in the corner where the edge
fingers
start. I
think it's supposed to be "0.100?.010" but I'd double-check
that against other diagrams or measure a real board.
http://pdp10.froghouse.org/qsic/qbus-dimensions.pdf
17 Sep
17 Sep
8:48 a.m.
On 09/17/2019 08:55 AM, Paul Koning via cctalk wrote:
"Spectre" is one of two notorious bugs of
modern CPUs involving speculative execution. I rather doubt that VAX is affected by this
but I suspect others here have a lot more knowledge.
You need an extremely high resolution timer to detect slight
differences in execution time of speculatively-executed
threads. The VAX 11/780 certainly did not do speculative
execution, and my guess is that all VAXen did not, either.
Also, I don't think the timer was high enough resolution to
detect such a difference.
The Alpha did do speculative execution, so it is remotely
possible that you could play such games on that platform.
Without a deep understanding of how these exploits really
work, I'm still a bit skeptical that it could actually be
performed on real-world systems in a shared host data center.
Jon
2 Oct
2 Oct
6:59 p.m.
On Tue, 17 Sep 2019, Jon Elson via cctalk wrote:
The NVAX and NVAX+ implementations include a branch predictor in their
microarchitecture[1], so obviously they do execute speculatively.
"Spectre" is one of two notorious bugs of modern CPUs involving speculative
execution. I rather doubt that VAX is affected by this but I suspect others
here have a lot more knowledge.
You need an extremely high resolution timer to detect slight differences in
execution time of speculatively-executed threads. The VAX 11/780 certainly did
not do speculative execution, and my guess is that all VAXen did not, either. Also, I don't think the timer was high enough
resolution to detect such a
difference.
I can't speak of timer availability offhand though.
References:
[1] G. Michael Uhler et al, "The NVAX and NVAX+ High-performance VAX
Microprocessors", Digital Technical Journal Vol. 4 No. 3 Summer 1992
<ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ701/DTJ701PF.PDF>
Maciej
3 Oct
3 Oct
5:25 a.m.
On Thu, 3 Oct 2019, Maciej W. Rozycki wrote:
For the record: in NVAX prediction does not extend beyond the instruction
fetch unit (I-box in VAX-speak), so there's actually no speculative
execution, but only speculative prefetch.
Maciej
You need an
extremely high resolution timer to detect slight differences in
execution time of speculatively-executed threads. The VAX 11/780 certainly did
not do speculative execution, and my guess is that all VAXen did not, either.
The NVAX and NVAX+ implementations include a branch predictor in their
microarchitecture[1], so obviously they do execute speculatively.
6:45 a.m.
New subject: VAX + Spectre
On Oct 3, 2019, at 8:25 AM, Maciej W. Rozycki
<macro at linux-mips.org> wrote:
On Thu, 3 Oct 2019, Maciej W. Rozycki wrote:
For the record: in NVAX prediction does not extend beyond the instruction
fetch unit (I-box in VAX-speak), so there's actually no speculative
execution, but only speculative prefetch.
That's a key point. These vulnerabilities are quite complex and details matter. They
depend on speculation that goes far enough to make data references that produce cache
fills, and that those fills persist after the speculative references have been voided.
Branch prediction is only the first step, and as you point out, that alone is nowhere near
enough. For example, if a particular design did speculative execution but not speculative
memory references on adresses that miss in the cache, you'd still have no issue.
paul
You need
an extremely high resolution timer to detect slight differences in
execution time of speculatively-executed threads. The VAX 11/780 certainly did
not do speculative execution, and my guess is that all VAXen did not, either.
The NVAX and NVAX+ implementations include a branch predictor in their
microarchitecture[1], so obviously they do execute speculatively. 
7:55 a.m.
New subject: VAX + Spectre
tor 2019-10-03 klockan 09:45 -0400 skrev Paul Koning via cctalk:
Can the speculative pre-fetch of instruction trigger cache fills ?
On Oct 3,
2019, at 8:25 AM, Maciej W. Rozycki <macro at linux-mips.org
For the record: in NVAX prediction does not extend beyond the
instruction
fetch unit (I-box in VAX-speak), so there's actually no
speculative
execution, but only speculative prefetch.
That's a key point. These vulnerabilities are quite complex and
details matter. They depend on speculation that goes far enough to
make data references that produce cache fills, and that those fills
persist after the speculative references have been voided.
Branch prediction is only the first step, and as you point out, that
alone is nowhere near enough. For example, if a particular design
did speculative execution but not speculative memory references on
adresses that miss in the cache, you'd still have no issue.
wrote:
On Thu, 3 Oct 2019, Maciej W. Rozycki wrote:
You need
an extremely high resolution timer to detect slight
differences in
execution time of speculatively-executed threads. The VAX
11/780 certainly did
not do speculative execution, and my guess is that all VAXen
did not, either.
The NVAX and NVAX+ implementations include a branch predictor in
their
microarchitecture[1], so obviously they do execute speculatively.
8:28 a.m.
New subject: VAX + Spectre
On Oct 3, 2019, at 10:55 AM, Stefan Skoglund
<stefan.skoglund at agj.net> wrote:
tor 2019-10-03 klockan 09:45 -0400 skrev Paul Koning via cctalk:
Can the speculative pre-fetch of instruction trigger cache fills ?
I don't know, but that isn't relevant to the Spectre issue. That one need
speculative data loads, visible via a timing channel to user mode code.
paul
On Oct 3,
2019, at 8:25 AM, Maciej W. Rozycki <macro at linux-mips.org
That's a key point. These vulnerabilities are quite complex and
details matter. They depend on speculation that goes far enough to
make data references that produce cache fills, and that those fills
persist after the speculative references have been voided.
Branch prediction is only the first step, and as you point out, that
alone is nowhere near enough. For example, if a particular design
did speculative execution but not speculative memory references on
adresses that miss in the cache, you'd still have no issue.
wrote:
On Thu, 3 Oct 2019, Maciej W. Rozycki wrote:
> You need an extremely high resolution timer
to detect slight
> differences in
> execution time of speculatively-executed threads. The VAX
> 11/780 certainly did
> not do speculative execution, and my guess is that all VAXen
> did not, either.
The NVAX and NVAX+ implementations include a branch predictor in
their
microarchitecture[1], so obviously they do execute speculatively.
For the record: in NVAX prediction does not extend beyond the
instruction
fetch unit (I-box in VAX-speak), so there's actually no
speculative
execution, but only speculative prefetch. 
8:52 a.m.
New subject: VAX + Spectre
-----Original Message-----
From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Paul Koning via
cctalk
Sent: 03 October 2019 16:28
To: Stefan Skoglund <stefan.skoglund at agj.net>
Cc: General Discussion: On-Topic and Off-Topic Posts
<cctalk at
classiccmp.org>
Subject: Re: VAX + Spectre
Whilst , of course, nothing has been done for VAX VSI have checked to see
if OpenVMS in Alpha, Itanium or AMD64 are susceptible...
http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf
Dave
On Oct 3, 2019, at 10:55 AM, Stefan Skoglund
<stefan.skoglund at agj.net>
wrote:
tor 2019-10-03 klockan 09:45 -0400 skrev Paul Koning via cctalk:
Can the speculative pre-fetch of instruction trigger cache fills ?
I don't know, but that isn't relevant to the Spectre issue. That one need
speculative data loads, visible via a timing channel to user mode code.
paul On Oct 3,
2019, at 8:25 AM, Maciej W. Rozycki <macro at linux-mips.org
> wrote:
On Thu, 3 Oct 2019, Maciej W. Rozycki wrote:
>> You need an extremely high resolution timer to detect slight
>> differences in execution time of speculatively-executed threads.
>> The VAX
>> 11/780 certainly did
>> not do speculative execution, and my guess is that all VAXen did
>> not, either.
>
> The NVAX and NVAX+ implementations include a branch predictor in
> their microarchitecture[1], so obviously they do execute
> speculatively.
For the record: in NVAX prediction does not extend beyond the
instruction fetch unit (I-box in VAX-speak), so there's actually no
speculative execution, but only speculative prefetch.
That's a key point. These vulnerabilities are quite complex and
details matter. They depend on speculation that goes far enough to
make data references that produce cache fills, and that those fills
persist after the speculative references have been voided.
Branch prediction is only the first step, and as you point out, that
alone is nowhere near enough. For example, if a particular design
did speculative execution but not speculative memory references on
adresses that miss in the cache, you'd still have no issue.
1678
days inactive
1694
days old
33 comments
21 participants
participants (21)
-
allisonportable＠gmail.com -
bfranchuk＠jetnet.ab.ca -
chrise＠pobox.com -
cisin＠xenosoft.com -
clemc＠ccc.com -
cym224＠gmail.com -
dab＠froghouse.org -
dave.g4ugm＠gmail.com -
dkelvey＠hotmail.com -
ed＠groenenberg.net -
elson＠pico-systems.com -
ggs＠shiresoft.com -
healyzh＠avanthar.com -
imp＠bsdimp.com -
lproven＠gmail.com -
macro＠linux-mips.org -
paulkoning＠comcast.net -
spectre＠floodgap.com -
stefan.skoglund＠agj.net -
systems.glitch＠gmail.com -
useddec＠gmail.com