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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
