Changes v2:
* port the patch to current cryptodev tree plus the async seeding DRBG patches
---8<---
As required by SP800-90A, the DRBG implements are reseeding threshold.
This threshold is at 2**48 (64 bit) and 2**32 bit (32 bit) as
implemented in drbg_max_requests.
With the recently introduced
On Tue, Jun 09, 2015 at 05:27:46PM +0200, Stephan Mueller wrote:
>
> I see one: the reset of the threshold to the "normal" value must happen at
> two
> places: the one place is in the async handler. The 2nd place is when the
> request to random.c returns 0 (i.e. fully initialized). The 2nd locat
Am Dienstag, 9. Juni 2015, 23:26:05 schrieb Herbert Xu:
Hi Herbert,
> On Tue, Jun 09, 2015 at 05:22:32PM +0200, Stephan Mueller wrote:
> > Am Dienstag, 9. Juni 2015, 22:25:25 schrieb Herbert Xu:
> >
> > Hi Herbert,
> >
> > > Anyway, I'm happy to apply this. However, the patch is corrupted
> >
On Tue, Jun 09, 2015 at 05:22:32PM +0200, Stephan Mueller wrote:
> Am Dienstag, 9. Juni 2015, 22:25:25 schrieb Herbert Xu:
>
> Hi Herbert,
>
> >
> > Anyway, I'm happy to apply this. However, the patch is corrupted
> > so please resend it without the white-space damage/line wrapping.
>
> As thi
Am Dienstag, 9. Juni 2015, 22:25:25 schrieb Herbert Xu:
Hi Herbert,
>
> Anyway, I'm happy to apply this. However, the patch is corrupted
> so please resend it without the white-space damage/line wrapping.
As this patch would clash with the async seeding patch, shall I develop this
patch on to
On Tue, Jun 09, 2015 at 04:08:49AM +0200, Stephan Mueller wrote:
>
> Replace the global -O0 compiler flag from the Makefile with GCC
> pragmas to mark only the functions required to be compiled without
> optimizations.
>
> This patch also adds a comment describing the rationale for the
> functions
On Fri, Jun 05, 2015 at 03:51:18PM -0700, Tadeusz Struk wrote:
> The device doensn't support the default value and will change it to 256, which
> will cause performace degradation for biger packets.
> Add an explicit write to set it to 1024.
>
> Reported-by: Tianliang Wang
> Signed-off-by: Tadeus
LABBE Corentin wrote:
> Hello
>
>
>
> I was adding a test to testmgr for cbc(aes) but I hesitate on the
> cipher_testvec parameter also_non_
On Sun, Jun 07, 2015 at 12:04:17AM +0200, Stephan Mueller wrote:
> Hi,
>
> may I ask for review of the following patch. I would like particular feedback
> to the initial threshold value, which the patch currently sets to 50 (requests
> by a caller to the DRBG for random numbers). Thank you.
>
> I
Am Tuesday 09 June 2015, 22:17:43 schrieb Herbert Xu:
Hi Herbert,
>On Mon, Jun 08, 2015 at 02:42:50PM +0200, Stephan Mueller wrote:
>> When compiling the DRBG statically into the kernel, the testmgr
>> allocation of the DRBG may be done at a time the Jitter RNG is
>> not available as it is regist
On Mon, Jun 08, 2015 at 02:42:50PM +0200, Stephan Mueller wrote:
> When compiling the DRBG statically into the kernel, the testmgr
> allocation of the DRBG may be done at a time the Jitter RNG is
> not available as it is registered later. The patch changes the
> initialization to be invoked in subs
From: Stephan Mueller
The get_blocking_random_bytes API is broken because the wait can
be arbitrarily long (potentially forever) so there is no safe way
of calling it from within the kernel.
This patch replaces it with the new callback API which does not
have this problem.
The patch also remove
On Tue, Jun 09, 2015 at 02:23:39PM +0200, Stephan Mueller wrote:
>
> I am wondering about the error here. The Jitter RNG has in its init function
> a
> test to see whether the RNG really works on the hardware as there are still
> systems out there that have no high-res timer (e.g. I have seen th
Am Dienstag, 9. Juni 2015, 18:19:41 schrieb Herbert Xu:
Hi Herbert,
first of all, thanks a lot for your help. I have tested the patch set.
...
> /*
> * DRBG instantiation function as required by SP800-90A - this function
> * sets up the DRBG handle, performs the initial seeding and all san
From: Stephan Mueller
The get_blocking_random_bytes API is broken because the wait can
be arbitrarily long (potentially forever) so there is no safe way
of calling it from within the kernel.
This patch replaces it with the new callback API which does not
have this problem.
The patch also remove
The get_blocking_random_bytes API is broken because the wait can
be arbitrarily long (potentially forever) so there is no safe way
of calling it from within the kernel.
This patch replaces it with the new callback API which does not
have this problem.
The patch also removes the entropy buffer reg
This patch removes the kernel blocking API as it has been completely
replaced by the callback API.
Signed-off-by: Herbert Xu
---
drivers/char/random.c | 12
include/linux/random.h |1 -
2 files changed, 13 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/rando
The get_blocking_random_bytes API is broken because the wait can
be arbitrarily long (potentially forever) so there is no safe way
of calling it from within the kernel.
This patch replaces it with a callback API instead. The callback
is invoked potentially from interrupt context so the user needs
Hi:
This series replaces the blocking API for random pool readiness
with a callback API. The reason is that the random pool may not
become ready for quite some time so we cannot really wait for it
in a kernel thread as we quickly run into the 2-minute time limit
for detecting lockups.
Cheers,
--
19 matches
Mail list logo
