Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 11:16:10 CEST schrieb Arnd Bergmann: Hi Arnd, > I guess ideally you just move the inner half of lrng_get_jent(), > i.e. everything inside of the spinlock, plus the buffer, into that file. > That should keep the low-level side separate from the caller. Yes, I concur.

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 11:16:10 CEST schrieb Arnd Bergmann: Hi Arnd, > I guess ideally you just move the inner half of lrng_get_jent(), > i.e. everything inside of the spinlock, plus the buffer, into that file. > That should keep the low-level side separate from the caller. Yes, I concur.

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Arnd Bergmann
On Tue, Jul 18, 2017 at 11:10 AM, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 11:02:02 CEST schrieb Arnd Bergmann: > > Hi Arnd, >> >> I can see why the jitterentropy implementation avoids using kernel headers, >> the problem now is that part of it gets moved into a

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Arnd Bergmann
On Tue, Jul 18, 2017 at 11:10 AM, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 11:02:02 CEST schrieb Arnd Bergmann: > > Hi Arnd, >> >> I can see why the jitterentropy implementation avoids using kernel headers, >> the problem now is that part of it gets moved into a new header, and that >>

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 11:02:02 CEST schrieb Arnd Bergmann: Hi Arnd, > > I can see why the jitterentropy implementation avoids using kernel headers, > the problem now is that part of it gets moved into a new header, and that > already violates the original principle. > > From my reading of

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 11:02:02 CEST schrieb Arnd Bergmann: Hi Arnd, > > I can see why the jitterentropy implementation avoids using kernel headers, > the problem now is that part of it gets moved into a new header, and that > already violates the original principle. > > From my reading of

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Arnd Bergmann
On Tue, Jul 18, 2017 at 10:49 AM, Greg Kroah-Hartman wrote: > On Tue, Jul 18, 2017 at 10:40:07AM +0200, Stephan Müller wrote: >> Am Dienstag, 18. Juli 2017, 10:30:14 CEST schrieb Greg Kroah-Hartman: >> >> Hi Greg, >> >> > > +typedef unsigned long long __u64; >> >

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Arnd Bergmann
On Tue, Jul 18, 2017 at 10:49 AM, Greg Kroah-Hartman wrote: > On Tue, Jul 18, 2017 at 10:40:07AM +0200, Stephan Müller wrote: >> Am Dienstag, 18. Juli 2017, 10:30:14 CEST schrieb Greg Kroah-Hartman: >> >> Hi Greg, >> >> > > +typedef unsigned long long __u64; >> > > +typedef long long

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 10:49:59 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > > This issue was discussed during the inclusion of the Jitter RNG C code > > into > > the kernel. > > Ok, that was then, this is now, why not change it now? How does > including types.h change anything? At the

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 10:49:59 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > > This issue was discussed during the inclusion of the Jitter RNG C code > > into > > the kernel. > > Ok, that was then, this is now, why not change it now? How does > including types.h change anything? At the

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Greg Kroah-Hartman
On Tue, Jul 18, 2017 at 10:40:07AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 10:30:14 CEST schrieb Greg Kroah-Hartman: > > Hi Greg, > > > > +typedef unsigned long long __u64; > > > +typedef long long __s64; > > > > types.h already has these defines, don't

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Greg Kroah-Hartman
On Tue, Jul 18, 2017 at 10:40:07AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 10:30:14 CEST schrieb Greg Kroah-Hartman: > > Hi Greg, > > > > +typedef unsigned long long __u64; > > > +typedef long long __s64; > > > > types.h already has these defines, don't

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 10:30:14 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > +typedefunsigned long long __u64; > > +typedeflong long __s64; > > types.h already has these defines, don't re-typedef them again... The issue is that the C code is compiled without

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 10:30:14 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > +typedefunsigned long long __u64; > > +typedeflong long __s64; > > types.h already has these defines, don't re-typedef them again... The issue is that the C code is compiled without

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Greg Kroah-Hartman
On Tue, Jul 18, 2017 at 09:57:55AM +0200, Stephan Müller wrote: > --- /dev/null > +++ b/include/crypto/jitterentropy.h > @@ -0,0 +1,80 @@ > +/* > + * Copyright (C) 2017, Stephan Mueller > + * > + * Redistribution and use in source and binary forms, with or without > + *

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Greg Kroah-Hartman
On Tue, Jul 18, 2017 at 09:57:55AM +0200, Stephan Müller wrote: > --- /dev/null > +++ b/include/crypto/jitterentropy.h > @@ -0,0 +1,80 @@ > +/* > + * Copyright (C) 2017, Stephan Mueller > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are

[RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Stephan Müller
To support the LRNG operation which allocates the Jitter RNG separately from the kernel crypto API, extract the relevant information into a separate header file. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld

[RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

2017-07-18 Thread Stephan Müller
To support the LRNG operation which allocates the Jitter RNG separately from the kernel crypto API, extract the relevant information into a separate header file. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld Signed-off-by: Stephan Mueller --- crypto/jitterentropy.c