$GETTIM and $GETTIM_PREC on modern systems


Topic author
mgdaniel
Contributor
Posts: 22
Joined: Mon Feb 28, 2022 5:16 pm
Reputation: 0
Location: Adelaide, South Australia
Status: Offline
Contact:

$GETTIM and $GETTIM_PREC on modern systems

Post by mgdaniel » Thu Jul 07, 2022 2:35 pm

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.


sms
Valued Contributor
Posts: 66
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Re: $GETTIM and $GETTIM_PREC on modern systems

Post by sms » Thu Jul 07, 2022 11:01 pm

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.


levitte
Newbie
Posts: 3
Joined: Fri Jul 08, 2022 2:05 am
Reputation: 0
Status: Offline

Re: $GETTIM and $GETTIM_PREC on modern systems

Post by levitte » Fri Jul 08, 2022 2:25 am

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:
2. A timestamp of sufficient resolution (detail) so that it is different each time it is used.
(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)

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
mgdaniel
Contributor
Posts: 22
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

Post by mgdaniel » Fri Jul 08, 2022 4:15 am

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.


levitte
Newbie
Posts: 3
Joined: Fri Jul 08, 2022 2:05 am
Reputation: 0
Status: Offline

Re: $GETTIM and $GETTIM_PREC on modern systems

Post by levitte » Fri Jul 08, 2022 4:24 am

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
mgdaniel
Contributor
Posts: 22
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

Post by mgdaniel » Fri Jul 08, 2022 5:41 am

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

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++;
}


sms
Valued Contributor
Posts: 66
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Re: $GETTIM and $GETTIM_PREC on modern systems

Post by sms » Fri Jul 08, 2022 1:34 pm

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( &gt);   /* 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?
Added in 52 minutes 44 seconds:

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".


martin
Contributor
Posts: 13
Joined: Tue Mar 22, 2022 6:47 pm
Reputation: 0
Location: England
Status: Offline

Re: $GETTIM and $GETTIM_PREC on modern systems

Post by martin » Fri Jul 08, 2022 3:24 pm

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)

Code: Select all

date "+%s"
returns 1657308013, so the first few nonces would have to be 165730801300, 165730801301, 165730801302
Retired System Manager VMS/UNIX/Linux. Started on a VAX 11/782 with VMS 3.6.


sms
Valued Contributor
Posts: 66
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Re: $GETTIM and $GETTIM_PREC on modern systems

Post by sms » Fri Jul 08, 2022 5:22 pm

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.


martin
Contributor
Posts: 13
Joined: Tue Mar 22, 2022 6:47 pm
Reputation: 0
Location: England
Status: Offline

Re: $GETTIM and $GETTIM_PREC on modern systems

Post by martin » Fri Jul 08, 2022 5:39 pm

'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.
Retired System Manager VMS/UNIX/Linux. Started on a VAX 11/782 with VMS 3.6.

Post Reply