[Info-vax] VMS Software needs to port VAX DIBOL to OpenVMS X86 platform

[kemain.nospam at gmail.com]

> -----Original Message-----
> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Stephen
> Hoffman via Info-vax
> Sent: December-24-20 4:27 PM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] VMS Software needs to port VAX DIBOL to OpenVMS
> X86 platform
> 
> On 2020-12-24 15:13:04 +0000, Comp.os.vms (also claiming to be Kerry
> Main) said:
> 

Oops .. new laptop email setup error.

> Large memory: Haven't heard much call for server configurations larger than
> the current 128 PiB configuration limit for x86-64.
> 
> HPE never added OpenVMS support for the top-end Integrity Itanium
> servers, and it seems unlikely that VSI would add that support now.
> 
> Memory Encryption: Already available on AMD x86-64, and single-tenant
> configurations are prolly going to preferred by most OpenVMS sites for other
> reasons.
> 
> AES assists: there've been ongoing improvements across most (all?)
> platforms, and no reason to assume those hardware updates won't
> continue.
> 
> There's a pile of security-related stuff missing from OpenVMS.
> Detailed which memory encryption and AES support won't address.
> 
> Like a lack of full-device storage encryption (FDE), an encrypted keystore,
> memory compression to public certificate root certs, ASLR/KASLR, continuing
> the W^X work, etc.
> 
> Writing secure apps is a pain in the arse on OpenVMS, and I know how to do
> it. Retrofitting apps for security is yet harder.
> 
> The OpenVMS security doc is scattershot and largely reflective of the last
> millennium.
> 
> Lots of work ahead for VSI, here. Lots of work. For third-parties and end-
> developers, too.
> 
> Memory compression and memory encryption and AES assists are nice to
> have, but there are rather more fundamental omissions awaiting within
> OpenVMS.
> 
> 
> > Some 🤡 wrote:
> >>
> >> And once all that's well along, y'all will prolly be busy porting to
> >> the descendants of this Arm server:
> >> https://www.servethehome.com/ampere-altra-wiwynn-mt-jade-server-
> revie
> >> w-the-most-significant-arm-server/
> >>
> >>
> >
> > Well, its an age-old discussion, but if there ever was a vote for what
> > VSI platform comes next after X86-64, my vote would be the Power10+
> > architecture - not ARM.
> 
> Systems based on POWER are very nice, but are comparatively expensive,
> low-volume, and rare. And POWER is not on the best trend, by all
> appearances.
> 
> > One big differentiator I believe for both existing and new OpenVMS
> > Customers would be the huge level of HW based security encryption
> > built into the architecture.
> > <https://newsroom.ibm.com/2020-08-17-IBM-Reveals-Next-Generation-
> IBM-P
> > OWER10-Processor>
> >
> 
> Memory compression support and memory encryption and AES support
> aren't particularly innovative.  Related:
> https://www.kernel.org/doc/html/latest/x86/amd-memory-encryption.html
> https://lwn.net/Articles/699820/
> 
> Intel has decided to join the fray here, too:
> https://arstechnica.com/gadgets/2020/02/intel-promises-full-memory-
> encryption-in-upcoming-cpus/
> 
> 
> And for a keystore, there's the TPM hardware:
> https://en.wikipedia.org/wiki/Trusted_Platform_Module
> OpenVMS lacks a software keystore, so that's been a fairly wide-open mess
> for most OpenVMS apps for a while.
> 
> Here's a decent overview of mobile platform hardware security, an
> environment which is more prone to physical theft and to physical access
> than is (most of) server security:
> https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/apple-
> platform-security-guide.pdf
> 
> 
> Intel SGX has been discussed before, though its security has proven
> problematic:
> https://software.intel.com/content/www/us/en/develop/blogs/protecting-
> application-secrets-with-intel-sgx.html
> 
> 
> Arm Trustzone:
> https://genode.org/documentation/articles/trustzone
> 
> Amazon Graviton2 (based on the Arm Neoverse N1 cores) supports memory
> encryption, as well:
> https://aws.amazon.com/ec2/graviton/
> This for folks that aren't single-tenant.
> 
> Microsoft is tweaking Qualcomm processor designs based on Snapdragon
> 8cx cores, with SQ1 and SQ2, for their Windows 10 on Arm Surface Pro X
> configurations. Arm has rather newer cores available such as the
> Neoverse cores mentioned earlier, and the Apple M1 design is both
> seriously fast and seriously efficient. And Arm servers are on a better
> trend than those based on IBM POWER, by all appearances.
> 
> If you're interested in platforms specifically targeting security,
> OpenBSD, seL4, and maybe Geode, will be of interest:
> http://www.openbsd.org/security.html
> https://sel4.systems
> https://genode.org/documentation/general-overview/index
> 
> OpenVMS tends to be single-tenant or single-organization per server,
> which makes memory encryption somewhat less interesting. Memory
> encryption is rather more interesting when you're on a mobile
> battery-powered device, or your physical servers are subject to
> physical seizure, or when sharing a virtual host with an untrusted app
> or service or guest, and OpenVMS has other issues there—OpenVMS
> security documentation and features have long discouraged network and
> server sharing, going back to the now-ancient NCSC security evaluations
> and earlier. And encrypting memory or storage data (FDE) when there's
> background activity is far from trivial in general, as those encryption
> keys have to be available somewhere. Encrypting storage is rather
> easier in that regard such as what can be available with Apple T2
> storage encryption—but those keys are still necessary.
> 
> TL;DR: would I like memory encryption? Sure. Would I like frameworks
> and upgrades to make creating secure connections easier, and for
> securing passwords, and for better managing certs and cert chains? FDE?
> Better installers? Telemetry? Yes. And I'd prefer the latter features
> to memory encryption, too. Multi-tenant servers can be avoided. TLS
> connections and server storage swaps, not so much.
> 
> > Another feature would be next gen large memory support.
> 
> Intel x86-64 has had 57-bit (128 PiB) five-level page table addressing
> support for a while.
> 
> As for the sorts of large-hardware configurations available for folks
> running OpenVMS, HPE never added OpenVMS support for the top-end
> Itanium servers. Which implies that most OpenVMS usage is arguably
> mid-range when compared across the current computing environment.
> While
> we might see HPE Integrity x86-64 server support added at some future
> date, but top-end HPE Integrity Itanium server support for VSI OpenVMS
> seems an unlikely addition at this late date.
> 
> There's also good evidence that faster storage connections and faster
> memory connections can offset smaller physical memory configurations,
> too. q.v. Apple M1. Expect to see some app assumptions and app design
> preferences shift with OpenVMS on x86-64 due to differences in speeds
> and feeds, and to shift again with whatever servers might follow in the
> future. Big memory was somewhere between nice and necessary with HDD
> storage, but NVMe such as that found on many x86-64 systems and on that
> Ampere Altra Mt Jade Arm server is far faster.  Trade-offs always shift.
> re-post:
> https://www.servethehome.com/ampere-altra-wiwynn-mt-jade-server-
> review-the-most-significant-arm-server/
> 
> 
> And of course, it's never easy. There are seemingly always corner cases
> and creative surprises awaiting any architectural changes:
> https://github.com/Tencent/rapidjson/issues/1596
> 
> As for IBM: Over the next ten years, I'm less than ebullient about the
> prospects for IBM as a business, and for POWER as an architecture. IBM
> itself is aiming for "cloud" and "AI", and have spun off their services
> and support businesses among other changes. The IBM mainframe business
> aside, POWER looks far too much like another evolution of the DEC Alpha
> and Sun SPARC business plans and partnerships. POWER is nice, but
> myriads of elegant architectures have been available over the years.
> And OpenVMS isn't big in ML.
> 

Regardless of which is the next OpenVMS server platform after X86-64, the current challenges for OpenVMS will need to be addressed - no one is arguing this.

However, given similar past arguments about addressing marketing and technical challenges, if one only sees the glass as half-empty, VSI would never have decided to do the X86-64 port.

> As for DIBOL and the original thread, if y'all are dependent on what
> Synergex provides, VSI isn't going to be able to help there. Not
> without investing a whole lot in new and competitive DIBOL compiler.
> And VSI likely doesn't have the old VAX DIBOL bits as a foundation,
> which means more work. And I don't see an open-source alternative.
> Which means migrating to DIBOL/DBL on a different platform, or adding
> Synergex support on OpenVMS, or translating to a different language and
> refactoring and using that. (I know a vendor that used their own DSL
> and then sold "source code access" which was "source code" generated
> from the DSL, so there's that approach, too; always operating through
> the translation. Wouldn't be my choice, but I've encountered it.) No
> good choice here, if Synergex doesn't meet your (thread OP)
> requirements.
> 

Synergex stated earlier in this thread they had not yet made any decision about OpenVMS X86-64 as a platform.

I would suggest those Customers with DIBOL/OpenVMS solutions wait until Synergex have had a chance to do the evaluation. Sure, let Synergex know your preferences, but If the Synergex work required to do the OpenVMS DIBOL port to X86-64 is not that large, then it might be an easy option for them. Same is likely true for other vendors and partners.

The easier the port, the less overall partner costs and the easier it is to justify adopting a new server hardware platform. That is really the key message to adopting new server platforms in the future.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com





-- 
This email has been checked for viruses by AVG.
https://www.avg.com