* Re: [Y2038] [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback
From: Arnd Bergmann @ 2016-06-21 19:37 UTC (permalink / raw)
To: y2038
Cc: John Stultz, Stephan Mueller, Herbert Xu, Alexander Kuleshov,
lkml, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <CALAqxLW-TKy2CpTst=AtJY8JNGYg_WB0MxTU3Kf4J6ijKCtBVA@mail.gmail.com>
On Tuesday, June 21, 2016 12:05:06 PM CEST John Stultz wrote:
> On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller <smueller@chronox.de> wrote:
> > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
> >
> > Hi John,
> >
> >> I don't see in the above an explanation of *why* you're using
> >> ktime_get_raw_ns() instead of ktime_get_ns().
> >
> > Could you help me understand what the difference is or point me to some
> > documentation? I understood that we only talked about the _raw variant.
>
> Using specialized interfaces with subtle semantics w/o understanding
> them is sort of my concern here.
>
> There are reasons why you might want to use the ktime_get_raw_ns()
> interface over ktime_get_ns(), but they have not been made clear in
> the comment. Arnd discussed some potential concerns that the freq
> adjustment done by ntp might be somewhat predictable/controlled by
> remote parties, which could have some effect in the calculation. That
> feels a little overly vague to me, but I'm no crypto expert, so if
> that is a reasonable concern, then it should be a conscious and
> documented decision.
My original patch changed __getnstimeofday() to __getnstimeofday64(),
which kept the original semantics of not warning in case the clock
source is suspended (which is the only different to the normal
getnstimeofday{,64}().
I did the patch a while time ago along with a number of other patches
that I never sent out until last week, so I don't remember the
reasoning for suggesting ktime_get_raw_fast_ns() over ktime_get_raw_ns(),
but I sure wanted to keep the non-warning behavior, and ktime_get_ns()
warns on timekeeping_suspended() while the other two don't.
If we don't care about the non-warning aspect, ktime_get_ns() makes
most sense here, and the original code should probably have used
getnstimeofday() as well.
Arnd
^ permalink raw reply
* Re: [PATCH v4 0/5] /dev/random - a new approach
From: Austin S. Hemmelgarn @ 2016-06-21 19:31 UTC (permalink / raw)
To: Stephan Mueller
Cc: Theodore Ts'o, David Jaša, Andi Kleen, sandyinchina,
Jason Cooper, John Denker, H. Peter Anvin, Joe Perches,
Pavel Machek, George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <1900555.p3fYFz9p7D@positron.chronox.de>
On 2016-06-21 14:04, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn:
>>>> 6. You have a significant lack of data regarding embedded systems, which
>>>> is one of the two biggest segments of Linux's market share. You list no
>>>> results for any pre-ARMv6 systems (Linux still runs on and is regularly
>>>> used on ARMv4 CPU's, and it's worth also pointing out that the values on
>>>> the ARMv6 systems are themselves below average), any MIPS systems other
>>>> than 24k and 4k (which is not a good representation of modern embedded
>>>> usage), any SPARC CPU's other than UltraSPARC (ideally you should have
>>>> results on at least a couple of LEON systems as well), no tight-embedded
>>>> PPC chips (PPC 440 processors are very widely used, as are the 7xx and
>>>> 970 families, and Freescale's e series), and only one set of results for
>>>> a tight-embedded x86 CPU (the Via Nano, you should ideally also have
>>>> results on things like an Intel Quark). Overall, your test system
>>>> selection is not entirely representative of actual Linux usage (yeah,
>>>> ther'es a lot of x86 servers out there running Linux, there's at least
>>>> as many embedded systems running it too though, even without including
>>>> Android).
>>>
>>> Perfectly valid argument. But I programmed that RNG as a hobby -- I do not
>>> have the funds to buy all devices there are.
>>
>> I'm not complaining as much about the lack of data for such devices as I
>> am about you stating that it will work fine for such devices when you
>> have so little data to support those claims. Many of the devices you
>
> Little data, interesting statement for results on 200+ systems including all
> major CPU arches all showing information leading in the same directions.
Let me try rephrasing this to make it a bit clearer:
1. You have lots of data on server systems.
2. You have a significant amount of data on desktop/workstation type
systems.
3. You have very little data on embedded systems.
and here are your arguments:
A. This works well on server systems.
B. This works well on desktop systems.
C. This works well on embedded systems.
Arguments A and B are substantiated directly by points 1 and 2.
Argument C is not substantiated thoroughly because of point 3.
My complaint is about argument C given point 3.
I'm not saying you have insufficient data to support argument A or B,
only that you have insufficient data to support argument C.
Android barely counts as an embedded system anymore, as many Android
phones can outperform most inexpensive desktop and laptop systems, and
even some rather expensive laptops. This leaves the only systems that
can be assumed without further information to be representative of
embedded boards to be the ones running Genode, and possibly the MIPS
systems, which is a total of about 10 results out of hundreds for
servers and desktops/workstations.
^ permalink raw reply
* Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback
From: John Stultz @ 2016-06-21 19:05 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Arnd Bergmann, Alexander Kuleshov, y2038 Mailman List,
lkml, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <1724645.8YjKaqazLv@positron.chronox.de>
On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
>
> Hi John,
>
>> I don't see in the above an explanation of *why* you're using
>> ktime_get_raw_ns() instead of ktime_get_ns().
>
> Could you help me understand what the difference is or point me to some
> documentation? I understood that we only talked about the _raw variant.
Using specialized interfaces with subtle semantics w/o understanding
them is sort of my concern here.
There are reasons why you might want to use the ktime_get_raw_ns()
interface over ktime_get_ns(), but they have not been made clear in
the comment. Arnd discussed some potential concerns that the freq
adjustment done by ntp might be somewhat predictable/controlled by
remote parties, which could have some effect in the calculation. That
feels a little overly vague to me, but I'm no crypto expert, so if
that is a reasonable concern, then it should be a conscious and
documented decision.
thanks
-john
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback
From: Stephan Mueller @ 2016-06-21 18:49 UTC (permalink / raw)
To: John Stultz
Cc: Herbert Xu, Arnd Bergmann, Alexander Kuleshov, y2038 Mailman List,
lkml, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <CALAqxLU6-=r8z9dVF5PQCzps-Y4SWcXMd_=QDgZuYj7Dij5whg@mail.gmail.com>
Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
Hi John,
> I don't see in the above an explanation of *why* you're using
> ktime_get_raw_ns() instead of ktime_get_ns().
Could you help me understand what the difference is or point me to some
documentation? I understood that we only talked about the _raw variant.
>
> 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.
Ok, if the running backwards hint is only applicable to the _fast variants, I
can certainly drop it.
Thanks
Stephan
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH v5 0/7] /dev/random - a new approach
From: Stephan Mueller @ 2016-06-21 18:46 UTC (permalink / raw)
To: Austin S. Hemmelgarn
Cc: Nikos Mavrogiannopoulos, Theodore Ts'o, Pavel Machek,
Herbert Xu, Andi Kleen, Sandy Harris, Jason Cooper, John Denker,
H. Peter Anvin, Joe Perches, George Spelvin,
Linux Crypto Mailing List, Linux Kernel Mailing List
In-Reply-To: <8e41b430-51e5-b0a4-8801-e44c9623e2bd@gmail.com>
Am Dienstag, 21. Juni 2016, 14:22:48 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-21 12:28, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn:
> >
> > Hi Austin,
> >
> >> On 2016-06-21 03:32, Stephan Mueller wrote:
> >>> Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos:
> >>>
> >>> Hi Nikos,
> >>>
> >>>> On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller <smueller@chronox.de>
> >>>
> >>> wrote:
> >>>>>> Personally, I don't really use /dev/random, nor would I recommend it
> >>>>>> for most application programmers. At this point, getrandom(2) really
> >>>>>> is the preferred interface unless you have some very specialized
> >>>>>> needs.
> >>>>>
> >>>>> I fully agree. But there are use cases for /dev/random, notably as a
> >>>>> seed
> >>>>> source for other DRNG.
> >>>>
> >>>> Is that really the case? I believe all DRNG's use /dev/urandom anyway
> >>>> for seeding since they cannot afford indeterminate blocking. It would
> >>>> be a gain for everyone if /dev/random was the same as /dev/urandom in
> >>>> Linux.
> >>>
> >>> For standard approaches, this is true. But there are regulations,
> >>> notably
> >>> in the German realm, /dev/random shall be used, at least partially (see
> >>> AIS 20/31).
> >>
> >> Which just goes to show how utterly stupid some people who write laws
> >> and regulations are. Saying specifically that '/dev/random shall be
> >> used' does not enforce any improvement of entrophic value in the data at
> >> all, it just coincidentally improves the theoretical quality of the data
> >> because of how Linux and some legacy UNIX systems are designed. This
> >> 'regulation' already provides zero benefit other than a placebo effect
> >> on at least OpenBSD, FreeBSD, and I'm pretty certain most other BSD
> >> derivatives, as /dev/random and /dev/urandom point to the same thing
> >> there (on OpenBSD it's an arcfour based drbg, FreeBSD does similar but
> >> uses a CSPRNG called Fortuna), and while I'm not certain, I believe AIX
> >> does likewise (although they use a design based on yarrow).
> >
> > It is NOT utterly stupid, you should listen to the reasons.
>
> I'm not commenting about them wanting cryptographically secure entropy.
> My statement about the intelligence of the people who wrote the standard
> was commenting on their saying '/dev/random shall be used' instead of 'a
It behooves if you read the documents before making statements! AIS 20/31 does
not require /dev/random in the documentation, but specifies a number of
requirements for a seed source (NTG.1, PTG.[1|2|3]). And /dev/random happens
to be an NTG.1 whereas /dev/urandom is not.
> cryptographically secure entropy source shall be used'. POSIX requires
> that the first statement imply the second, but the second does not
> require the first. Their choice to use the first indicates that they
> assume this will be the only implementation that will ever matter, and
> that POSIX systems will be the only thing anyone using the standard
> cares about, both of which are inherently poor assumptions outside of a
> completely closed system. Most standards proposed or mandated by
> bureaucracies have similar issues making bad assumptions about the
> context in which they will be used.
>
> > The core reason is
> > explained with the following analogy:
> >
> > /dev/urandom, for a short period of time, operates as a DRNG. For the sake
> > of discussion, let us assume that it is a DRNG which is, for the sake of
> > discussion, seeded with 256 bits of entropy.
> >
> > Now, you pull 256 bits out of it, you have 256 bits of entropy.
> >
> > You pull again 256 bit out of it -- what entropy do you have? You do NOT
> > have *again* 256 bits of entropy. All you can say is the entire generated
> > 512 bits have collectively 256 bits of entropy. And so on and so forth.
> >
> > Now, if you want to say that your newly spawned DRNG is seeded with X
> > amount of entropy, the DRNG nature of /dev/urandom makes such a statement
> > a challenge. The easy way out of the challenge is to use /dev/random (I
> > am aware of the fact that the DRNG has a computational strength, but it
> > is not, well, entropy).
> >
> > In addition, when using /dev/urandom, you have to show that at the time
> > you
> > seed the DRNG, it is fully seeded. That is a challenge at boot time - a
> > challenge this entire thread revolves around. Yes, getrandom(2) is the way
> > out, but not everybody uses it. Again, /dev/random does NOT have this
> > challenge.
>
> The fact that that's how /dev/urandom works is a result of the
> implementation, I already listed at least 3 UNIX derivatives that do not
> work this way and provide cryptographically secure entropy from the same
> source stream for both /dev/random and /dev/urandom. Changing this on
> Linux would not break backwards compatibility as long as we provide
> sufficient entropy via /dev/random, because nobody depends on it
> blocking for anything other than ensuring they get good entropy, so if
> it always returns good cryptographically secure entropy, we never need
> to block unless the generator hasn't yet been seeded. Now, on top of
> that, there's still no absolute guarantee that what you get from
> /dev/random is actually cryptographically secure, but that's a separate
> issue.
I am not sure what your point is, so let us leave it at that.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v4 0/5] /dev/random - a new approach
From: Austin S. Hemmelgarn @ 2016-06-21 17:18 UTC (permalink / raw)
To: Tomas Mraz, Stephan Mueller
Cc: Theodore Ts'o, David Jaša, Andi Kleen, sandyinchina,
Jason Cooper, John Denker, H. Peter Anvin, Joe Perches,
Pavel Machek, George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <1466515196.17017.8.camel@redhat.com>
On 2016-06-21 09:19, Tomas Mraz wrote:
> On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote:
>> On 2016-06-20 14:32, Stephan Mueller wrote:
>>>
>>> [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
>> Specific things I notice about this:
>> 1. QEMU systems are reporting higher values than almost anything
>> else
>> with the same ISA. This makes sense, but you don't appear to have
>> accounted for the fact that you can't trust almost any of the entropy
>> in
>> a VM unless you have absolute trust in the host system, because the
>> host
>> system can do whatever the hell it wants to you, including
>> manipulating
>> timings directly (with a little patience and some time spent working
>> on
>> it, you could probably get those number to show whatever you want
>> just
>> by manipulating scheduling parameters on the host OS for the VM
>> software).
>
> You have to trust the host for anything, not just for the entropy in
> timings. This is completely invalid argument unless you can present a
> method that one guest can manipulate timings in other guest in such a
> way that _removes_ the inherent entropy from the host.
When dealing with almost any type 2 hypervisor, it is fully possible for
a user other than the one running the hypervisor to manipulate
scheduling such that entropy is reduced. This does not imply that the
user who is doing this has any other control over the target VM, and
importantly, often does not require administrative access on the host,
only regular user access. Such an attack is very difficult to effect
outside of a clean-room environment, but is still possible. You can't
use this to force generation of arbitrary data, but you can definitely
starve a VM for entropy. By nature, something that relies on interrupt
timings will be more impacted by such an attack than something that does
not.
In most cases, such an attack will be a DoS attack on the host as well
(as that's the simplest way to do this). This is less of an issue with
proper practices on a type 1 hypervisor, but is still possible there too
(although pulling this off on at least Xen when you have proper VCPU
isolation is functionally impossible without administrative access to
the control domain).
^ permalink raw reply
* Re: [PATCH v5 0/7] /dev/random - a new approach
From: Austin S. Hemmelgarn @ 2016-06-21 18:22 UTC (permalink / raw)
To: Stephan Mueller
Cc: Nikos Mavrogiannopoulos, Theodore Ts'o, Pavel Machek,
Herbert Xu, Andi Kleen, Sandy Harris, Jason Cooper, John Denker,
H. Peter Anvin, Joe Perches, George Spelvin,
Linux Crypto Mailing List, Linux Kernel Mailing List
In-Reply-To: <183335903.ioesrD1Ugf@tauon.atsec.com>
On 2016-06-21 12:28, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn:
>
> Hi Austin,
>
>> On 2016-06-21 03:32, Stephan Mueller wrote:
>>> Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos:
>>>
>>> Hi Nikos,
>>>
>>>> On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller <smueller@chronox.de>
>>>
>>> wrote:
>>>>>> Personally, I don't really use /dev/random, nor would I recommend it
>>>>>> for most application programmers. At this point, getrandom(2) really
>>>>>> is the preferred interface unless you have some very specialized
>>>>>> needs.
>>>>>
>>>>> I fully agree. But there are use cases for /dev/random, notably as a
>>>>> seed
>>>>> source for other DRNG.
>>>>
>>>> Is that really the case? I believe all DRNG's use /dev/urandom anyway
>>>> for seeding since they cannot afford indeterminate blocking. It would
>>>> be a gain for everyone if /dev/random was the same as /dev/urandom in
>>>> Linux.
>>>
>>> For standard approaches, this is true. But there are regulations, notably
>>> in the German realm, /dev/random shall be used, at least partially (see
>>> AIS 20/31).
>>
>> Which just goes to show how utterly stupid some people who write laws
>> and regulations are. Saying specifically that '/dev/random shall be
>> used' does not enforce any improvement of entrophic value in the data at
>> all, it just coincidentally improves the theoretical quality of the data
>> because of how Linux and some legacy UNIX systems are designed. This
>> 'regulation' already provides zero benefit other than a placebo effect
>> on at least OpenBSD, FreeBSD, and I'm pretty certain most other BSD
>> derivatives, as /dev/random and /dev/urandom point to the same thing
>> there (on OpenBSD it's an arcfour based drbg, FreeBSD does similar but
>> uses a CSPRNG called Fortuna), and while I'm not certain, I believe AIX
>> does likewise (although they use a design based on yarrow).
>
> It is NOT utterly stupid, you should listen to the reasons.
I'm not commenting about them wanting cryptographically secure entropy.
My statement about the intelligence of the people who wrote the standard
was commenting on their saying '/dev/random shall be used' instead of 'a
cryptographically secure entropy source shall be used'. POSIX requires
that the first statement imply the second, but the second does not
require the first. Their choice to use the first indicates that they
assume this will be the only implementation that will ever matter, and
that POSIX systems will be the only thing anyone using the standard
cares about, both of which are inherently poor assumptions outside of a
completely closed system. Most standards proposed or mandated by
bureaucracies have similar issues making bad assumptions about the
context in which they will be used.
> The core reason is
> explained with the following analogy:
>
> /dev/urandom, for a short period of time, operates as a DRNG. For the sake of
> discussion, let us assume that it is a DRNG which is, for the sake of
> discussion, seeded with 256 bits of entropy.
>
> Now, you pull 256 bits out of it, you have 256 bits of entropy.
>
> You pull again 256 bit out of it -- what entropy do you have? You do NOT have
> *again* 256 bits of entropy. All you can say is the entire generated 512 bits
> have collectively 256 bits of entropy. And so on and so forth.
>
> Now, if you want to say that your newly spawned DRNG is seeded with X amount
> of entropy, the DRNG nature of /dev/urandom makes such a statement a
> challenge. The easy way out of the challenge is to use /dev/random (I am aware
> of the fact that the DRNG has a computational strength, but it is not, well,
> entropy).
>
> In addition, when using /dev/urandom, you have to show that at the time you
> seed the DRNG, it is fully seeded. That is a challenge at boot time - a
> challenge this entire thread revolves around. Yes, getrandom(2) is the way
> out, but not everybody uses it. Again, /dev/random does NOT have this
> challenge.
The fact that that's how /dev/urandom works is a result of the
implementation, I already listed at least 3 UNIX derivatives that do not
work this way and provide cryptographically secure entropy from the same
source stream for both /dev/random and /dev/urandom. Changing this on
Linux would not break backwards compatibility as long as we provide
sufficient entropy via /dev/random, because nobody depends on it
blocking for anything other than ensuring they get good entropy, so if
it always returns good cryptographically secure entropy, we never need
to block unless the generator hasn't yet been seeded. Now, on top of
that, there's still no absolute guarantee that what you get from
/dev/random is actually cryptographically secure, but that's a separate
issue.
^ permalink raw reply
* Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback
From: John Stultz @ 2016-06-21 18:11 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Arnd Bergmann, Alexander Kuleshov, y2038 Mailman List,
lkml, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <8242305.3NQCWfJAlD@positron.chronox.de>
On Tue, Jun 21, 2016 at 11:05 AM, Stephan Mueller <smueller@chronox.de> 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@chronox.de>
> ---
> 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
^ permalink raw reply
* [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback
From: Stephan Mueller @ 2016-06-21 18:05 UTC (permalink / raw)
To: herbert
Cc: Kees Cook, Arnd Bergmann, Alexander Kuleshov, y2038 Mailman List,
linux-kernel, John Stultz, linux-crypto, David S. Miller
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@chronox.de>
---
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();
*out = tmp;
}
--
2.5.5
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply related
* Re: [PATCH v4 0/5] /dev/random - a new approach
From: Stephan Mueller @ 2016-06-21 18:05 UTC (permalink / raw)
To: Austin S. Hemmelgarn
Cc: Tomas Mraz, Theodore Ts'o, David Jaša, Andi Kleen,
sandyinchina, Jason Cooper, John Denker, H. Peter Anvin,
Joe Perches, Pavel Machek, George Spelvin, linux-crypto,
linux-kernel
In-Reply-To: <9a0a80fb-779e-b708-990e-1627ec03b1b7@gmail.com>
Am Dienstag, 21. Juni 2016, 13:54:13 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-21 13:23, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
> >
> > Hi Austin,
> >
> >>> You have to trust the host for anything, not just for the entropy in
> >>> timings. This is completely invalid argument unless you can present a
> >>> method that one guest can manipulate timings in other guest in such a
> >>> way that _removes_ the inherent entropy from the host.
> >>
> >> When dealing with almost any type 2 hypervisor, it is fully possible for
> >> a user other than the one running the hypervisor to manipulate
> >> scheduling such that entropy is reduced. This does not imply that the
> >
> > Please re-read the document: Jitter RNG does not rest on scheduling.
>
> If you are running inside a VM, your interrupt timings depend on the
The RNG does not rest on interrupts either.
> hpyervisor's scheduling, period. You may not directly rely on
> scheduling from the OS you are running on, but if you are doing anything
> timing related in a VM, you are at the mercy of the scheduling used by
> the hypervisor and whatever host OS that may be running on.
>
> In the attack I"m describing, the malicious user is not manipulating the
> guest OS's scheduling, they are manipulating the host system's scheduling.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v4 0/5] /dev/random - a new approach
From: Stephan Mueller @ 2016-06-21 18:04 UTC (permalink / raw)
To: Austin S. Hemmelgarn
Cc: Theodore Ts'o, David Jaša, Andi Kleen, sandyinchina,
Jason Cooper, John Denker, H. Peter Anvin, Joe Perches,
Pavel Machek, George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <5d1a9ce4-a2e5-4ec7-9ca8-22d75281025f@gmail.com>
Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn:
Hi Austin,
>
> >> 2. Quite a few systems have a rather distressingly low lower bound and
> >> still get accepted by your algorithm (a number of the S/390 systems, and
> >> a handful of the AMD processors in particular).
> >
> > I am aware of that, but please read the entire documentation where the
> > lower and upper boundary comes from and how the Jitter RNG really
> > operates. There you will see that the lower boundary is just that: it
> > will not be lower, but the common case is the upper boundary.
>
> Talking about the common case is all well and good, but the lower bound
> still needs to be taken into account. If the test results aren't
> uniformly distributed within that interval, or even following a typical
> Gaussian distribution within it (which is what I and many other people
> would probably assume without the data later in the appendix), then you
> really need to mention this _before_ the table itself. Such information
> is very important, and not everyone has time to read everything.
Then read chapter 5 as mentioned above the table. What you read was an
appendix that is supposed to supplement to that chapter and not a full-fledged
documentation.
And quickly glancing over that table to make a judgment is not helpful for
such topic.
>
> >> 5. You discount the Pentium Celeron Mobile CPU as old and therefore not
> >> worth worrying about. Linux still runs on 80486 and other 'ancient'
> >> systems, and there are people using it on such systems. You need to
> >> account for this usage.
> >
> > I do not account for that in the documentation. In real life though, I
> > certainly do -- see how the Jitter RNG is used in the kernel.
>
> Then you shouldn't be pushing the documentation as what appears to be
> your sole argument for including it in the kernel.
I understand you read Appendix F -- but that document is 150+ pages in size
with quite a bit of information and you judge it based on an appendix
providing supplemental data?
Note, I pointed you to this appendix at the starting question where you wanted
to see test results on execution timing variations on ARM and MIPS.
>
> >> 6. You have a significant lack of data regarding embedded systems, which
> >> is one of the two biggest segments of Linux's market share. You list no
> >> results for any pre-ARMv6 systems (Linux still runs on and is regularly
> >> used on ARMv4 CPU's, and it's worth also pointing out that the values on
> >> the ARMv6 systems are themselves below average), any MIPS systems other
> >> than 24k and 4k (which is not a good representation of modern embedded
> >> usage), any SPARC CPU's other than UltraSPARC (ideally you should have
> >> results on at least a couple of LEON systems as well), no tight-embedded
> >> PPC chips (PPC 440 processors are very widely used, as are the 7xx and
> >> 970 families, and Freescale's e series), and only one set of results for
> >> a tight-embedded x86 CPU (the Via Nano, you should ideally also have
> >> results on things like an Intel Quark). Overall, your test system
> >> selection is not entirely representative of actual Linux usage (yeah,
> >> ther'es a lot of x86 servers out there running Linux, there's at least
> >> as many embedded systems running it too though, even without including
> >> Android).
> >
> > Perfectly valid argument. But I programmed that RNG as a hobby -- I do not
> > have the funds to buy all devices there are.
>
> I'm not complaining as much about the lack of data for such devices as I
> am about you stating that it will work fine for such devices when you
> have so little data to support those claims. Many of the devices you
Little data, interesting statement for results on 200+ systems including all
major CPU arches all showing information leading in the same directions.
> have listed that can be reasonably assumed to be embedded systems are
> relatively modern ones that most people would think of (smart-phones and
> similar). Such systems have almost as much if not more interrupts as
> many desktop and server systems, so the entropy values there actually do
Please re-read the documentation: the testing and the test analysis remove
outliers from interrupts and such to get a worst-case testing.
> make some sense. Not everything has this luxury. Think for example of
> a router. All it will generally have interrupts from is the timer
> interrupt (which should functionally have near zero entropy because it's
> monotonic most of the time) and the networking hardware, and quite
> often, many of the good routers operate their NIC's in polling mode,
> which means very few interrupts (which indirectly is part of the issue
> with some server systems too), and therefore will have little to no
> entropy there either. This is an issue with the current system too, but
> you have almost zero data on such systems systems yourself, so you can't
> argue that it makes things better for them.
It would be good to read the documentation in full -- the RNG does not rest on
interrupts.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 23/28] ARM: dts: DRA7: Add DT node for DES IP
From: Tero Kristo @ 2016-06-21 17:56 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-crypto, herbert, davem, linux-arm-kernel,
lokeshvutla
In-Reply-To: <20160610113836.GF22406@atomide.com>
On 10/06/16 14:38, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [160601 02:09]:
>> From: Joel Fernandes <joelf@ti.com>
>>
>> DRA7xx SoCs have a DES3DES IP. Add DT data for the same.
>
> Are these dts changes safe to apply separately or do they
> cause issues like extra warnings during boot?
DTS changes are fine to merge as is separately, some crypto
functionality might not work properly though (well, the support is
somewhat broken on am43xx/dra7 anyways.) I just gave the kernel a boot
test with am43xx/dra7 platforms with the DT data only applied, and that
part worked fine.
I noticed that if you merge the hwmod changes before you have the DTS
data though, you will get some extra boot warnings of the following kind
on am43xx/dra7:
<snip>
[ 0.315623] omap_hwmod: aes1: no dt node
[ 0.315631] ------------[ cut here ]------------
[ 0.315656] WARNING: CPU: 0 PID: 1 at
arch/arm/mach-omap2/omap_hwmod.c:2497 _init+0x1d0/0x41c
[ 0.315663] omap_hwmod: aes1: doesn't have mpu register target base
<snip>
Do you want to pick-up the DTS changes from this revision of series as
is or shall I repost those also? I think the series would require a
re-ordering of posting the DTS changes before the hwmod data.
-Tero
^ permalink raw reply
* Re: [PATCH v4 0/5] /dev/random - a new approach
From: Austin S. Hemmelgarn @ 2016-06-21 17:54 UTC (permalink / raw)
To: Stephan Mueller
Cc: Tomas Mraz, Theodore Ts'o, David Jaša, Andi Kleen,
sandyinchina, Jason Cooper, John Denker, H. Peter Anvin,
Joe Perches, Pavel Machek, George Spelvin, linux-crypto,
linux-kernel
In-Reply-To: <6038462.HIH9pGNYO7@positron.chronox.de>
On 2016-06-21 13:23, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
>
> Hi Austin,
>
>>> You have to trust the host for anything, not just for the entropy in
>>> timings. This is completely invalid argument unless you can present a
>>> method that one guest can manipulate timings in other guest in such a
>>> way that _removes_ the inherent entropy from the host.
>>
>> When dealing with almost any type 2 hypervisor, it is fully possible for
>> a user other than the one running the hypervisor to manipulate
>> scheduling such that entropy is reduced. This does not imply that the
>
> Please re-read the document: Jitter RNG does not rest on scheduling.
If you are running inside a VM, your interrupt timings depend on the
hpyervisor's scheduling, period. You may not directly rely on
scheduling from the OS you are running on, but if you are doing anything
timing related in a VM, you are at the mercy of the scheduling used by
the hypervisor and whatever host OS that may be running on.
In the attack I"m describing, the malicious user is not manipulating the
guest OS's scheduling, they are manipulating the host system's scheduling.
^ permalink raw reply
* Re: [PATCH v4 0/5] /dev/random - a new approach
From: Austin S. Hemmelgarn @ 2016-06-21 17:51 UTC (permalink / raw)
To: Stephan Mueller
Cc: Theodore Ts'o, David Jaša, Andi Kleen, sandyinchina,
Jason Cooper, John Denker, H. Peter Anvin, Joe Perches,
Pavel Machek, George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <1526644.Bum3kD6iTD@tauon.atsec.com>
On 2016-06-21 09:20, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn:
>
> Hi Austin,
>
>> On 2016-06-20 14:32, Stephan Mueller wrote:
>>> Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn:
>>>
>>> Hi Austin,
>>>
>>>> On 2016-06-18 12:31, Stephan Mueller wrote:
>>>>> Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o:
>>>>>
>>>>> Hi Theodore,
>>>>>
>>>>>> At the end of the day, with these devices you really badly need a
>>>>>> hardware RNG. We can't generate randomness out of thin air. The only
>>>>>> thing you really can do requires user space help, which is to generate
>>>>>> keys lazily, or as late as possible, so you can gather as much entropy
>>>>>> as you can --- and to feed in measurements from the WiFi (RSSI
>>>>>> measurements, MAC addresses seen, etc.) This won't help much if you
>>>>>> have an FBI van parked outside your house trying to carry out a
>>>>>> TEMPEST attack, but hopefully it provides some protection against a
>>>>>> remote attacker who isn't try to carry out an on-premises attack.
>>>>>
>>>>> All my measurements on such small systems like MIPS or smaller/older
>>>>> ARMs
>>>>> do not seem to support that statement :-)
>>>>
>>>> Was this on real hardware, or in a virtual machine/emulator? Because if
>>>> it's not on real hardware, you're harvesting entropy from the host
>>>> system, not the emulated one. While I haven't done this with MIPS or
>>>> ARM systems, I've taken similar measurements on SPARC64, x86_64, and
>>>> PPC64 systems comparing real hardware and emulated hardware, and the
>>>> emulated hardware _always_ has higher entropy, even when running the
>>>> emulator on an identical CPU to the one being emulated and using KVM
>>>> acceleration and passing through all the devices possible.
>>>>
>>>> Even if you were testing on real hardware, I'm still rather dubious, as
>>>> every single test I've ever done on any hardware (SPARC, PPC, x86, ARM,
>>>> and even PA-RISC) indicates that you can't harvest entropy as
>>>> effectively from a smaller CPU compared to a large one, and this effect
>>>> is significantly more pronounced on RISC systems.
>>>
>>> It was on real hardware. As part of my Jitter RNG project, I tested all
>>> major CPUs from small to big -- see Appendix F [1]. For MIPS/ARM, see the
>>> trailing part of the big table.
>>>
>>> [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
>>
>> Specific things I notice about this:
>> 1. QEMU systems are reporting higher values than almost anything else
>> with the same ISA. This makes sense, but you don't appear to have
>> accounted for the fact that you can't trust almost any of the entropy in
>> a VM unless you have absolute trust in the host system, because the host
>> system can do whatever the hell it wants to you, including manipulating
>> timings directly (with a little patience and some time spent working on
>> it, you could probably get those number to show whatever you want just
>> by manipulating scheduling parameters on the host OS for the VM software).
>
> I am not sure where you see QEMU systems listed there.
That would be the ones which list 'QEMU Virtual CPU version X.Y' as the
CPU string. The only things that return that in the CPUID data are
either QEMU itself, or software that is based on QEMU.
>
>> 2. Quite a few systems have a rather distressingly low lower bound and
>> still get accepted by your algorithm (a number of the S/390 systems, and
>> a handful of the AMD processors in particular).
>
> I am aware of that, but please read the entire documentation where the lower
> and upper boundary comes from and how the Jitter RNG really operates. There
> you will see that the lower boundary is just that: it will not be lower, but
> the common case is the upper boundary.
Talking about the common case is all well and good, but the lower bound
still needs to be taken into account. If the test results aren't
uniformly distributed within that interval, or even following a typical
Gaussian distribution within it (which is what I and many other people
would probably assume without the data later in the appendix), then you
really need to mention this _before_ the table itself. Such information
is very important, and not everyone has time to read everything.
>
> Furthermore, the use case of the Jitter RNG is to support the DRBG seeding
> with a very high reseed interval.
>
>> 3. Your statement at the bottom of the table that 'all test systems at
>> least un-optimized have a lower bound of 1 bit' is refuted by your own
>> data, I count at least 2 data points where this is not the case. One of
>> them is mentioned at the bottom as an outlier, and you have data to back
>> this up listed in the table, but the other (MIPS 4Kec v4.8) is the only
>> system of that specific type that you tested, and thus can't be claimed
>> as an outlier.
>
> You are right, I have added more and more test results to the table without
> updating the statement below. I will fix that.
>
> But note, that there is a list below that statement providing explanations
> already. So, it is just that one statement that needs updating.
>
>> 4. You state the S/390 systems gave different results when run
>> un-optimized, but don't provide any data regarding this.
>
> The pointer to appendix F.46 was supposed to cover that issue.
Apologies for not reading that part thoroughly, you might want to add
those results to the table too.
>
>> 5. You discount the Pentium Celeron Mobile CPU as old and therefore not
>> worth worrying about. Linux still runs on 80486 and other 'ancient'
>> systems, and there are people using it on such systems. You need to
>> account for this usage.
>
> I do not account for that in the documentation. In real life though, I
> certainly do -- see how the Jitter RNG is used in the kernel.
Then you shouldn't be pushing the documentation as what appears to be
your sole argument for including it in the kernel.
>
>> 6. You have a significant lack of data regarding embedded systems, which
>> is one of the two biggest segments of Linux's market share. You list no
>> results for any pre-ARMv6 systems (Linux still runs on and is regularly
>> used on ARMv4 CPU's, and it's worth also pointing out that the values on
>> the ARMv6 systems are themselves below average), any MIPS systems other
>> than 24k and 4k (which is not a good representation of modern embedded
>> usage), any SPARC CPU's other than UltraSPARC (ideally you should have
>> results on at least a couple of LEON systems as well), no tight-embedded
>> PPC chips (PPC 440 processors are very widely used, as are the 7xx and
>> 970 families, and Freescale's e series), and only one set of results for
>> a tight-embedded x86 CPU (the Via Nano, you should ideally also have
>> results on things like an Intel Quark). Overall, your test system
>> selection is not entirely representative of actual Linux usage (yeah,
>> ther'es a lot of x86 servers out there running Linux, there's at least
>> as many embedded systems running it too though, even without including
>> Android).
>
> Perfectly valid argument. But I programmed that RNG as a hobby -- I do not
> have the funds to buy all devices there are.
I'm not complaining as much about the lack of data for such devices as I
am about you stating that it will work fine for such devices when you
have so little data to support those claims. Many of the devices you
have listed that can be reasonably assumed to be embedded systems are
relatively modern ones that most people would think of (smart-phones and
similar). Such systems have almost as much if not more interrupts as
many desktop and server systems, so the entropy values there actually do
make some sense. Not everything has this luxury. Think for example of
a router. All it will generally have interrupts from is the timer
interrupt (which should functionally have near zero entropy because it's
monotonic most of the time) and the networking hardware, and quite
often, many of the good routers operate their NIC's in polling mode,
which means very few interrupts (which indirectly is part of the issue
with some server systems too), and therefore will have little to no
entropy there either. This is an issue with the current system too, but
you have almost zero data on such systems systems yourself, so you can't
argue that it makes things better for them.
>
> And http://www.chronox.de/jent.html asks for help -- if you have those
> devices, please help and simply execute one application and return the data to
> me.
>
>> 7. The RISC CPU's that you actually tested have more consistency within
>> a particular type than the CISC CPU's. Many of them do have higher
>> values than the CISC CPU's, but a majority of the ones I see listed
>> which have such high values are either old systems not designed for low
>> latency, or relatively big SMP systems (which will have higher entropy
>> because of larger numbers of IRQ's, as well as other factors).
>
> Ok, run the tests on the systems you like and return the results to me.
I would love to, but sadly the only system I have that isn't an x86 box
that actually boots at all right now is an almost 2 decade old PA-RISC
box that barely runs Linux, and the number of people who would be
interested in the results from that can probably be counted on one hand.
^ permalink raw reply
* Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)
From: Andy Lutomirski @ 2016-06-21 17:43 UTC (permalink / raw)
To: linux-bluetooth, Johan Hedberg, Gustavo Padovan, Marcel Holtmann,
linux-crypto, David S. Miller, Herbert Xu,
linux-kernel@vger.kernel.org, Linus Torvalds
net/bluetooth/smp.c (in smp_e) wants to do AES-ECB on a 16-byte stack
buffer, which seems eminently reasonable to me. It does it like this:
sg_init_one(&sg, data, 16);
skcipher_request_set_tfm(req, tfm);
skcipher_request_set_callback(req, 0, NULL, NULL);
skcipher_request_set_crypt(req, &sg, &sg, 16, NULL);
err = crypto_skcipher_encrypt(req);
skcipher_request_zero(req);
if (err)
BT_ERR("Encrypt data error %d", err);
I tried to figure out what exactly that does, and I got like in so
many layers of indirection that I mostly gave up. But it appears to
map the stack address to a physical address, stick it in a
scatterlist, follow several function pointers, go through a bunch of
"scatterwalk" indirection, and call blkcipher_next_fast, which calls
blkcipher_map_src, which calls scatterwalk_map, which calls
kmap_atomic (!). This is anything but fast.
I think this code has several serious problems:
- It uses kmap_atomic to access a 16-byte stack buffer. This is absurd.
- It blows up if the stack is in vmalloc space, because you can't
virt_to_phys on the stack buffer in the first place. (This is why I
care.) And I really, really don't want to write sg_init_stack to
create a scatterlist that points to the stack, although such a thing
could be done if absolutely necessary.
- It's very, very compllicated and it does something very, very
simple (call aes_encrypt on a plain old u8 *).
Oh yeah, it sets CRYPTO_ALG_ASYNC, too. I can't even figure out what
that does because the actual handling of that flag is so many layers
deep.
Is there a straightforward way that bluetooth and, potentially, other
drivers can just do synchronous crypto in a small buffer specified by
its virtual address? The actual cryptography part of the crypto code
already works this way, but I can't find an API for it.
--Andy
^ permalink raw reply
* Re: [PATCH v4 0/5] /dev/random - a new approach
From: Stephan Mueller @ 2016-06-21 17:23 UTC (permalink / raw)
To: Austin S. Hemmelgarn
Cc: Tomas Mraz, Theodore Ts'o, David Jaša, Andi Kleen,
sandyinchina, Jason Cooper, John Denker, H. Peter Anvin,
Joe Perches, Pavel Machek, George Spelvin, linux-crypto,
linux-kernel
In-Reply-To: <e70c9e01-5e48-a26a-d485-ca512c111cbc@gmail.com>
Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
Hi Austin,
> > You have to trust the host for anything, not just for the entropy in
> > timings. This is completely invalid argument unless you can present a
> > method that one guest can manipulate timings in other guest in such a
> > way that _removes_ the inherent entropy from the host.
>
> When dealing with almost any type 2 hypervisor, it is fully possible for
> a user other than the one running the hypervisor to manipulate
> scheduling such that entropy is reduced. This does not imply that the
Please re-read the document: Jitter RNG does not rest on scheduling.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v4 0/5] /dev/random - a new approach
From: Austin S. Hemmelgarn @ 2016-06-21 17:17 UTC (permalink / raw)
To: Pavel Machek
Cc: Stephan Mueller, Theodore Ts'o, David Jaša, Andi Kleen,
sandyinchina, Jason Cooper, John Denker, H. Peter Anvin,
Joe Perches, George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <20160621134240.GA8086@amd>
On 2016-06-21 09:42, Pavel Machek wrote:
> Hi!
>
>> 6. You have a significant lack of data regarding embedded systems, which is
>> one of the two biggest segments of Linux's market share. You list no
>> results for any pre-ARMv6 systems (Linux still runs on and is regularly used
>> on ARMv4 CPU's, and it's worth also pointing out that the values on
>> the
>
> Feel free to contribute more test results.
>
> I mean... you can't expect every person who wants to improve something
> in linux to test on everything in the world... can you?
>
I was commenting less on the lack of results for such systems than on
attempts to make statements about such systems based on a data-set that
lacks information about such systems.
^ permalink raw reply
* Re: [PATCH] crypto: use timespec64 for jent_get_nstime
From: Stephan Mueller @ 2016-06-21 17:16 UTC (permalink / raw)
To: John Stultz
Cc: Herbert Xu, Arnd Bergmann, Alexander Kuleshov, y2038 Mailman List,
lkml, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <CALAqxLV4qmY8hhzYjQ8+Mx-Tb5WKP1RUQd4JLUnoZRndKTM9og@mail.gmail.com>
Am Dienstag, 21. Juni 2016, 10:12:24 schrieb John Stultz:
Hi John,
>
> So this is definitely more clear then what was described earlier, and
> worries me because on many x86 machines (though fewer I guess these
> days then in the past) the clocksource will often not be the TSC (and
> have lower resolution).
Please note, the use of the ktime_get_raw_ns() is *only* used as a fallback on
architectures where random_get_entropy / get_cycles is not implemented.
So, on X86 and on many other arches, this function call will never be
triggered.
...
>
> But please just make sure the reason why you're using that specific
> interface is clearly documented in the code so we don't have to later
> reverse engineer the intent.
Will do.
@Arnd: I would prepare a patch then using ktime_get_raw_ns and providing a
good documentation in the code.
Ciao
Stephan
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH] crypto: use timespec64 for jent_get_nstime
From: John Stultz @ 2016-06-21 17:12 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Arnd Bergmann, Alexander Kuleshov, y2038 Mailman List,
lkml, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <12040808.ISNuLM4SqW@tauon.atsec.com>
On Tue, Jun 21, 2016 at 9:51 AM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz:
>
> Hi John,
>
>> On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller <smueller@chronox.de>
> wrote:
>> > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
>> >
>> > Hi John,
>> >
>> >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> >> >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
>> >> > Compared to the previous __getnstimeofday(), the difference is
>> >> >
>> >> > - using "monotonic" timebase instead of "real", so the zero time
>> >> >
>> >> > is when the system booted rather than Jan 1 1970
>> >>
>> >> I haven't looked at the details of the calling code, but I'd worry for
>> >> crypto uses, especially if its being used for entropy collection,
>> >> using the monotonic clock instead of the realtime clock might be
>> >> problematic.
>> >
>> > Funnily it does not seem like that. All tests that I have conducted show
>> > that monotonic clocks behave equally as realtime clocks, because the
>> > uncertainty lies in the execution time of a set of instructions. All we
>> > need to do is to measure it with a timer that has a resolution that
>> > allows detecting these variations.
>>
>> Ok. If you're only using it for interval measurements, then either way
>> shouldn't matter. I just wanted to make sure the entropy wasn't coming
>> from the actual time.
>>
>> >> > - "raw" means we don't honor updates for the rate based on ntp,
>> >> >
>> >> > which is probably better as the ntp state might be observable
>> >> > over the net (it probably doesn't matter, but it can't hurt)
>> >>
>> >> So... this feels like a very vague explanation, and the lack of
>> >> frequency correction here probably need a really good comment. Keeping
>> >> multiple time domains is usually asking for trouble, but we added the
>> >> MONOTONIC_RAW clock to address a few cases where people really wanted
>> >> an abstract hardware counter, which was unaffected by frequency
>> >> corrections. I'd really make sure its clear why this is what you want
>> >> vs the standard system time domain so we don't run into problems
>> >> understanding it later.
>> >
>> > Perfect, that is what I would be interested in.
>>
>> But documenting *why* clearly is the thing I'd very strongly suggest.
>> If we need to make some slight semantic change for whatever reason, I
>> don't want folks worried "we can't do that because the crypto code is
>> using it for voodoo".
>
> I hope my explanation is sufficient to not count as voodoo: I only need an
> interval measurement capability which has a sufficient high resolution similar
> or better than RDTSC on x86.
So this is definitely more clear then what was described earlier, and
worries me because on many x86 machines (though fewer I guess these
days then in the past) the clocksource will often not be the TSC (and
have lower resolution).
So you might boot w/ "clocksource=acpi_pm" or "clocksource=hpet" to
test these other possible clocksources.
However, this was always the case, so if if __getnstimeofday64()
worked before (though, its not clear why you were using the __ version
prior, since that's supposed to be an internal function), it uses the
same clocksource, so I suspect there won't be any functional
difference the the pre-existing code.
But please just make sure the reason why you're using that specific
interface is clearly documented in the code so we don't have to later
reverse engineer the intent.
thanks
-john
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH] crypto: use timespec64 for jent_get_nstime
From: Stephan Mueller @ 2016-06-21 17:07 UTC (permalink / raw)
To: John Stultz
Cc: Herbert Xu, Arnd Bergmann, Alexander Kuleshov, y2038 Mailman List,
lkml, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <12040808.ISNuLM4SqW@tauon.atsec.com>
Am Dienstag, 21. Juni 2016, 18:51:32 schrieb Stephan Mueller:
Hi,
> > So.. again, I'd avoid using the "fast" accessor unless there is a
> > clear need or obvious benefit. Which should be documented.
>
> So, you suggest ktime_get_raw_ns? If yes, let me test that for one use case.
I tested ktime_get_raw_ns and it exhibits the same results as
ktime_get_raw_fast_ns and RDTSC. So, I see no objections in using
ktime_get_raw_ns.
Ciao
Stephan
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH] crypto: use timespec64 for jent_get_nstime
From: Stephan Mueller @ 2016-06-21 16:51 UTC (permalink / raw)
To: John Stultz
Cc: Herbert Xu, Arnd Bergmann, Alexander Kuleshov, y2038 Mailman List,
lkml, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <CALAqxLXTxM=Rt01_wOpbiYQByVMQ6rO1mazR1BAMRF_uxNHY6A@mail.gmail.com>
Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz:
Hi John,
> On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller <smueller@chronox.de>
wrote:
> > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
> >
> > Hi John,
> >
> >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
> >> >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
> >> > Compared to the previous __getnstimeofday(), the difference is
> >> >
> >> > - using "monotonic" timebase instead of "real", so the zero time
> >> >
> >> > is when the system booted rather than Jan 1 1970
> >>
> >> I haven't looked at the details of the calling code, but I'd worry for
> >> crypto uses, especially if its being used for entropy collection,
> >> using the monotonic clock instead of the realtime clock might be
> >> problematic.
> >
> > Funnily it does not seem like that. All tests that I have conducted show
> > that monotonic clocks behave equally as realtime clocks, because the
> > uncertainty lies in the execution time of a set of instructions. All we
> > need to do is to measure it with a timer that has a resolution that
> > allows detecting these variations.
>
> Ok. If you're only using it for interval measurements, then either way
> shouldn't matter. I just wanted to make sure the entropy wasn't coming
> from the actual time.
>
> >> > - "raw" means we don't honor updates for the rate based on ntp,
> >> >
> >> > which is probably better as the ntp state might be observable
> >> > over the net (it probably doesn't matter, but it can't hurt)
> >>
> >> So... this feels like a very vague explanation, and the lack of
> >> frequency correction here probably need a really good comment. Keeping
> >> multiple time domains is usually asking for trouble, but we added the
> >> MONOTONIC_RAW clock to address a few cases where people really wanted
> >> an abstract hardware counter, which was unaffected by frequency
> >> corrections. I'd really make sure its clear why this is what you want
> >> vs the standard system time domain so we don't run into problems
> >> understanding it later.
> >
> > Perfect, that is what I would be interested in.
>
> But documenting *why* clearly is the thing I'd very strongly suggest.
> If we need to make some slight semantic change for whatever reason, I
> don't want folks worried "we can't do that because the crypto code is
> using it for voodoo".
I hope my explanation is sufficient to not count as voodoo: I only need an
interval measurement capability which has a sufficient high resolution similar
or better than RDTSC on x86.
>
> >> > - "fast" means that in very rare cases, the time might appear
> >> >
> >> > to go backwards (it probably can't happen here because you are not
> >> > called in an NMI).
> >>
> >> "fast" really means "safe-for-nmi wrt to locking". The tradeoff being
> >> that when frequency adjustments occur, and if your code is delayed,
> >> you might see time go backwards by a small amount. This allows
> >
> > My code would not see that as an issue.
> >
> >> tracing/sched code (or other code called from NMI) to not have to
> >> duplicate the timekeeping infrastructure.
> >>
> >> I think without a much better explanation, using the "fast" method
> >> isn't really warranted here.
> >
> > Thanks a lot. With that, I would think that the proposed
> > ktime_get_raw_fast_ns is good for use, which is supported with testing on
> > my system.
>
> So.. again, I'd avoid using the "fast" accessor unless there is a
> clear need or obvious benefit. Which should be documented.
So, you suggest ktime_get_raw_ns? If yes, let me test that for one use case.
Thanks
Stephan
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH] crypto: use timespec64 for jent_get_nstime
From: John Stultz @ 2016-06-21 16:47 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Arnd Bergmann, Alexander Kuleshov, y2038 Mailman List,
lkml, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <2575012.qQ3uE1GZEQ@tauon.atsec.com>
On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
>
> Hi John,
>
>> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
>> > Compared to the previous __getnstimeofday(), the difference is
>> >
>> > - using "monotonic" timebase instead of "real", so the zero time
>> >
>> > is when the system booted rather than Jan 1 1970
>>
>> I haven't looked at the details of the calling code, but I'd worry for
>> crypto uses, especially if its being used for entropy collection,
>> using the monotonic clock instead of the realtime clock might be
>> problematic.
>
> Funnily it does not seem like that. All tests that I have conducted show that
> monotonic clocks behave equally as realtime clocks, because the uncertainty
> lies in the execution time of a set of instructions. All we need to do is to
> measure it with a timer that has a resolution that allows detecting these
> variations.
Ok. If you're only using it for interval measurements, then either way
shouldn't matter. I just wanted to make sure the entropy wasn't coming
from the actual time.
>> > - "raw" means we don't honor updates for the rate based on ntp,
>> >
>> > which is probably better as the ntp state might be observable
>> > over the net (it probably doesn't matter, but it can't hurt)
>>
>> So... this feels like a very vague explanation, and the lack of
>> frequency correction here probably need a really good comment. Keeping
>> multiple time domains is usually asking for trouble, but we added the
>> MONOTONIC_RAW clock to address a few cases where people really wanted
>> an abstract hardware counter, which was unaffected by frequency
>> corrections. I'd really make sure its clear why this is what you want
>> vs the standard system time domain so we don't run into problems
>> understanding it later.
>
> Perfect, that is what I would be interested in.
But documenting *why* clearly is the thing I'd very strongly suggest.
If we need to make some slight semantic change for whatever reason, I
don't want folks worried "we can't do that because the crypto code is
using it for voodoo".
>> > - "fast" means that in very rare cases, the time might appear
>> >
>> > to go backwards (it probably can't happen here because you are not
>> > called in an NMI).
>>
>> "fast" really means "safe-for-nmi wrt to locking". The tradeoff being
>> that when frequency adjustments occur, and if your code is delayed,
>> you might see time go backwards by a small amount. This allows
>
> My code would not see that as an issue.
>
>> tracing/sched code (or other code called from NMI) to not have to
>> duplicate the timekeeping infrastructure.
>>
>> I think without a much better explanation, using the "fast" method
>> isn't really warranted here.
>
> Thanks a lot. With that, I would think that the proposed ktime_get_raw_fast_ns
> is good for use, which is supported with testing on my system.
So.. again, I'd avoid using the "fast" accessor unless there is a
clear need or obvious benefit. Which should be documented.
thanks
-john
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime
From: Stephan Mueller @ 2016-06-21 16:34 UTC (permalink / raw)
To: John Stultz
Cc: Arnd Bergmann, Herbert Xu, Alexander Kuleshov, y2038 Mailman List,
lkml, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <CALAqxLWan2_2HhChvq+fXKpP8CyURwj-ccdnmfEve4LTOza=mg@mail.gmail.com>
Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
Hi John,
> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
> >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
> > Compared to the previous __getnstimeofday(), the difference is
> >
> > - using "monotonic" timebase instead of "real", so the zero time
> >
> > is when the system booted rather than Jan 1 1970
>
> I haven't looked at the details of the calling code, but I'd worry for
> crypto uses, especially if its being used for entropy collection,
> using the monotonic clock instead of the realtime clock might be
> problematic.
Funnily it does not seem like that. All tests that I have conducted show that
monotonic clocks behave equally as realtime clocks, because the uncertainty
lies in the execution time of a set of instructions. All we need to do is to
measure it with a timer that has a resolution that allows detecting these
variations.
>
> > - "raw" means we don't honor updates for the rate based on ntp,
> >
> > which is probably better as the ntp state might be observable
> > over the net (it probably doesn't matter, but it can't hurt)
>
> So... this feels like a very vague explanation, and the lack of
> frequency correction here probably need a really good comment. Keeping
> multiple time domains is usually asking for trouble, but we added the
> MONOTONIC_RAW clock to address a few cases where people really wanted
> an abstract hardware counter, which was unaffected by frequency
> corrections. I'd really make sure its clear why this is what you want
> vs the standard system time domain so we don't run into problems
> understanding it later.
Perfect, that is what I would be interested in.
>
> > - "fast" means that in very rare cases, the time might appear
> >
> > to go backwards (it probably can't happen here because you are not
> > called in an NMI).
>
> "fast" really means "safe-for-nmi wrt to locking". The tradeoff being
> that when frequency adjustments occur, and if your code is delayed,
> you might see time go backwards by a small amount. This allows
My code would not see that as an issue.
> tracing/sched code (or other code called from NMI) to not have to
> duplicate the timekeeping infrastructure.
>
> I think without a much better explanation, using the "fast" method
> isn't really warranted here.
Thanks a lot. With that, I would think that the proposed ktime_get_raw_fast_ns
is good for use, which is supported with testing on my system.
>
> thanks
> -john
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v5 0/7] /dev/random - a new approach
From: Stephan Mueller @ 2016-06-21 16:28 UTC (permalink / raw)
To: Austin S. Hemmelgarn
Cc: Nikos Mavrogiannopoulos, Theodore Ts'o, Pavel Machek,
Herbert Xu, Andi Kleen, Sandy Harris, Jason Cooper, John Denker,
H. Peter Anvin, Joe Perches, George Spelvin,
Linux Crypto Mailing List, Linux Kernel Mailing List
In-Reply-To: <e2612733-f3c1-bdc0-5822-3f20c44fe781@gmail.com>
Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-21 03:32, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos:
> >
> > Hi Nikos,
> >
> >> On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller <smueller@chronox.de>
> >
> > wrote:
> >>>> Personally, I don't really use /dev/random, nor would I recommend it
> >>>> for most application programmers. At this point, getrandom(2) really
> >>>> is the preferred interface unless you have some very specialized
> >>>> needs.
> >>>
> >>> I fully agree. But there are use cases for /dev/random, notably as a
> >>> seed
> >>> source for other DRNG.
> >>
> >> Is that really the case? I believe all DRNG's use /dev/urandom anyway
> >> for seeding since they cannot afford indeterminate blocking. It would
> >> be a gain for everyone if /dev/random was the same as /dev/urandom in
> >> Linux.
> >
> > For standard approaches, this is true. But there are regulations, notably
> > in the German realm, /dev/random shall be used, at least partially (see
> > AIS 20/31).
>
> Which just goes to show how utterly stupid some people who write laws
> and regulations are. Saying specifically that '/dev/random shall be
> used' does not enforce any improvement of entrophic value in the data at
> all, it just coincidentally improves the theoretical quality of the data
> because of how Linux and some legacy UNIX systems are designed. This
> 'regulation' already provides zero benefit other than a placebo effect
> on at least OpenBSD, FreeBSD, and I'm pretty certain most other BSD
> derivatives, as /dev/random and /dev/urandom point to the same thing
> there (on OpenBSD it's an arcfour based drbg, FreeBSD does similar but
> uses a CSPRNG called Fortuna), and while I'm not certain, I believe AIX
> does likewise (although they use a design based on yarrow).
It is NOT utterly stupid, you should listen to the reasons. The core reason is
explained with the following analogy:
/dev/urandom, for a short period of time, operates as a DRNG. For the sake of
discussion, let us assume that it is a DRNG which is, for the sake of
discussion, seeded with 256 bits of entropy.
Now, you pull 256 bits out of it, you have 256 bits of entropy.
You pull again 256 bit out of it -- what entropy do you have? You do NOT have
*again* 256 bits of entropy. All you can say is the entire generated 512 bits
have collectively 256 bits of entropy. And so on and so forth.
Now, if you want to say that your newly spawned DRNG is seeded with X amount
of entropy, the DRNG nature of /dev/urandom makes such a statement a
challenge. The easy way out of the challenge is to use /dev/random (I am aware
of the fact that the DRNG has a computational strength, but it is not, well,
entropy).
In addition, when using /dev/urandom, you have to show that at the time you
seed the DRNG, it is fully seeded. That is a challenge at boot time - a
challenge this entire thread revolves around. Yes, getrandom(2) is the way
out, but not everybody uses it. Again, /dev/random does NOT have this
challenge.
>
> On top of that though, just because some poorly thought out standard
> requires it's usage doesn't mean we have to work based on that.
I cannot concur.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] crypto: use timespec64 for jent_get_nstime
From: John Stultz @ 2016-06-21 16:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Herbert Xu, Alexander Kuleshov, Stephan Mueller, lkml,
y2038 Mailman List, linux-crypto, David S. Miller, Kees Cook
In-Reply-To: <3776557.os2uYrMn6M@wuerfel>
On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
>>
> Compared to the previous __getnstimeofday(), the difference is
>
> - using "monotonic" timebase instead of "real", so the zero time
> is when the system booted rather than Jan 1 1970
I haven't looked at the details of the calling code, but I'd worry for
crypto uses, especially if its being used for entropy collection,
using the monotonic clock instead of the realtime clock might be
problematic.
> - "raw" means we don't honor updates for the rate based on ntp,
> which is probably better as the ntp state might be observable
> over the net (it probably doesn't matter, but it can't hurt)
So... this feels like a very vague explanation, and the lack of
frequency correction here probably need a really good comment. Keeping
multiple time domains is usually asking for trouble, but we added the
MONOTONIC_RAW clock to address a few cases where people really wanted
an abstract hardware counter, which was unaffected by frequency
corrections. I'd really make sure its clear why this is what you want
vs the standard system time domain so we don't run into problems
understanding it later.
> - "fast" means that in very rare cases, the time might appear
> to go backwards (it probably can't happen here because you are not
> called in an NMI).
"fast" really means "safe-for-nmi wrt to locking". The tradeoff being
that when frequency adjustments occur, and if your code is delayed,
you might see time go backwards by a small amount. This allows
tracing/sched code (or other code called from NMI) to not have to
duplicate the timekeeping infrastructure.
I think without a much better explanation, using the "fast" method
isn't really warranted here.
thanks
-john
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox