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
in concurrency situations.
Signed-off-by: Harald Freudenberger fre...@linux.vnet.ibm.com
Harald Freudenberger (1):
s390/crypto: fix aes ctr concurrency issue
arch/s390/crypto/aes_s390.c | 55 --
1 files changed, 42 insertions(+), 13 deletions
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
this could lead to data
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, like
we do in aesni-intel on x86
situations.
Signed-off-by: Harald Freudenberger fre...@linux.vnet.ibm.com
---
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
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 the page
when done.
Cc: sta...@vger.kernel.org
Signed-off-by: Harald Freudenberger fre...@linux.vnet.ibm.com
---
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
solution at concurrency situations.
Cc: sta...@vger.kernel.org
Signed-off-by: Harald Freudenberger fre...@linux.vnet.ibm.com
---
arch/s390/crypto/des_s390.c | 69 ++-
1 file changed, 48 insertions(+), 21 deletions(-)
diff --git a/arch/s390/crypto/des_s390.c b
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 fre...@linux.vnet.ibm.com
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 fre...@linux.vnet.ibm.com
---
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
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/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:
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 <fre...@linux.vnet.ibm.com> wrote:
>>> Hello all
>>>
>>> I am currently following a hang at modprobe aes_s390 where
&g
e patch v2 and the helper patch, built and installed.
Now the aes_s390 module loads perfect without any hang, no complains
in syslog and /proc/crypto shows that all selftests for the algs in the module
passed successful.
Thanks all for your help :-)
regards, Harald Freudenberger
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
and the top most rng chosen.
Signed-off-by: Harald Freudenberger <fre...@linux.vnet.ibm.com>
Reviewed-by: PrasannaKumar Muralidharan <prasannatsmku...@gmail.com>
---
drivers/char/hw_random/core.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/
has been chosen by
userspace. The new attribute file shows '1' for user
selected rng and '0' otherwise.
Signed-off-by: Harald Freudenberger <fre...@linux.vnet.ibm.com>
Reviewed-by: PrasannaKumar Muralidharan <prasannatsmku...@gmail.com>
---
drivers/char/hw_random
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. So
true entropy in RNG's bitstream
* (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
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:
and the top most rng chosen.
Signed-off-by: Harald Freudenberger <fre...@linux.vnet.ibm.com>
---
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..e
the name of the rng chosen or 'none'.
Signed-off-by: Harald Freudenberger <fre...@linux.vnet.ibm.com>
---
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
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 <fre...@linux.vnet.ibm.com>
---
drivers/char/hw_
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 the quality best
rng.
Harald Freudenberger (3):
crypto
accessible for all users without the need to have udev rules
rewriting the access rights.
Signed-off-by: Harald Freudenberger <fre...@linux.vnet.ibm.com>
---
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_
On 07/04/2017 03:15 PM, PrasannaKumar Muralidharan wrote:
> On 3 July 2017 at 15:33, Harald Freudenberger <fre...@linux.vnet.ibm.com>
> wrote:
>> This patch introduces a new sysfs attribute file 'rng_selected'
>> which shows the the rng chosen by userspace.
>>
>&g
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 <fre...@linux.vnet.ibm.com>
---
drivers/char/hw_random/core.c | 31 +--
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 <fre...@linux.vnet.ibm.com>
---
drivers/char/hw_random/core.c | 31 +--
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(_list)) {
> mutex_unlock(_mutex);
looks like for me.
reviewed-by: Harald Freudenberger <fre...@linux.vnet.ibm.com>
is sorted by quality, use the best (=first) one */
> - if (!list_empty(_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(_list)) {
> mutex_unlock(_mutex);
That's a really good idea. I also thought about something like that.
regards
Harald Freudenberger
rue 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
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
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 like
f 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.
he 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
36 matches
Mail list logo
