[Info-vax] The Road to V9.0

[johnwallace4 at yahoo.co.uk]

On Thursday, 10 October 2019 13:25:39 UTC+1, Simon Clubley  wrote:
> On 2019-10-10, clair.grant at vmssoftware.com <clairgrant71 at gmail.com> wrote:
> > Below is a recent log from booting the system and executing a few commands and running SDA. (I edited out a bunch of our own debugging messages, otherwise it is the exact screen capture of a real system boot.) Two major things about to round into shape are 1) switching from the memory disk to the real system disk and 2) now that basic exception handling is in place, fleshing out the condition handlers and signaling.
> >
> 
> [I've changed the subject line back to its original one.]
> 
> Ok, now this is starting to look _seriously_ interesting. :-)
> 
> Very well done on getting this far. When do you think we might start
> seeing some of the user level applications, such as EDT or EVE, running
> and a x86 node join a cluster ?
> 
> >
> >         VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, XFBG-N4A
> >
> >                     Copyright 2019 VMS Software, Inc.
> >
> >   MDS Mitigation active, variant verw(MD_CLEAR)
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> That caught my attention. Which of the other architectural level
> vulnerabilities you have had to mitigate against on VMS ?
> 
> For anyone wondering what this is all about, the following shows the
> steps Red Hat have taken to mitigate against this:
> 
> https://www.redhat.com/en/blog/understanding-mds-vulnerability-what-it-why-it-works-and-how-mitigate-it
> 
> Thanks for the update Clair,
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

I'm not sure I'd class MDS as an "architectural" vulnerability 
but I'd speculate that others may disagree. It looks a lot like
an Intel-specific implementation issue in my book. 

Fwiw, I spent half an hour or more reading summaries and 
white papers and watching a Red Hat talking head (why provide a 
YouTube talking head when a paper or even a transcript would
be indexable, searchable, etc???) before I reverted to the 
MDSattacks FAQ at
https://mdsattacks.com/
which currently includes the following text:
"Am I affected?

Very likely. Our attacks affect all modern Intel CPUs in servers, desktops and laptops. This includes the latest 9th-generation processors, despite their in-silicon mitigations for Meltdown. Ironically, 9th-generation CPUs are more vulnerable to some of our attacks compared to older generation hardware.

Processors from other vendors (AMD and ARM) do not appear to be affected. Official statements from these vendors can be found in the RIDL and Fallout papers."

I'll repeat the important bit: 
"Processors from AMD and ARM do not appear to be affected."

And over at
https://www.securityweek.com/intel-mds-vulnerabilities-what-you-need-know
it is written that POWER and SPARC architectures are not 
affected.

So for the moment it's looking like it's just Intel's own 
x86(64) implementations that are broken (again?). 

To me it sounds once again like Intel's attempts to deliver
ever-faster x86-compatible silicon, which seem to lead to
chip designers discarding important security-relaed attributes 
of data and instructions and other stuff which needs extra 
care in a world of speculative execution and branch prediction
and out of order execution and cacheable vs noncacheable 
regions and various other such 'modern' delights, without 
a clean model for architectural consistency of registers, 
memory, interfaces, read and write ordering, privileged
hardware (including hi-res timers), and generally a lack 
of attention to "rolling back the speculative changes to 
visible state", have once again come back to bite the world 
of Intel x86 dependent hardware and software and people.

But it's easy for me to say that.

In passing: Has anybody noticed what happens if you try 
searching for 
"How do MDS attacks affect VMS"

There's a reason I started referring to VSIVMS a while 
back :)