[Simh] Fwd: VAX + Spectre

[dwight]

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