Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

[John Stultz]

On Tue, Jun 21, 2016 at 11:05 AM, Stephan Mueller <smueller@xxxxxxxxxx> wrote:
> As part of the Y2038 development, __getnstimeofday is not supposed to be
> used any more. It is now replaced with ktime_get_raw_ns. Albeit
> ktime_get_raw_ns is monotonic compared to __getnstimeofday, this
> difference is irrelevant as the Jitter RNG uses the time stamp to
> measure the execution time of a given code path and tries to detect
> variations in the execution time. Therefore, the only requirement the
> Jitter RNG has, is a sufficient high resolution to detect these
> variations.
>
> The change was tested on x86 to show an identical behavior as RDTSC. The
> used test code simply measures the execution time of the heart of the
> RNG:
>
>         jent_get_nstime(&time);
>         jent_memaccess(ec, min);
>         jent_fold_time(NULL, time, &folded, min);
>         jent_get_nstime(&time2);
>         return ((time2 - time));
>
> Signed-off-by: Stephan Mueller <smueller@xxxxxxxxxx>
> ---
>  crypto/jitterentropy-kcapi.c | 23 ++++++++++++++---------
>  1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/crypto/jitterentropy-kcapi.c b/crypto/jitterentropy-kcapi.c
> index 597cedd..69a2988 100644
> --- a/crypto/jitterentropy-kcapi.c
> +++ b/crypto/jitterentropy-kcapi.c
> @@ -87,24 +87,29 @@ void jent_memcpy(void *dest, const void *src, unsigned int n)
>         memcpy(dest, src, n);
>  }
>
> +/*
> + * Obtain a high-resolution time stamp value. The time stamp is used to measure
> + * the execution time of a given code path and its variations. Hence, the time
> + * stamp must have a sufficiently high resolution. It is valid if the time
> + * runs backwards for short period of time as the RNG code is able handle that.
> + *
> + * Note, if the function returns zero because a given architecture does not
> + * implement a high-resolution time stamp, the RNG code's runtime test
> + * will detect it and will not produce output.
> + */
>  void jent_get_nstime(__u64 *out)
>  {
> -       struct timespec ts;
>         __u64 tmp = 0;
>
>         tmp = random_get_entropy();
>
>         /*
> -        * If random_get_entropy does not return a value (which is possible on,
> -        * for example, MIPS), invoke __getnstimeofday
> +        * If random_get_entropy does not return a value, i.e. it is not
> +        * implemented for a given architecture, invoke ktime_get_raw_ns
>          * hoping that there are timers we can work with.
>          */
> -       if ((0 == tmp) &&
> -          (0 == __getnstimeofday(&ts))) {
> -               tmp = ts.tv_sec;
> -               tmp = tmp << 32;
> -               tmp = tmp | ts.tv_nsec;
> -       }
> +       if (tmp == 0)
> +               tmp = ktime_get_raw_ns();


I don't see in the above an explanation of *why* you're using
ktime_get_raw_ns() instead of ktime_get_ns().

Also the bit about time running backwards being ok is confusing since
you're not using the "fast" accessor where that would be a risk.

thanks
-john