OpenVMS with regards to Spectre/Meltdown

[Bob Gezelter]

VSI has released a letter clarifying that the relevance of Spectre/Meltdown on OpenVMS systems (Alpha, Itanium, and the upcoming x86-64).

The original letter can be found at: http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf

- Bob Gezelter, http://www.rlgsc.com

[Norman F Raphael]

-----Original Message-----

From: Bob Gezelter via Info-vax <info...@info-vax.com>

Sent: Wed, Jan 17, 2018 5:55 pm
Subject: [New Info-vax] OpenVMS with regards to Spectre/Meltdown

>VSI has released a letter clarifying that the relevance of Spectre/Meltdown on OpenVMS systems (Alpha, >Itanium, and the upcoming x86-64).
>
>The original letter can be found at: http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf
>
>- Bob Gezelter, http://www.rlgsc.com

This link does not seem to work from here or on the VSI website.

Norman F. Raphael
Please reply to: norman....@ieee.org
"Everything worthwhile eventually
degenerates into real work." -Murphy

[Jan-Erik Soderholm]

Den 2018-01-18 kl. 00:21, skrev Norman F Raphael:
> -----Original Message-----
> From: Bob Gezelter via Info-vax <info...@info-vax.com>
>
> Sent: Wed, Jan 17, 2018 5:55 pm
> Subject: [New Info-vax] OpenVMS with regards to Spectre/Meltdown
>
> >VSI has released a letter clarifying that the relevance of
> Spectre/Meltdown on OpenVMS systems (Alpha, >Itanium, and the upcoming x86-64).
> >
> >The original letter can be found at:
> http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf
> <http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf>
> >
> >- Bob Gezelter, http://www.rlgsc.com
>
> This link does not seem to work from here or on the VSI website.
>
> Norman F. Raphael

> */Please reply to:/ norman....@ieee.org <mailto:norman....@ieee.org>*

> "Everything worthwhile eventually
> degenerates into real work." -Murphy
>
>

The link worked fine when posted by Bob and still works fine.

Also works fine by clicking the link on http://vmssoftware.com/.

[Jan-Erik Soderholm]

Den 2018-01-18 kl. 00:21, skrev Norman F Raphael:

> -----Original Message-----
> From: Bob Gezelter via Info-vax <info...@info-vax.com>
>
> Sent: Wed, Jan 17, 2018 5:55 pm
> Subject: [New Info-vax] OpenVMS with regards to Spectre/Meltdown
>
> >VSI has released a letter clarifying that the relevance of
> Spectre/Meltdown on OpenVMS systems (Alpha, >Itanium, and the upcoming x86-64).
> >
> >The original letter can be found at:
> http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf
> <http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf>
> >
> >- Bob Gezelter, http://www.rlgsc.com
>
> This link does not seem to work from here or on the VSI website.
>
> Norman F. Raphael

> */Please reply to:/ norman....@ieee.org <mailto:norman....@ieee.org>*

> "Everything worthwhile eventually
> degenerates into real work." -Murphy
>
>

Anyway, the text was quite short. Here it is.

--------------------------------------------
Dear customers, partners, and friends:

VMS Software, Inc. has performed extensive research into the susceptibility
of the OpenVMS platform to the Spectre and Meltdown attacks. The following
are the results of our findings:

OpenVMS on Itanium
Our Itanium research has confirmed Intel's own findings that OpenVMS on
Itanium is not susceptible.

OpenVMS on Alpha
Our Alpha research followed two inquires: Pre-EV6 Alpha and EV6-and-later
Alpha hardware.
i. OpenVMS on Pre-EV6 Alpha is not susceptible.
ii. OpenVMS on EV6-and-later Alpha is so far not susceptible, as we have
not reproduced behavior that speculatively executes load instructions that
miss the data cache. Ongoing research is being pursued to further validate
our findings for OpenVMS on EV6-and-later Alpha hardware.

OpenVMS on x86-64
Early design decisions for the x86-64 port of OpenVMS have already
mitigated the impact of the attacks on OpenVMS:
i. OpenVMS on x86-64 is not susceptible to Meltdown.
ii. OpenVMS on x86-64 has limited susceptibility to Spectre. We will work
diligently to eliminate susceptibility as we complete the port.

As always, we look forward to your feedback on this and any other
vulnerabilities in future.
----------------------------------------------

[Simon Clubley]

On 2018-01-17, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>
> OpenVMS on Itanium
> Our Itanium research has confirmed Intel's own findings that OpenVMS on
> Itanium is not susceptible.
>

And yet another thing that Itanium is not susceptible to...

And yes, I know there are whole classes of attacks which will work
just fine on Itanium. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Jan-Erik Soderholm]

Den 2018-01-18 kl. 01:30, skrev Simon Clubley:
> On 2018-01-17, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>
>> OpenVMS on Itanium
>> Our Itanium research has confirmed Intel's own findings that OpenVMS on
>> Itanium is not susceptible.
>>
>
> And yet another thing that Itanium is not susceptible to...
>
> And yes, I know there are whole classes of attacks which will work
> just fine on Itanium. :-)
>
> Simon.
>

Any attack not depending in having some specific hardware, I'd guess.

[Scott Dorsey]

In article <p3opr6$mkj$1...@dont-email.me>,

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2018-01-17, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>
>> OpenVMS on Itanium
>> Our Itanium research has confirmed Intel's own findings that OpenVMS on
>> Itanium is not susceptible.
>
>And yet another thing that Itanium is not susceptible to...

... running code at a reasonable speed...
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Bob Koehler]

In article <mailman.1.1516231358.263...@info-vax.com>, Norman F Raphael <norman....@verizon.net> writes:
> ------=_Part_26740_1385315819.1516231304551
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 7bit

>
> -----Original Message-----
>
> From: Bob Gezelter via Info-vax <info...@info-vax.com>
>
> Sent: Wed, Jan 17, 2018 5:55 pm
> Subject: [New Info-vax] OpenVMS with regards to Spectre/Meltdown
>
>>VSI has released a letter clarifying that the relevance of Spectre/Meltdown on OpenVMS systems (Alpha, >Itanium, and the upcoming x86-64).
>>
>>The original letter can be found at: http://vmssoftware.com/pdfs/news/Customer_Letter_2018_Meltdown_Spectre.pdf
>>
>>- Bob Gezelter, http://www.rlgsc.com
>
>
>
> This link does not seem to work from here or on the VSI website.

Worked for me, once I removed the %20 that copy and paste added to
the wrapped URL on my VT emulator screen.

[Stephen Hoffman]

On 2018-01-18 00:30:30 +0000, Simon Clubley said:

> On 2018-01-17, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>
>> OpenVMS on Itanium Our Itanium research has confirmed Intel's own
>> findings that OpenVMS on Itanium is not susceptible.
>
> And yet another thing that Itanium is not susceptible to...

One of the foundations of the Spectre vulnerabilities — speculative
execution leaking information — doesn't apply to Itanium. At least,
not directly. Some history...

Among some other design details and goals, VLIW / EPIC was in response
to the then-current complexity of dynamic out-of-order instruction
scheduling in processors; power, complexity, transistors, firmware,
etc. Out-of-order instruction scheduling and particularly branch
prediction was (and still is) complex and was just not working as well
as many folks would have wanted particularly back in the late 1980s and
early 1990s. VLIW / EPIC moved that scheduling and that prediction to
the compilers, and was further intended to move the dynamic scheduling
into the feedback mechanisms; into what would have been an executable
optimizer. Had the feedback mechanisms been implemented (and had
there been vulnerabilities found), we might well be looking at bugs
where the feedback was somehow co-opted and used to compromise the
processing. The performance of x86 also improved substantially;
branch prediction and speculative execution all improved performance
quite substantially.

HPE (then HP) was working on a tool known as Dynamo, as well as other
tools that were intended to optimize code execution. Tools related to
Dynamo (later DynamoRIO) never made it onto OpenVMS.

And modifying executables — whether that's called relinking,
optimization, tuning, or whatever — has some obvious security
implications. Any flaws in those approaches might well allow some
Spectre-like vulnerabilities, too. Though completely different
implementations on Itanium. But then Itanium is usually different.

Maybe VSI eventually has a look at implementing tools such as the BSD
pledge(2) call and maybe even DynamoRIO, as part of upgrading OpenVMS
security. Sandboxes and the rest of what's becoming commonplace. I
know that some of the VSI folks are aware of pledge(2), sandboxes, and
some other related techniques for upgrading the competitiveness of the
security features of OpenVMS. But that's fodder for another discussion
and another decade.

And yes, architectural-level hardware security bugs are usually
predicated on subtle flaws. Whether there are other architectural
issues? Donno. Both Itanium and Alpha are at an end, so there's not
going to be a whole lot of interest nor effort expended on those
platforms past any viable OpenVMS x86-64 port.

There's also an interesting parallel here with the design flaws exposed
by Spectre with the sorts of side-channel attacks — timing attacks,
cache attacks, etc — that arise in cryptography, but that too is a
whole 'nother discussion.

Related Reading:

https://pdfs.semanticscholar.org/79f3/016f89feb9099ae5e7f6c868993e3a4cd25d.pdf
http://www.cs.tufts.edu/comp/150IPL/papers/bala00dynamo.pdf
http://dynamorio.org
http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.html
https://en.wikipedia.org/wiki/Side-channel_attack
https://www.bearssl.org/constanttime.html


--
Pure Personal Opinion | HoffmanLabs LLC

[Norman F Raphael]

> -----Original Message-----

My apologies; it actually *did* work fine.  I expected it to display in my browser, but

instead it downloaded the PDF-file to a download directory, where I found it when the

light went on over my head ;-) .

Norman F. Raphael
Please reply to: norman....@ieee.org

[yuhong...@hotmail.com]

One good thing it did is to make PCID famous, which is also important for OpenVMS.

[Stephen Hoffman]

Multiple new crops of Spectre and Meltdown side-channels in recent
times, for those that haven't been tracking that particular mess.

Here's a recent paper on the topic:
https://arxiv.org/abs/1811.05441

At least one operating system (OpenBSD) has gone as far as disabling
hyperthreads, because of the risk of TLB-level side-channels.
https://www.mail-archive.com/source-...@openbsd.org/msg99141.html

Given Intel just announced a currently-vaporware-~2019H1 48-core
Cascade Lake AP Xeon and AMD Zen 2 announcements are due Real Soon Now
and with lots of cores, threading might be a little less interesting.
Over time, OpenVMS will almost certainly be updating its NUMA
scheduling to better deal with these processors, as the designs are
NUMA. Though these are NUMA inside a socket. Also with support for
the Intel persistent memory; Optane DC. This as have had some other
recent Intel processors. Be interesting to cache hot data in that
memory, and maybe write logs into that, whether for adding host-based
caching into OpenVMS RAID-1 support—cryptically named host-based volume
shadowing—or for application transactional activities. But I digress.
Not sure yet whether AMD Zen 2 will add PCID as will likely be required
by OpenVMS on x86-64, either. Linux 4.14 and later have started using
PCID, too. PCIDs are akin to Address Space Numbers (ASNs) on Alpha.
Gonna be interesting to ration the available 12-bit PCID assignments on
big multicore boxes, too. But I digress. Again. Hyperthreads on
Itanium works differently than on x86. OpenVMS hasn't seen a uniform
performance benefit from enabling that on Itanium. Some apps and some
loads, not others. How x86-64 works here, we shall see. But I yet
again digress. Blast it. Focus, Hoff, Focus! *Dragged back to topic*

Akin to what's been found in Intel, AMD, Arm and other processor
designs, GPU side-channels akin to Spectre and Meltdown now appear
possible:
http://www.cs.ucr.edu/~zhiyunq/pub/ccs18_gpu_side_channel.pdf

Not that OpenVMS is doing particularly much with GPUs in recent years,
with no support for OpenCL and Vulkan, and outdated OpenGL support. So
probably not a big exposure to OpenVMS folks, not until somebody gets
some GPU-based code ported and running on some controller OpenVMS
happens to support; maybe a password cracker such as hashcat or jtr
(and which should work really well against something as weak as the
OpenVMS Purdy polynomial password hash), or some code or app otherwise.
So now somebody else can swipe the results of your password
brute-forcing. The unmitigated gall of the folks potentially
co-resident on your GPU, eh?