this could be fixed or what's wrong with just the xts
registration (ecb, cbc, ctr work fine).
Any ideas or hints?
Thank's in advance.
regards
Harald Freudenberger
On 02/23/2017 12:39 PM, Herbert Xu wrote:
> On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote:
>> Harald Freudenberger wrote:
>>> Hello all
>>>
>>> I am currently following a hang at modprobe aes_s390 where
>>> crypto_register_alg()
On 02/23/2017 05:02 PM, Harald Freudenberger wrote:
> On 02/23/2017 12:39 PM, Herbert Xu wrote:
>> On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote:
>>> Harald Freudenberger wrote:
>>>> Hello all
>>>>
>>>> I am
On 02/24/2017 09:42 AM, Harald Freudenberger wrote:
> On 02/23/2017 05:02 PM, Harald Freudenberger wrote:
>> On 02/23/2017 12:39 PM, Herbert Xu wrote:
>>> On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote:
>>>> Harald Freudenberger wrote:
>>>
On 02/24/2017 11:32 AM, Harald Freudenberger wrote:
> On 02/24/2017 09:42 AM, Harald Freudenberger wrote:
...
>> ...
>> Feb 24 09:28:10 r35lp49 kernel:
>> ->crypto_larval_lookup(name=aes,type=0x0405,mask=0x248c)
>> Feb 24 09:28:10 r35lp49 kernel:
YNC) & mask & CRYPTO_ALG_ASYNC;
> + return crypto_requires_off(type, mask, CRYPTO_ALG_ASYNC);
> }
>
> noinline unsigned long __crypto_memneq(const void *a, const void *b, size_t
> size);
applied the xts.c create patch v2 and the helper patch, built and installed.
Now the
; - cur_rng_set_by_user = 0;
> - /* rng_list is sorted by quality, use the best (=first) one */
> - if (!list_empty(&rng_list)) {
> - struct hwrng *new_rng;
> -
> - new_rng = list_entry(rng_list.next, struct hwrng, list);
> - set_current_rng(new_rng);
> - }
> - }
> + if (current_rng == rng)
> + enable_best_rng();
>
> if (list_empty(&rng_list)) {
> mutex_unlock(&rng_mutex);
That's a really good idea. I also thought about something like that.
regards
Harald Freudenberger
*new_rng;
> -
> - new_rng = list_entry(rng_list.next, struct hwrng, list);
> - set_current_rng(new_rng);
> - }
> - }
> + if (current_rng == rng)
> + enable_best_rng();
>
> if (list_empty(&rng_list)) {
> mutex_unlock(&rng_mutex);
looks like for me.
reviewed-by: Harald Freudenberger
Multitheaded tests showed that the icv buffer in the current ghash
implementation is not handled correctly. A move of this working ghash
buffer value to the descriptor context fixed this. Code is tested and
verified with an multithreaded application via af_alg interface.
Signed-off-by: Harald
Signed-off-by: Harald Freudenberger
---
crypto/testmgr.h | 59 +-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 90f43b9..6003143 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
et to this algorithm. However, long-term
the s390 platform will provide some kind of true hardware random number
generator and the idea is to use this for seeding the prng.
regards
Harald Freudenberger
a rng source has been set via
sysfs from userland as long as this one doesn't unregister
it is kept as current rng regardless of registration of 'better'
rng sources.
Signed-off-by: Harald Freudenberger
---
drivers/char/hw_random/core.c | 31 +--
1 file ch
a rng source has been set via
sysfs from userland as long as this one doesn't unregister
it is kept as current rng regardless of registration of 'better'
rng sources.
Signed-off-by: Harald Freudenberger
---
drivers/char/hw_random/core.c | 31 +--
1 file ch
On 06/30/2017 07:27 AM, PrasannaKumar Muralidharan wrote:
> Hi Harald,
>
> Can you split this patch into two? One patch to choose rng based on
> the quality and another for not overriding user decided rng.
>
> Some more minor comments below.
>
> On 29 June 2017 at 15:
top most rng chosen.
Signed-off-by: Harald Freudenberger
---
drivers/char/hw_random/core.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 503a41d..e9dda16 100644
--- a/drivers/char
27; shows either
the name of the rng chosen or 'none'.
Signed-off-by: Harald Freudenberger
---
drivers/char/hw_random/core.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index
When a user chooses a rng source via sysfs
attribute this rng should be sticky, even
when other sources with better quality to
register. This patch introduces a simple way
to remember the user's choise.
Signed-off-by: Harald Freudenberger
---
drivers/char/hw_random/core.c | 10
uld require to hold an string buffer
and this would introduce some string length limit on the rng name.
Another idea is that there should be a possibility to unselect
the user's choice. An echo 'none' to rng_current may be a way to
remove the selection and the hwrng may act by using th
node
accessible for all users without the need to have udev rules
rewriting the access rights.
Signed-off-by: Harald Freudenberger
---
drivers/char/hw_random/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 503a41d..40
On 07/04/2017 03:15 PM, PrasannaKumar Muralidharan wrote:
> On 3 July 2017 at 15:33, Harald Freudenberger
> wrote:
>> This patch introduces a new sysfs attribute file 'rng_selected'
>> which shows the the rng chosen by userspace.
>>
>> If a rng source is c
On 07/06/2017 06:51 AM, PrasannaKumar Muralidharan wrote:
> Hi Harald,
>
>> Here is an updated version with just showing 0 or 1 in the new sysfs
>> attribute file:
>> == cut ======
>> From: Harald Freudenberger
>> Date: Mon, 3 Jul 2017 10:19:22
top most rng chosen.
Signed-off-by: Harald Freudenberger
Reviewed-by: PrasannaKumar Muralidharan
---
drivers/char/hw_random/core.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index
Patch 2 makes hwrng remember that the user has selected an
rng via echo to /sys/class/misc/hw_random/rng_current and
adds a new sysfs attribute file 'rng_selected' to the rng core.
Harald Freudenberger (2):
crypto: hwrng use rng source with best quality
crypto: hwrng remember rng chosen by
the current rng has been chosen by
userspace. The new attribute file shows '1' for user
selected rng and '0' otherwise.
Signed-off-by: Harald Freudenberger
Reviewed-by: PrasannaKumar Muralidharan
---
drivers/char/hw_random/core.c | 21 +++--
1 file changed, 19
On 07/12/2017 12:13 PM, Herbert Xu wrote:
> On Mon, Jul 03, 2017 at 12:37:59PM +0200, Harald Freudenberger wrote:
>> Currently /dev/hwrng uses default device node permissions
>> which is 0600. So by default the device node is not accessible
>> by an ordinary user. Some d
itstream
* (per mill).
*/
...
quality = estimation of true entropy per mill.
I understand this as quality=1000 meaning 100% entropy.
However, the core code currently does not really check this value.
When more than one hwrng sources do register, simple the one with
the higher quality value wins :-) The value is not even checked
to be in a given range.
I searched through some device drivers which do register at
the hwrng and it looks like most of the drivers do not even
set this value. My feeling is, you should use 999 when your
hardware provides 'perfect' random. So there is a chance for
an even 'more perfect' hardware coming up later to overrule
your 'perfect' hardware.
regards
Harald Freudenberger
The aes-ctr mode used one preallocated page without any concurrency
protection. When multiple threads run aes-ctr encryption or decryption
this could lead to data corruption.
The patch introduces locking for the preallocated page and alternatively
allocating and freeing of an temp page in concurre
concurrency situations.
Signed-off-by: Harald Freudenberger
Harald Freudenberger (1):
s390/crypto: fix aes ctr concurrency issue
arch/s390/crypto/aes_s390.c | 55 --
1 files changed, 42 insertions(+), 13 deletions(-)
--
To unsubscribe from this list: send
On Thu, 2013-11-28 at 22:00 +0800, Herbert Xu wrote:
> On Tue, Nov 19, 2013 at 11:22:12AM +0100, Harald Freudenberger wrote:
> > The aes-ctr mode used one preallocated page without any concurrency
> > protection. When multiple threads run aes-ctr encryption or decryption
> &g
On Fri, 2013-11-29 at 09:50 +0800, Herbert Xu wrote:
> On Thu, Nov 28, 2013 at 04:39:43PM +0100, Harald Freudenberger wrote:
> >
> > > You can't use mutex_lock because you may be in a non-sleepable
> > > context. Perhaps just fall back to doing it block-by-block,
situations.
Signed-off-by: Harald Freudenberger
---
arch/s390/crypto/aes_s390.c | 65 ++-
1 file changed, 46 insertions(+), 19 deletions(-)
diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c
index b3feabd..cf3c008 100644
--- a/arch/s390
On Thu, 2014-01-16 at 16:01 +0100, Harald Freudenberger wrote:
> The aes-ctr mode uses one preallocated page without any concurrency
> protection. When multiple threads run aes-ctr encryption or decryption
> this can lead to data corruption.
>
> The patch introduces locking for
when done.
Cc: sta...@vger.kernel.org
Signed-off-by: Harald Freudenberger
---
arch/s390/crypto/des_s390.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/s390/crypto/des_s390.c b/arch/s390/crypto/des_s390.c
index 200f2a1..82a0a2a 100644
--- a
solution at concurrency situations.
Cc: sta...@vger.kernel.org
Signed-off-by: Harald Freudenberger
---
arch/s390/crypto/des_s390.c | 69 ++-
1 file changed, 48 insertions(+), 21 deletions(-)
diff --git a/arch/s390/crypto/des_s390.c b/arch/s390/crypto
An additional testcase found an issue with the last
series of patches applied: the fallback solution may
not save the iv value after operation. This very small
fix just makes sure the iv is copied back to the
walk/desc struct.
Signed-off-by: Harald Freudenberger
---
arch/s390/crypto/aes_s390.c
ion when nbytes=0 is used (should return with EINVAL but actually
returns with 0). I'll send a fix for this via the s390 maintainers.
regards
Harald Freudenberger
On 12.10.19 22:18, Eric Biggers wrote:
> This series converts the glue code for the S390 CPACF implementations of
> AES, DES, and 3DES modes from the deprecated "blkcipher" API to the
> "skcipher" API. This is needed in order for the blkcipher API to be
> removed.
>
> I've compiled this patchset,
_s390_algs_num]);
> + while (des_s390_skciphers_num--)
> +
> crypto_unregister_skcipher(des_s390_skciphers_ptr[des_s390_skciphers_num]);
> if (ctrblk)
> free_page((unsigned long) ctrblk);
> }
> @@ -518,12 +443,12 @@ static int __init des_s390_init(void)
> ret = des_s390_register_alg(&des_alg);
> if (ret)
> goto out_err;
> - ret = des_s390_register_alg(&ecb_des_alg);
> + ret = des_s390_register_skcipher(&ecb_des_alg);
> if (ret)
> goto out_err;
> }
> if (cpacf_test_func(&kmc_functions, CPACF_KMC_DEA)) {
> - ret = des_s390_register_alg(&cbc_des_alg);
> + ret = des_s390_register_skcipher(&cbc_des_alg);
> if (ret)
> goto out_err;
> }
> @@ -531,12 +456,12 @@ static int __init des_s390_init(void)
> ret = des_s390_register_alg(&des3_alg);
> if (ret)
> goto out_err;
> - ret = des_s390_register_alg(&ecb_des3_alg);
> + ret = des_s390_register_skcipher(&ecb_des3_alg);
> if (ret)
> goto out_err;
> }
> if (cpacf_test_func(&kmc_functions, CPACF_KMC_TDEA_192)) {
> - ret = des_s390_register_alg(&cbc_des3_alg);
> + ret = des_s390_register_skcipher(&cbc_des3_alg);
> if (ret)
> goto out_err;
> }
> @@ -551,12 +476,12 @@ static int __init des_s390_init(void)
> }
>
> if (cpacf_test_func(&kmctr_functions, CPACF_KMCTR_DEA)) {
> - ret = des_s390_register_alg(&ctr_des_alg);
> + ret = des_s390_register_skcipher(&ctr_des_alg);
> if (ret)
> goto out_err;
> }
> if (cpacf_test_func(&kmctr_functions, CPACF_KMCTR_TDEA_192)) {
> - ret = des_s390_register_alg(&ctr_des3_alg);
> + ret = des_s390_register_skcipher(&ctr_des3_alg);
> if (ret)
> goto out_err;
> }
Tested with extended selftests and own tests via AF_ALG interface, works.
Thanks for this great work.
reviewed-by: Harald Freudenberger
+ .exit = fallback_exit_skcipher,
> + .min_keysize= AES_MIN_KEY_SIZE,
> + .max_keysize= AES_MAX_KEY_SIZE,
> + .ivsize = AES_BLOCK_SIZE,
> + .setkey = ctr_aes_set_key,
> + .encrypt= ctr_aes_crypt,
> + .decrypt= ctr_aes_crypt,
> + .chunksize = AES_BLOCK_SIZE,
> };
>
> static int gcm_aes_setkey(struct crypto_aead *tfm, const u8 *key,
> @@ -1116,24 +971,27 @@ static struct aead_alg gcm_aes_aead = {
> },
> };
>
> -static struct crypto_alg *aes_s390_algs_ptr[5];
> -static int aes_s390_algs_num;
> +static struct crypto_alg *aes_s390_alg;
> +static struct skcipher_alg *aes_s390_skcipher_algs[4];
> +static int aes_s390_skciphers_num;
> static struct aead_alg *aes_s390_aead_alg;
>
> -static int aes_s390_register_alg(struct crypto_alg *alg)
> +static int aes_s390_register_skcipher(struct skcipher_alg *alg)
> {
> int ret;
>
> - ret = crypto_register_alg(alg);
> + ret = crypto_register_skcipher(alg);
> if (!ret)
> - aes_s390_algs_ptr[aes_s390_algs_num++] = alg;
> + aes_s390_skcipher_algs[aes_s390_skciphers_num++] = alg;
> return ret;
> }
>
> static void aes_s390_fini(void)
> {
> - while (aes_s390_algs_num--)
> - crypto_unregister_alg(aes_s390_algs_ptr[aes_s390_algs_num]);
> + if (aes_s390_alg)
> + crypto_unregister_alg(aes_s390_alg);
> + while (aes_s390_skciphers_num--)
> +
> crypto_unregister_skcipher(aes_s390_skcipher_algs[aes_s390_skciphers_num]);
> if (ctrblk)
> free_page((unsigned long) ctrblk);
>
> @@ -1154,10 +1012,11 @@ static int __init aes_s390_init(void)
> if (cpacf_test_func(&km_functions, CPACF_KM_AES_128) ||
> cpacf_test_func(&km_functions, CPACF_KM_AES_192) ||
> cpacf_test_func(&km_functions, CPACF_KM_AES_256)) {
> - ret = aes_s390_register_alg(&aes_alg);
> + ret = crypto_register_alg(&aes_alg);
> if (ret)
> goto out_err;
> - ret = aes_s390_register_alg(&ecb_aes_alg);
> + aes_s390_alg = &aes_alg;
> + ret = aes_s390_register_skcipher(&ecb_aes_alg);
> if (ret)
> goto out_err;
> }
> @@ -1165,14 +1024,14 @@ static int __init aes_s390_init(void)
> if (cpacf_test_func(&kmc_functions, CPACF_KMC_AES_128) ||
> cpacf_test_func(&kmc_functions, CPACF_KMC_AES_192) ||
> cpacf_test_func(&kmc_functions, CPACF_KMC_AES_256)) {
> - ret = aes_s390_register_alg(&cbc_aes_alg);
> + ret = aes_s390_register_skcipher(&cbc_aes_alg);
> if (ret)
> goto out_err;
> }
>
> if (cpacf_test_func(&km_functions, CPACF_KM_XTS_128) ||
> cpacf_test_func(&km_functions, CPACF_KM_XTS_256)) {
> - ret = aes_s390_register_alg(&xts_aes_alg);
> + ret = aes_s390_register_skcipher(&xts_aes_alg);
> if (ret)
> goto out_err;
> }
> @@ -1185,7 +1044,7 @@ static int __init aes_s390_init(void)
> ret = -ENOMEM;
> goto out_err;
> }
> - ret = aes_s390_register_alg(&ctr_aes_alg);
> + ret = aes_s390_register_skcipher(&ctr_aes_alg);
> if (ret)
> goto out_err;
> }
Tested with extended selftests and own tests via AF_ALG interface, works.
Thanks for this great work.
Reviewed-by: Harald Freudenberger
crypt= ctr_paes_crypt,
> + .chunksize = AES_BLOCK_SIZE,
> };
>
> -static inline void __crypto_unregister_alg(struct crypto_alg *alg)
> +static inline void __crypto_unregister_skcipher(struct skcipher_alg *alg)
> {
> - if (!list_empty(&alg->cra_list))
> - crypto_unregister_alg(alg);
> + if (!list_empty(&alg->base.cra_list))
> + crypto_unregister_skcipher(alg);
> }
>
> static void paes_s390_fini(void)
> {
> if (ctrblk)
> free_page((unsigned long) ctrblk);
> - __crypto_unregister_alg(&ctr_paes_alg);
> - __crypto_unregister_alg(&xts_paes_alg);
> - __crypto_unregister_alg(&cbc_paes_alg);
> - __crypto_unregister_alg(&ecb_paes_alg);
> + __crypto_unregister_skcipher(&ctr_paes_alg);
> + __crypto_unregister_skcipher(&xts_paes_alg);
> + __crypto_unregister_skcipher(&cbc_paes_alg);
> + __crypto_unregister_skcipher(&ecb_paes_alg);
> }
>
> static int __init paes_s390_init(void)
> @@ -717,7 +651,7 @@ static int __init paes_s390_init(void)
> if (cpacf_test_func(&km_functions, CPACF_KM_PAES_128) ||
> cpacf_test_func(&km_functions, CPACF_KM_PAES_192) ||
> cpacf_test_func(&km_functions, CPACF_KM_PAES_256)) {
> - ret = crypto_register_alg(&ecb_paes_alg);
> + ret = crypto_register_skcipher(&ecb_paes_alg);
> if (ret)
> goto out_err;
> }
> @@ -725,14 +659,14 @@ static int __init paes_s390_init(void)
> if (cpacf_test_func(&kmc_functions, CPACF_KMC_PAES_128) ||
> cpacf_test_func(&kmc_functions, CPACF_KMC_PAES_192) ||
> cpacf_test_func(&kmc_functions, CPACF_KMC_PAES_256)) {
> - ret = crypto_register_alg(&cbc_paes_alg);
> + ret = crypto_register_skcipher(&cbc_paes_alg);
> if (ret)
> goto out_err;
> }
>
> if (cpacf_test_func(&km_functions, CPACF_KM_PXTS_128) ||
> cpacf_test_func(&km_functions, CPACF_KM_PXTS_256)) {
> - ret = crypto_register_alg(&xts_paes_alg);
> + ret = crypto_register_skcipher(&xts_paes_alg);
> if (ret)
> goto out_err;
> }
> @@ -740,7 +674,7 @@ static int __init paes_s390_init(void)
> if (cpacf_test_func(&kmctr_functions, CPACF_KMCTR_PAES_128) ||
> cpacf_test_func(&kmctr_functions, CPACF_KMCTR_PAES_192) ||
> cpacf_test_func(&kmctr_functions, CPACF_KMCTR_PAES_256)) {
> - ret = crypto_register_alg(&ctr_paes_alg);
> + ret = crypto_register_skcipher(&ctr_paes_alg);
> if (ret)
> goto out_err;
> ctrblk = (u8 *) __get_free_page(GFP_KERNEL);
Tested with extended selftests and own tests via AF_ALG interface, works.
Thanks for this great work.
reviewed-by: Harald Freudenberger
On 16.10.19 19:05, Eric Biggers wrote:
> On Tue, Oct 15, 2019 at 01:31:39PM +0200, Harald Freudenberger wrote:
>> On 12.10.19 22:18, Eric Biggers wrote:
>>> From: Eric Biggers
>>>
>>> Convert the glue code for the S390 CPACF protected key implementations
>&
ric kernel interface for some kind
of key token as a binary blob. I am also open to use the kernel key
ring for future extensions. But please understand we needed a way
to support our hardware keys and I think the chosen design isn't
so bad.
regards Harald Freudenberger
using the kernel key ring in future extensions.
rest of the function is executed.
Is this the intention? Shouldn't the condition
terminate the function either when there are fewer
than 64 mixes in the pool OR time since last
invocation is < 1 s ?
regards
Harald Freudenberger
have or will have true random entropy
source hardware and may also like to contribute to the linux random
device driver.
Does this sound reasonable? If yes, I'll start some investigation and
try to develop something for random.c. Though this may take some time.
regards and thanks for your time
Harald Freudenberger
gt; Thanks for the pointer.
> So the preferred way is defining a new crypto algorithm prefixed with
> "p" and reusing setkey to provide the key reference.
The "p" in paes is because we call it "protected key aes". I think you are not
limited
to the "p". What Herbert tries to point out is that you may define your own
cipher with an unique name and there you can handle your secure key references
as you like. You may use the s390 paes implementation as a starting point.
regards Harald Freudenberger
>
> Thanks,
> //richard
>
7 +127,7 @@ static int __init init(void)
> int ret;
>
> if (!cpacf_query_func(CPACF_KIMD, CPACF_KIMD_SHA_512))
> - return -EOPNOTSUPP;
> + return -ENODEV;
> if ((ret = crypto_register_shash(&sha512_alg)) < 0)
> goto out;
> if ((ret = crypto_register_shash(&sha384_alg)) < 0)
fine with me
Reviewed-by: Harald Freudenberger
"start in SHA-512 mode\n");
> - return -EOPNOTSUPP;
> + return -ENODEV;
> }
> prng_mode = PRNG_MODE_TDES;
> } else
fine with me
Reviewed-by: Harald Freudenberger
/ghash_s390.c
> @@ -137,7 +137,7 @@ static struct shash_alg ghash_alg = {
> static int __init ghash_mod_init(void)
> {
> if (!cpacf_query_func(CPACF_KIMD, CPACF_KIMD_GHASH))
> - return -EOPNOTSUPP;
> + return -ENODEV;
>
> return crypto_register_shash(&ghash_alg);
> }
fine with me
Reviewed-by: Harald Freudenberger
return -ENODEV;
>
> pkey_debug_init();
>
You missed one match in this file. Function pkey_clr2protkey()
also does a cpacf_test_func() and may return -EOPNOTSUPP.
I checked the call chain, it's save to change the returncode there also.
If done, Thanks and add my
reviewed-by: Harald Freudenberger
On 12.06.19 12:41, David Hildenbrand wrote:
> On 12.06.19 12:39, Harald Freudenberger wrote:
>> On 12.06.19 12:22, David Hildenbrand wrote:
>>> systemd-modules-load.service automatically tries to load the pkey module
>>> on systems that have MSA.
>>>
>>&g
= __des3_verify_key(&tfm->crt_flags, key);
> + err = crypto_des3_ede_verify_key(tfm, key, key_len);
> if (unlikely(err))
> return err;
>
Fine with me, Thanks,
Acked-by: Harald Freudenberger
On 05.08.19 19:00, Ard Biesheuvel wrote:
> Acked-by: Harald Freudenberger
> Signed-off-by: Ard Biesheuvel
> ---
> arch/s390/crypto/des_s390.c | 25 +---
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/arch/s390/crypto/des_s390.c b/arch/s
On 06.06.2018 15:11, Stephan Mueller wrote:
> Am Mittwoch, 6. Juni 2018, 14:48:33 CEST schrieb Harald Freudenberger:
>
> Hi Harald,
>> I am still searching for a way to provide our good hardware entropy
>> source to the random pool in the random device driver. So I'd
On 06.06.2018 16:26, PrasannaKumar Muralidharan wrote:
> Hi Herald,
>
> On 6 June 2018 at 18:18, Harald Freudenberger wrote:
>> Hello Theodore, hi Linux Community
>>
>> my patch for the s390 arch_get_random_seed* implementation is about to
>> be integrated with th
54 matches
Mail list logo
