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

[Stephen Hoffman]

On 2020-12-24 15:13:04 +0000, Comp.os.vms (also claiming to be Kerry 
Main) said:

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-review-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-POWER10-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.

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.




-- 
Pure Personal Opinion | HoffmanLabs LLC