$GETTIM and $GETTIM_PREC on modern systems
-
Topic author - Valued Contributor
- Posts: 64
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
- Status: Offline
- Contact:
$GETTIM and $GETTIM_PREC on modern systems
A question has arisen in the OpenSSL development community regarding the relative "entropy" offered by using $GETTIM and $GETTIM_PREC resolutions. This is in the context of the number of bits of resolution offered per tick of particular systems. Use of $GETTIM_PREC adds a dependency to OpenSSL when built on VMS V8.4 which precludes execution on V8.3 and less. If there is no significant gain in "bits per tick" under $GETTIM_PREC then why bother using it.
While it is imagined Alpha boxen are pretty-much passe, and only the very latest Itanium system might support higher tick rates, what is the situation with X86, and in particular hypervisors. Any *real* advantage to $GETTIM_PREC (in an "entropy generation" context)?
While a work-around has been put in place for executing OpenSSL build on V8.4 under earlier versions, it would simplify the code if $GETTIME_PREC could be eliminated completely in favour of $GETTIM and no real loss of precision bits.
While it is imagined Alpha boxen are pretty-much passe, and only the very latest Itanium system might support higher tick rates, what is the situation with X86, and in particular hypervisors. Any *real* advantage to $GETTIM_PREC (in an "entropy generation" context)?
While a work-around has been put in place for executing OpenSSL build on V8.4 under earlier versions, it would simplify the code if $GETTIME_PREC could be eliminated completely in favour of $GETTIM and no real loss of precision bits.
Re: $GETTIM and $GETTIM_PREC on modern systems
Code: Select all
> [...] Any *real* advantage to $GETTIM_PREC (in an "entropy generation"
> context)?
I know nothing, but a little experiment suggests that there's no
actual benefit on IA64 or on x86_64, but the latter CRTL could be
subject to change/improvement.
ITS $ cc /vers ! Normal compiler
VSI C V7.4-001 on OpenVMS IA64 V8.4-2L3
ITS $ sho cpu
System: ITS, HP rx2600 (1.50GHz/6.0MB)
[...]
ITS $ cc /vers ! x86_64 cross compiler
VSI C X7.4-547 (GEM 50V6F) for X86 on OpenVMS IA64 V8.4-2L3
V86 $ show system /noproc
OpenVMS E9.2 on node V86 7-JUL-2022 17:17:23.23 Uptime 31 03:00:56
V86 $ sho cpu
System: V86, VMware, Inc. VMware7,1
ITS $ type gtp.c
/* $GETTIM, $GETTIM_PREC test. */
#include <stdio.h>
#include <starlet.h>
#include <stsdef.h>
int main( int argc, char *argv)
{
int sts;
unsigned long long tim;
unsigned long long tim_pr;
sts = sys$gettim( &tim);
if ((sts & STS$M_SEVERITY) == STS$K_SUCCESS)
{
fprintf( stdout, " gettim: %016llx\n", tim);
sts = sys$gettim_prec( &tim_pr);
if ((sts & STS$M_SEVERITY) == STS$K_SUCCESS)
{
fprintf( stdout, " gettim_prec: %016llx\n", tim_pr);
fprintf( stdout, " diff: %016llx\n", (tim_pr- tim));
}
}
return sts;
}
IA64:
ITS $ r gtp
gettim: 00b775ae44c9b92f
gettim_prec: 00b775ae44c9d4ce
diff: 0000000000001b9f
ITS $ r gtp
gettim: 00b775ae45eb0753
gettim_prec: 00b775ae45eb33df
diff: 0000000000002c8c
ITS $ r gtp
gettim: 00b775ae4693a30b
gettim_prec: 00b775ae4693bbfa
diff: 00000000000018ef
ITS $ r gtp
gettim: 00b775ae471c33e1
gettim_prec: 00b775ae471c5ca6
diff: 00000000000028c5
To me, the "high precision system time" from $GETTIM_PREC looks very
like the plain-old system time from $GETTIM. At least on IA64, there's
a little variable change between the two function invocations. On
x86_64, there seldom is a difference, and, if there is one, it's always
the same, suggesting much lower resolution.
x86_64:
V86 $ r gtp_x
gettim: 00b775ae3ce51a3e
gettim_prec: 00b775ae3ce51a3e
diff: 0000000000000000
V86 $ r gtp_x
gettim: 00b775ae3d5a9811
gettim_prec: 00b775ae3d5c1eb0
diff: 000000000001869f
V86 $ r gtp_x
gettim: 00b775ae3e51c8af
gettim_prec: 00b775ae3e51c8af
diff: 0000000000000000
V86 $ r gtp_x
gettim: 00b775ae3ee7518d
gettim_prec: 00b775ae3ee8d82c
diff: 000000000001869f
ITS $ write sys$output %x0001869f
99999
I'm participating in the current E9.2 field test program, so I'll see
if anyone there has anything to say.
Last edited by sms on Thu Jul 07, 2022 11:02 pm, edited 1 time in total.
Re: $GETTIM and $GETTIM_PREC on modern systems
I had to remind myself what the high precision time is used for...
It's not so much about entropy as it's about as probable uniqueness as possible, as this is used for the nonce value.
With reference to NIST's SP 800-90A Rev 1, Section 8.6.7, which says this about the nonce requirements for a time stamp:
So the question is really, how likely is it that the time value has changed between two calls of $gettim() vs two calls of $gettim_prec() (given that some amount of other code has been executed between the calls, as is the case in OpenSSL).
Caveat: I guess we are trying to predict the future... given @sms's tests, the current likelihood of change between calls is probably not the best on X86 for the moment, but there's no saying if it'll stay that way indefinitely.
It's not so much about entropy as it's about as probable uniqueness as possible, as this is used for the nonce value.
With reference to NIST's SP 800-90A Rev 1, Section 8.6.7, which says this about the nonce requirements for a time stamp:
(this is, of course, within the same process and thread, as OpenSSL also includes their ids into the nonce, making it unique enough in that way)2. A timestamp of sufficient resolution (detail) so that it is different each time it is used.
So the question is really, how likely is it that the time value has changed between two calls of $gettim() vs two calls of $gettim_prec() (given that some amount of other code has been executed between the calls, as is the case in OpenSSL).
Caveat: I guess we are trying to predict the future... given @sms's tests, the current likelihood of change between calls is probably not the best on X86 for the moment, but there's no saying if it'll stay that way indefinitely.
Last edited by levitte on Fri Jul 08, 2022 4:24 am, edited 1 time in total.
-
Topic author - Valued Contributor
- Posts: 64
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
- Status: Offline
- Contact:
Re: $GETTIM and $GETTIM_PREC on modern systems
If a unique timestamp is the primary requirement then why not static store the previous stamp and if not different to the current value retry in a tight loop until it is. Will happen sooner (on more modern systems) or later (on less modern systems). No real cost, especially if calls to gettime() are separated by even milliseconds.
Re: $GETTIM and $GETTIM_PREC on modern systems
That sounds awfully close to another option given in the same SP 800-90A section:
4. A combination of a timestamp and a monotonically increasing sequence number, such
that the sequence number is reset when and only when the timestamp changes. For
example, a timestamp may show the date but not the time of day, so a sequence number
is appended that will not repeat during a particular day
-
Topic author - Valued Contributor
- Posts: 64
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
- Status: Offline
- Contact:
Re: $GETTIM and $GETTIM_PREC on modern systems
Too easy.
[Your message contains 9 characters.
You need to enter at least 10 characters.]
Added in 3 hours 11 minutes 22 seconds:
Something akin to...
[Your message contains 9 characters.
You need to enter at least 10 characters.]
Added in 3 hours 11 minutes 22 seconds:
Something akin to...
Code: Select all
/*
* Helper functions
* ----------------
*
* gettime() gets time using sys$gettim plus
* a monotonically increasing sequence number
*
*/
static int gettime(unsigned __int64 *t)
{
static int gettim_sequence_no = 0;
return sys$gettim((void *)t) + gettim_sequence_no++;
}
Re: $GETTIM and $GETTIM_PREC on modern systems
Code: Select all
> To me, the "high precision system time" from $GETTIM_PREC looks very
> like the plain-old system time from $GETTIM. [...]
No new authoritative info, but...
No doubt I'm more amazed than I should be, but the actual
documentation ("System Services Reference Manual: A-GETUAI") has more
useful info than HELP System_Services $GETTIM.
https://docs.vmssoftware.com/vsi-openvms-system-services-reference-manual-a-getuai/#JUN_317
https://docs.vmssoftware.com/vsi-openvms-system-services-reference-manual-a-getuai/#_4527GETTI_PREC
Notable bits:
The quadword is the number of 100-nanosecond intervals since
November 17, 1858.
On Alpha and Integrity server systems, the exact frequency at
which system time is updated varies, depending on the
characteristics of the server; however the update frequency is
approximately 1 millisecond.
On Alpha, [$GETTIM_PREC] is equivalent to $GETTIM service and just
returns the last updated system time. The successful completion
status of the service on ALPHA is SS$_LOWPREC.
Treating 99999 as 100000, 100000 * 100ns = 10ms, so (currently) on
x86_64, "the update frequency" ("period", actually) appears to be more
like 10ms than 1ms.
But all signs suggest that on all non-VAX systems, not only Alpha,
$GETTIM and $GETTIM_PREC are equivalent.
> Something akin to...
> [...]
> static int gettim_sequence_no = 0;
> return sys$gettim((void *)t) + gettim_sequence_no++;
Distant cousin, perhaps. I might say more like:
unsigned __int64 gt;
int sts;
static int gettim_sequence_no = 0;
sts = sys$gettim( >); /* Error handling? (What could go wrong?) */
gt = (gt << 8)| gettim_sequence_no;
gettim_sequence_no = (gettim_sequence_no+ 1)& 0xff;
return gt;
Unlikely to get called 256 times between sys$gettim() updates?
Code: Select all
> Unlikely to get called 256 times between sys$gettim() updates?
Of course, if uniqueness is the real goal, then there's no reason not
to shove more (always identical, for reasonable values of "always") bits
off the high end of the time, and combine the remains with a wider
counter.
But, more important, for "A combination of a timestamp and a
monotonically increasing sequence number", simple addition is _not_ how
I'd interpret "combination".
-
- Valued Contributor
- Posts: 73
- Joined: Tue Mar 22, 2022 6:47 pm
- Reputation: 0
- Location: England
- Status: Offline
Re: $GETTIM and $GETTIM_PREC on modern systems
Absolutely not. If time updates at T and T+t, then simply adding a monotonically increasing sequence number, n could lead to the situation where n=t and so you would get the same value for the nonce. See SP 800-90A where it says "a sequence number is appended that will not repeat" (my emphasis).
As a manufactured example (using Linux tools I'm still awaiting a community VMS licence for x86_64) returns 1657308013, so the first few nonces would have to be 165730801300, 165730801301, 165730801302
As a manufactured example (using Linux tools I'm still awaiting a community VMS licence for x86_64)
Code: Select all
date "+%s"
Martin
- Retired System Manager: VMS/UNIX/UNICOS/Linux.
- Started on a VAX 11/782 in 1984 with VMS 3.6.
Re: $GETTIM and $GETTIM_PREC on modern systems
Code: Select all
> Absolutely not. [...]
"Absolutely not" _what_, exactly?
> [...] I'm still awaiting a community VMS licence for x86_64)
I know nothing, but the recent e-mail announcement on the V9.2
release said "Scheduled for July 14, 2022", and "The V9.2 kit, open
source, and layered products will be distributed to customers through
the Service Portal, similar to the field test versions.", which sounds
to me as if the Community is _not_ (yet) included.
-
- Valued Contributor
- Posts: 73
- Joined: Tue Mar 22, 2022 6:47 pm
- Reputation: 0
- Location: England
- Status: Offline
Re: $GETTIM and $GETTIM_PREC on modern systems
'simple addition is _not_ how I'd interpret "combination"' - Absolutely not. As I went on to illustrate simple addition is (i) flawed and (ii) contrary to SP 800-90A which talks about appending.
Martin
- Retired System Manager: VMS/UNIX/UNICOS/Linux.
- Started on a VAX 11/782 in 1984 with VMS 3.6.