[Simh] Fwd: VAX + Spectre

[Timothe Litt]

The VAX 9000 does branch prediction & speculative fetches; kills,
aborts, and register logs made for debugging fun.  "A cache cycle wasted
is lost forever" met "waste not, want not".  It fetches aggressively. 
It has multiple microcodes - some loadable, other compiled (and
optimized) into gates.  I was the last person to touch the EBox
microcode.  I haven't studied the CVEs - but my understanding is that
the issues come from cross-process leakage, which is most severe with
virtual machines.  Or can happen if you get a hostile process onto a
server.  Although the VAX architecture specifies a VM mode, it didn't
get much (if any) traction.  The group that specified it did worry about
covert channels, including from cache timing.  It seems unlikely that
hostile processes would appear on VAXes - assuming that you've turned
off the DECnet TASK object.  After all, you don't have bloated web
browsers.  NVAX borrowed a lot from the 9000 - but I don't have those
documents handy - I had little to do with it.  (Fun fact: NVAX
simulation was run on 9000 reliability qualification machines - for speed.)

Alpha has branch prediction - type and effectiveness evolved with the
processors.  Architecturally, Alpha uses a much more forgiving memory
ordering model.  Out of order and speculative execution, store buffers,
speculative loads, explicit memory barriers.  It doesn't have microcode,
though PALcode has some of its attributes.  Again, I haven't looked at
the CVEs in detail.  VMS Software claims to have done an analysis -
http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf
They certainly hired a number of OS experts - but I don't know if that
includes the microarchitectural expertise that would be required to be
definitive.  Their letter seems to indicate black box testing...

For both, remember that by today's standards, these are slow CPUs.  That
cuts both ways.  Also, "verifying microcode" (or the gates & sequencers)
is more than "looking at it".  Understanding is tough.  Even focused
testing is non-trivial.

I would include the environment in any risk assessment - these attacks
(and for that matter, ROWHAMMER and other attacks) require a parallel
process/OS to work.  If you can prevent that, as I understand them, they
won't work.  Since VAX (and Alpha) aren't used in the shared hosting
(VM) world, to a first order, the risk seems very low.  As for hostile
processes on your OS instance - maybe in the days of general timesharing
with an uncontrolled user base compiling code.  But is that the way
they're used today?  Or are they legacy back-end systems with a sane
user base?  And is there a sufficiently motivated and resourced attacker
who could do something with, say, a webserver's private key?  (Once you
have it, you need a DNS and/or routing attack to get your false server
to take traffic; for SSH, one would hope you use a firewall/other
secondary defenses.  And it may be more effective to simply change keys
frequently.  Anything much longer than a key would take a long time to
extract  - and you have other issues if that goes unnoticed.)  And, even
assuming GCC was updated - how many people will (can?) recompile the
legacy application base?  And libraries?

It's rational to look at these - just don't overreact.  The mitigations
have costs, and preventing intrusions may be a better investment.

On another subject, a while back someone mentioned the 34 bit (25-bit
PFN) physical memory ECO to VAX.  The 9000 DID implement it, and my
group created an off-trunk build of VMS that exploited it.  The ECO was
not popular with the OS groups, because it used bits in the PTE (Z & 3
software bits) that needed a new home - a byte that had to go somewhere,
which broke assumptions about data structures.  It turned out that based
on that opposition, the cost of DRAM, and the cost of fixing a
late-breaking bug, we decided to drop support (and supported the full
21-bit PFN - 30 bit PA) instead.  This still required a hardware change
- but it was much smaller.  So 34-bit mode did get implemented, and
almost got to the field - and the DMA devices that read PTEs (for DMA)
had to (and did) know about it...

On 17-Sep-19 14:01, Clem Cole wrote:
> 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
> <mailto: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
>     <mailto: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 <mailto: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
>     >>
>     >> 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 <mailto:Simh at trailing-edge.com>
>     > http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20190917/42ca54b1/attachment-0001.html>