Make openVMS seeding less dependent of OpenVMS version [1.1.1]

[levitte]

SYS$GETTIM_PREC is a very new function, only available on OpenVMS v8.4.
OpenSSL binaries built on OpenVMS v8.4 become unusable on older OpenVMS
versions, but building for the older CRTL version will make the high
precision time functions unavailable.

Tests have shown that on Alpha and Itanium, the time update granularity
between SYS$GETTIM and SYS$GETTIM_PREC is marginal, so the former plus
a sequence number turns out to be better to guarantee a unique nonce.

Fixes #18727

[t8m]

I am unsure whether this is a bug fix or a feature.

[levitte]

It's a regression... before introducing the call of sys$gettim_prec(), it was perfectly possible to build OpenSSL on any OpenVMS version and have it run with any OpenVMS from v7.1 and up, as far as I recall. Suddenly, you cannot build on OpenVMS v8.4 and expect it to run on older versions.

In OpenVMS land, this isn't a strange concept, especially when you have clusters with multiple OpenVMS versions in mind.

@mgdaniel, feel free to correct me if I remember things wrong...

[levitte]

The call of sys$gettim_prec() was introduced in the development that became 1.1.1 (i.e. the first 1.1.1 release).

[mgdaniel]

The call of sys$gettim_prec() was introduced in the development that became 1.1.1 (i.e. the first 1.1.1 release).

Agreed. And I do not imagine it adds significant entropy to the the mix. The difference between $gettime() and $gettim_prec() must (currently) be minimal at best and in the future a few bits of resolution.

[mgdaniel]

I am unsure whether this is a bug fix or a feature.

I put it in as a bug fix because it prevented execution on less recent versions of VMS. Not a feature.

[mgdaniel]

It's a regression... before introducing the call of sys$gettim_prec(), it was perfectly possible to build OpenSSL on any OpenVMS version and have it run with any OpenVMS from v7.1 and up, as far as I recall. Suddenly, you cannot build on OpenVMS v8.4 and expect it to run on older versions.

In OpenVMS land, this isn't a strange concept, especially when you have clusters with multiple OpenVMS versions in mind.

@mgdaniel, feel free to correct me if I remember things wrong...

With SYS$GET_ENTROPY becoming available I believe SYS$GETTIM_PREC could easily be eliminated completely in favour of SYS$GETTIM with no effective/significant loss of entropy all-told, thus immediately eliminating the backward compatibility issue.

[levitte]

The call of sys$gettim_prec() was introduced in the development that became 1.1.1 (i.e. the first 1.1.1 release).

Agreed. And I do not imagine it adds significant entropy to the the mix. The difference between $gettime() and $gettim_prec() must (currently) be minimal at best and in the future a few bits of resolution.

So what you're saying is that the call of sys$gettim_prec() could just as well be dropped? 'cause yeah, the resulting time is a count of 100ns units either way, so the "tick" update difference between sys$gettim() and sys$gettim_prec() is probably not dramatic for this sort of use...

[mgdaniel]

The call of sys$gettim_prec() was introduced in the development that became 1.1.1 (i.e. the first 1.1.1 release).

Agreed. And I do not imagine it adds significant entropy to the the mix. The difference between $gettime() and $gettim_prec() must (currently) be minimal at best and in the future a few bits of resolution.

So what you're saying is that the call of sys$gettim_prec() could just as well be dropped? 'cause yeah, the resulting time is a count of 100ns units either way, so the "tick" update difference between sys$gettim() and sys$gettim_prec() is probably not dramatic for this sort of use...

Agreed. Certainly not significant with the current range of (rather passe) Alphas, and most Itanics (AIUI). The current crop of X86 systems/hypervisors; who knows what the TOD/interrupt clock will be doing. Perhaps we should ask VSI about hypervisor interrupt/timer resolution.

[mgdaniel]

Perhaps we should ask VSI about hypervisor interrupt/timer resolution.

https://forum.vmssoftware.com/viewtopic.php?f=21&t=8509

[mgdaniel]

Perhaps we should ask VSI about hypervisor interrupt/timer resolution.

https://forum.vmssoftware.com/viewtopic.php?f=21&t=8509

The upshot of asking this question (ignoring the hypervisor element) is that there is no (current) effective difference between the result of the two calls. This combined with your own SP 800-90A section 4 observation suggests that SYS$GETTIM_PREC may be eliminated while still maintaining compliance.

Suggest you get coding 😁

[mgdaniel]

And to give your a start, this seems to work:

/*
 *  NIST's SP 800-90A Rev 1, Section 8.6.7
 *  4. A combination of a timestamp and a monotonically increasing sequence number...
 */

static int gettime(unsigned __int64 *t)
{
    static unsigned __int64 seqnum = 0;
    unsigned __int64 t64;
    int  status;

    status = sys$gettim((void *)&t64);
    *t = (t64 & ~0Xff) | (seqnum++ & 0xff);
    return status;
}

[openssl-machine]

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

[hlandau]

Approving for reasons given in #18731.

[openssl-machine]

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

[levitte]

I'm reworking this change the same way I did #18731, i.e. forego SYS$GETTIM_PREC

[levitte]

Reworked. @mgdaniel, sorry that this took time to get back to. Would you be willing to test this (and by all means, #18731 too!)?

[hlandau]

One nit. Otherwise, looks OK.

[mgdaniel]

On Tue, 25 Oct 2022 04:49:14 -0700 ***@***.*** wrote: Reworked. @mgdaniel, sorry that this took time to get back to. Would you be willing to test this (and by all means, #18731 too!)?

Sure Richard. Can you provide web links into the final rand_vms.c(s)?

…

-- Reply to this email directly or view it on GitHub: #18730 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[levitte]

https://raw.githubusercontent.com/openssl/openssl/d100d5b52213963bc86dce460226b2b4bef980bf/crypto/rand/rand_vms.c

That's for 1.1.1. I'll get you the same separately in #18731 for 3.0

Sure Richard. Can you provide web links into the final rand_vms.c(s)?

[levitte]

Merged

aa542d2 Make openVMS seeding less dependent of OpenVMS version