Re: [Simh] Fwd: VAX + Spectre

2019-09-22 Thread Fred Cisin via cctalk

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.


Re: [Simh] Fwd: VAX + Spectre

2019-09-22 Thread Nemo via cctalk
On 18/09/2019, Guy Sotomayor Jr via cctalk  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.


Re: [Simh] Fwd: VAX + Spectre

2019-09-18 Thread Guy Sotomayor Jr via cctalk



> On Sep 18, 2019, at 9:59 AM, Chris Elmquist  wrote:
> 
> On Wednesday (09/18/2019 at 09:19AM -0700), Guy Sotomayor Jr via cctalk wrote:
>> 
>> 
>>> On Sep 18, 2019, at 12:42 AM, Liam Proven via cctalk 
>>>  wrote:
>>> 
>>> On Wed, 18 Sep 2019 at 02:19, Paul Koning via cctalk
>>>  wrote:
> ...
 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!
>> 
>> 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!
> 
> 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

Re: [Simh] Fwd: VAX + Spectre

2019-09-18 Thread Chris Elmquist via cctalk
On Wednesday (09/18/2019 at 09:19AM -0700), Guy Sotomayor Jr via cctalk wrote:
> 
> 
> > On Sep 18, 2019, at 12:42 AM, Liam Proven via cctalk 
> >  wrote:
> > 
> > On Wed, 18 Sep 2019 at 02:19, Paul Koning via cctalk
> >  wrote:
> >>> ...
> >> 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!
> 
> 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!

https://en.wikipedia.org/wiki/Van_Eck_phreaking

-- 
Chris Elmquist


Re: [Simh] Fwd: VAX + Spectre

2019-09-18 Thread Guy Sotomayor Jr via cctalk



> On Sep 18, 2019, at 12:42 AM, Liam Proven via cctalk  
> wrote:
> 
> On Wed, 18 Sep 2019 at 02:19, Paul Koning via cctalk
>  wrote:
>>> ...
>> 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!

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

Re: [Simh] Fwd: VAX + Spectre

2019-09-18 Thread Liam Proven via cctalk
On Wed, 18 Sep 2019 at 02:19, Paul Koning via cctalk
 wrote:
> > ...
> 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!

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053


Re: Vulnerabilities (Was: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread ben via cctalk

Windows _is_ Bells and Whistles, plus a couple of gongs.


No ... The GONGS is the chinese knock off.





Re: Vulnerabilities (Was: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread ben via cctalk

On 9/17/2019 1:08 PM, Fred Cisin via cctalk wrote:

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.)


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"?



Re: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread Paul Koning via cctalk



> On Sep 17, 2019, at 6:51 PM, dwight via cctalk  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



Re: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread dwight via cctalk
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  on behalf of Clem Cole via cctalk 

Sent: Tuesday, September 17, 2019 11:01 AM
To: Paul Koning 
Cc: General Discussion: On-Topic and Off-Topic Posts ; 
SIMH 
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  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  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
> exploi

Re: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread Clem Cole via cctalk
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  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  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 
> 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: co...@sdf.org
> >> Subject: VAX + Spectre
> >> Date: September 17, 2019 at 5:32:42 AM EDT
> >> To: port-...@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
> > s...@trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>


Re: Vulnerabilities (Was: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread Liam Proven via cctalk
On Tue, 17 Sep 2019 at 21:09, Fred Cisin via cctalk
 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: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053


Re: Vulnerabilities (Was: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread allison via cctalk
On 9/17/19 3:08 PM, Fred Cisin via cctalk wrote:
> 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.)

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


Vulnerabilities (Was: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread Fred Cisin via cctalk

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.)


Re: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread Paul Koning via cctalk



> On Sep 17, 2019, at 2:35 PM, allison via cctalk  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?

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



Re: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread allison via cctalk
On 9/17/19 1:49 PM, Warner Losh via cctalk wrote:
> On Tue, Sep 17, 2019, 6:40 PM Paul Koning via cctalk 
> 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  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 
>> 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: co...@sdf.org
 Subject: VAX + Spectre
 Date: September 17, 2019 at 5:32:42 AM EDT
 To: port-...@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
>>> s...@trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>

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


Re: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread Warner Losh via cctalk
On Tue, Sep 17, 2019, 6:40 PM Paul Koning via cctalk 
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  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 
> 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: co...@sdf.org
> >> Subject: VAX + Spectre
> >> Date: September 17, 2019 at 5:32:42 AM EDT
> >> To: port-...@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
> > s...@trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>


Re: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread Paul Koning via cctalk
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  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  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: co...@sdf.org
>> Subject: VAX + Spectre
>> Date: September 17, 2019 at 5:32:42 AM EDT
>> To: port-...@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
> s...@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh



Re: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread Clem Cole via cctalk
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  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: *co...@sdf.org
> *Subject: **VAX + Spectre*
> *Date: *September 17, 2019 at 5:32:42 AM EDT
> *To: *port-...@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
> s...@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh