[Info-vax] OpenVMS with regards to Spectre/Meltdown

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Thu Jan 18 10:24:12 EST 2018


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

> On 2018-01-17, Jan-Erik Soderholm <jan-erik.soderholm at 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 




More information about the Info-vax mailing list