[Info-vax] Why it is a good idea that OpenVMS isn't on x86-64 just yet

[johnwallace4 at yahoo.co.uk]

On Friday, 15 January 2016 13:46:43 UTC, Jan-Erik Soderholm  wrote:
> Den 2016-01-15 kl. 14:02, skrev Craig A. Berry:
> > On 1/15/16 6:16 AM, Neil Rieck wrote:
> >> Why it is a good idea that OpenVMS isn't on x86-64 just yet
> >>
> >> Skylake bug causes Intel chips to freeze under 'complex workloads'
> >>
> >> http://www.extremetech.com/computing/220953-skylake-bug-causes-intel-chips-to-freeze-in-complex-workloads
> >>
> >
> > Might be good we don't have OpenSSH yet either:
> >
> > http://seclists.org/oss-sec/2016/q1/97
> >
> >
> >
> 
> I the first case (Skylark) it is quite unlikely that any typical
> OpenVMS environment/application would be hit by this. And it seems
> to only have been seen when running an application called "Prime95":
> 
> "Prime95 is the freeware application written by George Woltman that
> is used by GIMPS, a distributed computing project dedicated to
> finding new Mersenne prime numbers".
> 
> https://en.wikipedia.org/wiki/Mersenne_prime
> 
> 
> In the second case, it is an OpenSSH *client* problem that also
> needs an compromised OpenSSH server to be exploited. And the
> fix is easy and (now) documentet. Also see the part saying:
> 
> "This information leak affects all OpenSSH clients >= 5.4, but its
> impact is slightly reduced by the following four reasons:..."

Reading the Skylake link from Craig, and knowing what I know, it
seems far more likely that Prime95 is the only *publically
admitted* application that shows the symptoms. If it can happen
somewhat reproducibly in a user mode memory bound number crunching
application like Prime95, who knows where else it will happen, but
in many cases it may be somewhat less reproducible.

The Prime95 people even acknowledge that their application is a
useful somewhat-reproducible system stress tester which will
happily exercise integer and floating arithmetic in parallel, 
and which is in theory capable of making reasonable use of
things like symmetric multi-threading. And so on.

Now, if a Window box misbehaves, how do you diagnose it?
IT department favourite: don't diagnose, reboot and re-run. 
Fair enough if it fixes things. If it doesn't fix things,
re-install. If that doesn't work, swap the whole box. Rinse
and repeat, till either boredom sets in or it finally becomes
clear that there *is* an underlying problem.

Much the same for a Linux box? (No idea for OS/X, it's not my scene).

On the other hand, over the decades, VMS systems have had a variety of
obscure hardwareish bugs, some of which have reached real customers
in the field. VMS has a variety of system level tools which can be 
used to record (and later analyse) portions of system state when
things misbehave. There used to be (and maybe still are) people who
could look at crash dumps and such like and shed some light on what
had been happening.

If, over the years, those bugs have been fed back and resulted in
extra test cases (for use either at design time and/or for in systems)
then the existence of VMS on x86-64 *might* have *prevented* this
latest bug reaching the field.

Hopefully the ex-Tandem people have this kind of thing sorted, now
that x86-64 is going into Integrity servers.