Hi Eric,
> It isn't clearly defined what happens if you read from an AF_ALG request
> socket without previously sending the control data to begin an
> encryption or decryption operation. On some kernels the read will
> return 0, while on others it will block.
> Testing this corner case isn't the
To support the LRNG operation which uses the Jitter RNG separately
from the kernel crypto API, at a time where potentially the regular
memory management is not yet initialized, the Jitter RNG needs to
provide a state whose memory is defined at compile time. As only once
instance will ever be needed
Using the LRNG switchable DRNG support, the SP800-90A DRBG extension is
implemented.
The DRBG uses the kernel crypto API DRBG implementation. In addition, it
uses the kernel crypto API SHASH support to provide the hashing
operation.
The DRBG supports the choice of either a CTR DRBG using AES-256,
Add runtime-pluggable support for all PRNGs that are accessible via
the kernel crypto API, including hardware PRNGs. The PRNG is selected
with the module parameter drng_name where the name must be one that the
kernel crypto API can resolve into an RNG.
This allows using of the kernel crypto API PR
Hi,
The following patch set provides a different approach to /dev/random which is
called Linux Random Number Generator (LRNG) to collect entropy within the Linux
kernel. The main improvements compared to the existing /dev/random is to provide
sufficient entropy during boot time as well as in virtu
This patch allows several DRBG functions to be called by the LRNG kernel
code paths outside the drbg.c file.
CC: "Eric W. Biederman"
CC: "Alexander E. Patrakov"
CC: "Ahmed S. Darwish"
CC: "Theodore Y. Ts'o"
CC: Willy Tarreau
CC: Matthew Garrett
CC: Vito Caputo
CC: Andreas Dilger
CC: Jan Ka
From 4a94cf2db12d5d1f8fd3354ea0da2c5726f96ac7 Mon Sep 17 00:00:00 2001
From: Stephan Mueller
Date: Sun, 19 Jan 2020 21:23:17 +0100
Subject:
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The Jitter RNG fast noise source implemented as part of the kernel
In order to improve NUMA-locality when serving getrandom(2) requests,
allocate one DRNG instance per node.
The DRNG instance that is present right from the start of the kernel is
reused as the first per-NUMA-node DRNG. For all remaining online NUMA
nodes a new DRNG instance is allocated.
During b
The DRNG switch support allows replacing the DRNG mechanism of the
LRNG. The switching support rests on the interface definition of
include/linux/lrng.h. A new DRNG is implemented by filling in the
interface defined in this header file.
In addition to the DRNG, the extension also has to provide a
In an effort to provide a flexible implementation for a random number
generator that also delivers entropy during early boot time, allows
replacement of the deterministic random number generation mechanism,
implement the various components in separate code for easier
maintenance, and provide compli
Implement health tests for LRNG's slow noise sources as mandated by
SP-800-90B The file contains the following health tests:
- stuck test: The stuck test calculates the first, second and third
discrete derivative of the time stamp to be processed by the LFSR.
Only if all three values are non-z
The LRNG sysctl interface provides the same controls as the existing
/dev/random implementation. These sysctls behave identically and are
implemented identically. The goal is to allow a possible merge of the
existing /dev/random implementation with this implementation which
implies that this patch
Parts of the LRNG are already covered by self-tests, including:
* Self-test of SP800-90A DRBG provided by the Linux kernel crypto API.
* Self-test of the PRNG provided by the Linux kernel crypto API.
* Raw noise source data testing including SP800-90B compliant
tests when enabling CONFIG_LRNG_
The test interface allows a privileged process to capture the raw
unconditioned noise that is collected by the LRNG for statistical
analysis. Such testing allows the analysis how much entropy
the interrupt noise source provides on a given platform.
Extracted noise data is not used to seed the LRNG.
As we're already using Kconfig to disable 64-bit builds for this
driver, there is no point in doing it again in the source code.
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index 3363ca4b1a98..bfc4ac0e4ac4 100644
--- a/drivers/crypto/hifn_795x.c
Eric Biggers wrote:
>
> Since proto_ops are almost identical, and only one is used in a given kernel
> build, why not just do:
>
> static struct proto_ops algif_rng_ops = {
>...
> #ifdef CONFIG_CRYPTO_USER_API_RNG_CAVP
>.sendmsg= rng_sendmsg,
> #else
>.sendmsg
On Mon, Aug 17, 2020 at 03:03:11PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> I'm not sure if there's already a patch for this, but I notices arm64
> allmodconfig fails to build with GCC 10.2 as shown below:
>
> crypto/aegis128-neon-inner.c: In function 'crypto_aegis128_init_neon':
> crypto/aegis128
On Tue, Aug 11, 2020 at 05:30:41PM +0300, Horia Geantă wrote:
>
> > + if (IS_ERR(fallback)) {
> > + pr_err("Failed to allocate %s fallback: %ld\n",
> > + tfm_name, PTR_ERR(fallback));
> > + return PTR_ERR(fallback);
> Shouldn't
On Thu, Aug 06, 2020 at 07:35:43PM +0300, Andrei Botila wrote:
>
> +static bool xts_skcipher_ivsize(struct skcipher_request *req)
> +{
> + struct crypto_skcipher *skcipher = crypto_skcipher_reqtfm(req);
> + unsigned int ivsize = crypto_skcipher_ivsize(skcipher);
> + u64 size = 0;
> +
>
On Thu, Aug 06, 2020 at 05:28:14PM +0200, Laurent Vivier wrote:
.
> +static size_t rng_max_buffer_size(struct hwrng *rng)
> +{
> + size_t size;
> +
> + size = max_t(size_t, rng->buffer_size, SMP_CACHE_BYTES);
> +
> + /* rng_buffer can store up to PAGE_SIZE */
> + return min(PAGE_SIZ
Provide an error message for users when pci_request_mem_regions failed.
Signed-off-by: George Acosta
---
drivers/crypto/cavium/nitrox/nitrox_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/cavium/nitrox/nitrox_main.c
b/drivers/crypto/cavium/nitrox/nitrox_main.c
index c
On Thu, Aug 20, 2020 at 03:09:55PM -0700, Ben Greear wrote:
>
> I have always assumed that I need aesni instructions to have any chance at
> this performing well,
> but there are certainly chips out there that don't have aesni, so possibly it
> is still worth improving
> if it is relatively easy
On 8/20/20 1:10 PM, Herbert Xu wrote:
On Thu, Aug 20, 2020 at 06:54:58AM -0700, Ben Greear wrote:
Here's a run on an: Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz
testing speed of async cmac(aes-aesni) (cmac(aes-aesni))
[ 259.397910] tcrypt: test 8 ( 1024 byte blocks, 1024 byte
On Thu, Aug 20, 2020 at 06:54:58AM -0700, Ben Greear wrote:
>
> Here's a run on an: Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz
>
>testing speed of async cmac(aes-aesni) (cmac(aes-aesni))
>
> [ 259.397910] tcrypt: test 8 ( 1024 byte blocks, 1024 bytes per update, 1
> updates):
On Thu, Aug 20, 2020 at 06:27:36AM -0700, Tom Rix wrote:
> There are many divide by 0 reports. This one got attention because it is in
> crypto, where i believe problems, even false positives, should be fixed.
Please don't top post.
AS your bug report is a false positive I'm rejecting your patc
From: Eric Biggers
It isn't clearly defined what happens if you read from an AF_ALG request
socket without previously sending the control data to begin an
encryption or decryption operation. On some kernels the read will
return 0, while on others it will block.
Testing this corner case isn't th
From: Eric Biggers
Add a helper function which sends data to an AF_ALG request socket,
including control data. This is needed by af_alg02, but it may also be
useful for other AF_ALG tests in the future.
Signed-off-by: Eric Biggers
---
include/tst_af_alg.h | 32 ++
lib/tst_
It isn't clearly defined what happens if you read from an AF_ALG request
socket without previously sending the control data to begin an
encryption or decryption operation. On some kernels the read will
return 0, while on others it will block.
Testing this corner case isn't the purpose of af_alg02
Hi Atte,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bc752d2f345bf55d71b3422a6a24890ea03168dc]
url:
https://github.com/0day-ci/linux/commits/Atte-Tommiska/hwrng-add-support-for-Xiphera-XIP8001B/20200820-190349
base
test robot
---
url:
https://github.com/0day-ci/linux/commits/Atte-Tommiska/hwrng-add-support-for-Xiphera-XIP8001B/20200820-190349
base:bc752d2f345bf55d71b3422a6a24890ea03168dc
xiphera-trng.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/char/hw_random/xiphera-trng.c
+++ b
On 8/20/20 12:56 AM, Ard Biesheuvel wrote:
On Thu, 20 Aug 2020 at 09:54, Herbert Xu wrote:
On Thu, Aug 20, 2020 at 09:48:02AM +0200, Ard Biesheuvel wrote:
Or are you saying on Ben's machine cbc-aesni would have worse
performance vs. aes-generic?
Yes, given the pathological overhead of FP
There are many divide by 0 reports. This one got attention because it is in
crypto, where i believe problems, even false positives, should be fixed.
Tom
On 8/20/20 12:15 AM, Herbert Xu wrote:
> On Sun, Aug 02, 2020 at 10:12:47AM -0700, t...@redhat.com wrote:
>> From: Tom Rix
>>
>> Clang static
Hi "Stephan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on cryptodev/master crypto/master v5.9-rc1
next-20200820]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
Hi "Stephan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on cryptodev/master crypto/master v5.9-rc1
next-20200820]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
Am Donnerstag, 20. August 2020, 13:46:49 CEST schrieb kernel test robot:
Hi,
> All warnings (new ones prefixed by >>):
> >> drivers/char/lrng/lrng_interfaces.c:120:6: warning: no previous prototype
> >> for 'add_hwgenerator_randomness' [-Wmissing-prototypes]
> 120 | void add_hwgenerator_rand
Am Donnerstag, 20. August 2020, 14:07:40 CEST schrieb kernel test robot:
Hi,
>
> All warnings (new ones prefixed by >>):
> >> drivers/char/lrng/lrng_drbg.c:226:1: warning: 'static' is not at
> >> beginning of declaration [-Wold-style-declaration]
> 226 | const static struct lrng_crypto_cb l
Hi "Stephan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on cryptodev/master crypto/master v5.9-rc1
next-20200820]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
Hi "Stephan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on cryptodev/master crypto/master v5.9-rc1
next-20200820]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
Xiphera is an FPGA-based cryptographic solutions provider based in
Finland.
Website of the company: https://xiphera.com/
Signed-off-by: Atte Tommiska
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings
Document the device tree bindings of Xiphera's XIP8001B-trng IP.
Signed-off-by: Atte Tommiska
---
.../bindings/rng/xiphera,xip8001b-trng.yaml | 33 +++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/rng/xiphera,xip8001b-trng.yaml
diff -
On 20/08/2020 01:37, Rob Herring wrote:
> On Wed, 19 Aug 2020 15:21:34 +0300, Atte Tommiska wrote:
>> Document the device tree bindings of Xiphera's XIP8001B-trng IP.
>>
>> Signed-off-by: Atte Tommiska
>> ---
>> .../bindings/rng/xiphera,xip8001b-trng.yaml | 30 +++
>> 1 file cha
Xiphera XIP8001B is an FPGA-based True Random Number Generator
Intellectual Property (IP) Core which can be instantiated in
multiple FPGA families. This driver adds Linux support for it through
the hwrng interface.
Signed-off-by: Atte Tommiska
---
drivers/char/hw_random/Kconfig| 10 ++
This patchset introduces a linux driver for Xiphera's XIP8001B IP.
The IP is an FPGA-based TRNG which can be used in various FPGA families.
The IP is in use in multiple customer projects and in Xiphera's own products.
v2: fixed the 'make dt_binding_check' errors in the devicetree schema.
Atte Tom
Implement health tests for LRNG's slow noise sources as mandated by
SP-800-90B The file contains the following health tests:
- stuck test: The stuck test calculates the first, second and third
discrete derivative of the time stamp to be processed by the LFSR.
Only if all three values are non-z
In an effort to provide a flexible implementation for a random number
generator that also delivers entropy during early boot time, allows
replacement of the deterministic random number generation mechanism,
implement the various components in separate code for easier
maintenance, and provide compli
In order to improve NUMA-locality when serving getrandom(2) requests,
allocate one DRNG instance per node.
The DRNG instance that is present right from the start of the kernel is
reused as the first per-NUMA-node DRNG. For all remaining online NUMA
nodes a new DRNG instance is allocated.
During b
The DRNG switch support allows replacing the DRNG mechanism of the
LRNG. The switching support rests on the interface definition of
include/linux/lrng.h. A new DRNG is implemented by filling in the
interface defined in this header file.
In addition to the DRNG, the extension also has to provide a
The LRNG sysctl interface provides the same controls as the existing
/dev/random implementation. These sysctls behave identically and are
implemented identically. The goal is to allow a possible merge of the
existing /dev/random implementation with this implementation which
implies that this patch
Using the LRNG switchable DRNG support, the SP800-90A DRBG extension is
implemented.
The DRBG uses the kernel crypto API DRBG implementation. In addition, it
uses the kernel crypto API SHASH support to provide the hashing
operation.
The DRBG supports the choice of either a CTR DRBG using AES-256,
The Jitter RNG fast noise source implemented as part of the kernel
crypto API is queried for 256 bits of entropy at the time the seed
buffer managed by the LRNG is about to be filled.
CC: "Eric W. Biederman"
CC: "Alexander E. Patrakov"
CC: "Ahmed S. Darwish"
CC: "Theodore Y. Ts'o"
CC: Willy Ta
Hi,
The following patch set provides a different approach to /dev/random which is
called Linux Random Number Generator (LRNG) to collect entropy within the Linux
kernel. The main improvements compared to the existing /dev/random is to provide
sufficient entropy during boot time as well as in virtu
To support the LRNG operation which uses the Jitter RNG separately
from the kernel crypto API, at a time where potentially the regular
memory management is not yet initialized, the Jitter RNG needs to
provide a state whose memory is defined at compile time. As only once
instance will ever be needed
The test interface allows a privileged process to capture the raw
unconditioned noise that is collected by the LRNG for statistical
analysis. Such testing allows the analysis how much entropy
the interrupt noise source provides on a given platform.
Extracted noise data is not used to seed the LRNG.
This patch allows several DRBG functions to be called by the LRNG kernel
code paths outside the drbg.c file.
CC: "Eric W. Biederman"
CC: "Alexander E. Patrakov"
CC: "Ahmed S. Darwish"
CC: "Theodore Y. Ts'o"
CC: Willy Tarreau
CC: Matthew Garrett
CC: Vito Caputo
CC: Andreas Dilger
CC: Jan Ka
Add runtime-pluggable support for all PRNGs that are accessible via
the kernel crypto API, including hardware PRNGs. The PRNG is selected
with the module parameter drng_name where the name must be one that the
kernel crypto API can resolve into an RNG.
This allows using of the kernel crypto API PR
Parts of the LRNG are already covered by self-tests, including:
* Self-test of SP800-90A DRBG provided by the Linux kernel crypto API.
* Self-test of the PRNG provided by the Linux kernel crypto API.
* Raw noise source data testing including SP800-90B compliant
tests when enabling CONFIG_LRNG_
On Thu, 20 Aug 2020 at 09:54, Herbert Xu wrote:
>
> On Thu, Aug 20, 2020 at 09:48:02AM +0200, Ard Biesheuvel wrote:
> >
> > > Or are you saying on Ben's machine cbc-aesni would have worse
> > > performance vs. aes-generic?
> > >
> >
> > Yes, given the pathological overhead of FPU preserve/restore
On Thu, Aug 20, 2020 at 09:48:02AM +0200, Ard Biesheuvel wrote:
>
> > Or are you saying on Ben's machine cbc-aesni would have worse
> > performance vs. aes-generic?
> >
>
> Yes, given the pathological overhead of FPU preserve/restore for every
> block of 16 bytes processed by the cbcmac wrapper.
On Thu, 20 Aug 2020 at 09:44, Herbert Xu wrote:
>
> On Thu, Aug 20, 2020 at 09:33:21AM +0200, Ard Biesheuvel wrote:
> >
> > > On my machine the performance difference on a 1472-byte request
> > > between SIMD and generic is 2161 vs. 7558 (cycles).
> >
> > Sure. But your machine does not have the p
On Thu, Aug 20, 2020 at 09:33:21AM +0200, Ard Biesheuvel wrote:
>
> > On my machine the performance difference on a 1472-byte request
> > between SIMD and generic is 2161 vs. 7558 (cycles).
>
> Sure. But your machine does not have the pathological FPU
> preserve/restore performance.
Why does that
On Thu, 20 Aug 2020 at 09:29, Herbert Xu wrote:
>
> On Thu, Aug 20, 2020 at 09:19:16AM +0200, Ard Biesheuvel wrote:
> >
> > Actually, I'm not so sure that they will be so much worse. The
> > expensive FPU preserve/restore occurs for every 16 bytes of data
> > processed by the AES cipher, which I'd
On Thu, Aug 20, 2020 at 09:19:16AM +0200, Ard Biesheuvel wrote:
>
> Actually, I'm not so sure that they will be so much worse. The
> expensive FPU preserve/restore occurs for every 16 bytes of data
> processed by the AES cipher, which I'd estimate to take ~10 cycles per
> byte for an unaccelerated
On Thu, 20 Aug 2020 at 09:06, Herbert Xu wrote:
>
> On Thu, Aug 20, 2020 at 09:04:26AM +0200, Ard Biesheuvel wrote:
> >
> > I don't disagree with that, especially given all the effort that went
> > into optimizing FPU preserve/restore on both arm64 and x86. But the
> > bottom line is that this is
On Sun, Aug 02, 2020 at 10:12:47AM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> Clang static analysis reports this error
>
> crypto/drbg.c:441:40: warning: Division by zero
> padlen = (inputlen + sizeof(L_N) + 1) % (drbg_blocklen(drbg));
> ~~
On Thu, Aug 20, 2020 at 09:04:26AM +0200, Ard Biesheuvel wrote:
>
> I don't disagree with that, especially given all the effort that went
> into optimizing FPU preserve/restore on both arm64 and x86. But the
> bottom line is that this is what is causing the degradation in Ben's
> case, so we cannot
On Thu, 20 Aug 2020 at 09:01, Herbert Xu wrote:
>
> On Thu, Aug 20, 2020 at 08:58:15AM +0200, Ard Biesheuvel wrote:
> >
> > But if we look at the actual issue at hand, we might also look into
> > amortizing the FPU preserve/restore over multiple invocations of a
> > cipher. I proposed a patch a wh
On Thu, Aug 20, 2020 at 08:58:15AM +0200, Ard Biesheuvel wrote:
>
> But if we look at the actual issue at hand, we might also look into
> amortizing the FPU preserve/restore over multiple invocations of a
> cipher. I proposed a patch a while ago that makes cipher an internal
> crypto API abstractio
67 matches
Mail list logo
