<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.)<br>
</p>
<p>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 - <a
href="http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf">http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf</a>
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...</p>
<p>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.<br>
</p>
<p>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?<br>
</p>
<p>It's rational to look at these - just don't overreact. The
mitigations have costs, and preventing intrusions may be a better
investment.</p>
<p>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...</p>
<pre class="moz-signature" cols="72">
</pre>
<div class="moz-cite-prefix">On 17-Sep-19 14:01, Clem Cole wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC20D2Ox_uYnFMiMxrsWxr4qN-FYMPx3_4QTvkp9PU96pS9WDw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">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.</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">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.</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">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.</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">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.</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">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.</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">Bottom line,
you need to really look at the microcode and very it.</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">Clem</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
</div>
<div hspace="streak-pt-mark" style="max-height:1px"><img alt=""
style="width:0px;max-height:0px;overflow:hidden"
src="https://mailfoogae.appspot.com/t?sender=aY2xlbWNAY2NjLmNvbQ%3D%3D&type=zerocontent&guid=21efb56e-d544-4515-bf26-e9cb8a36f6f8"
moz-do-not-send="true"><font size="1" color="#ffffff">ᐧ</font></div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2019 at 1:40
PM Paul Koning <<a href="mailto:paulkoning@comcast.net"
moz-do-not-send="true">paulkoning@comcast.net</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes,
I understand that a number of ISAs are vulnerable. The
original paper by Kocher clearly mentions both x86 and ARM.<br>
<br>
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.<br>
<br>
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.<br>
<br>
paul<br>
<br>
> On Sep 17, 2019, at 11:42 AM, Clem Cole <<a
href="mailto:clemc@ccc.com" target="_blank"
moz-do-not-send="true">clemc@ccc.com</a>> wrote:<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> ᐧ<br>
> <br>
> On Tue, Sep 17, 2019 at 9:55 AM Paul Koning <<a
href="mailto:paulkoning@comcast.net" target="_blank"
moz-do-not-send="true">paulkoning@comcast.net</a>> wrote:<br>
> "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.<br>
> <br>
> paul<br>
> <br>
>> Begin forwarded message:<br>
>> <br>
>> From: <a href="mailto:coypu@sdf.org" target="_blank"
moz-do-not-send="true">coypu@sdf.org</a><br>
>> Subject: VAX + Spectre<br>
>> Date: September 17, 2019 at 5:32:42 AM EDT<br>
>> To: <a href="mailto:port-vax@netbsd.org"
target="_blank" moz-do-not-send="true">port-vax@netbsd.org</a><br>
>> <br>
>> So, this is a bug report:<br>
>> <a
href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811</a><br>
>> <br>
>> GCC would like to know if VAX needs Spectre-related
work.<br>
>> Are any of the VAXes ever made capable of speculative
execution? the<br>
>> first tech for doing it was in 1967, so not entirely
far-fetched.<br>
> <br>
> _______________________________________________<br>
> Simh mailing list<br>
> <a href="mailto:Simh@trailing-edge.com" target="_blank"
moz-do-not-send="true">Simh@trailing-edge.com</a><br>
> <a
href="http://mailman.trailing-edge.com/mailman/listinfo/simh"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://mailman.trailing-edge.com/mailman/listinfo/simh</a><br>
<br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Simh mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a>
<a class="moz-txt-link-freetext" href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a></pre>
</blockquote>
</body>
</html>