Xu Wang wrote:
> Remove unneeded variable t1 seed_encrypt() and
> seed_decrypt().
>
> Signed-off-by: Xu Wang
> ---
> crypto/seed.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/crypto/seed.c b/crypto/seed.c
> index 5e3bef3a617d..69b3058d6a32 100644
> --- a/crypto/s
On Fri, Aug 21, 2020 at 01:43:19PM +, Corentin Labbe wrote:
>
> + err = pm_runtime_get_sync(ss->dev);
> + if (err < 0)
> + goto err_pm;
> + err = 0;
The error case needs to do this:
https://patchwork.kernel.org/patch/11728595/
Cheers,
--
Email: Herbert Xu
Home Page:
On Fri, Aug 21, 2020 at 01:43:20PM +, Corentin Labbe wrote:
>
> + err = pm_runtime_get_sync(op->ss->dev);
> + if (err < 0)
> + goto error_pm;
> + return 0;
You need to handle the error case like this:
https://patchwork.kernel.org/patch/11728595/
Cheers,
--
Email: Her
At Steffen's request, I'll help maintain padata for the foreseeable
future.
While at it, let's have patches go to lkml too since the code is now
used outside of crypto.
Signed-off-by: Daniel Jordan
Cc: Herbert Xu
Cc: Steffen Klassert
Cc: linux-crypto@vger.kernel.org
Cc: linux-ker...@vger.kerne
On Thu, Aug 27, 2020 at 08:44:09AM +0200, Steffen Klassert wrote:
> Please also consider to add yourself as one of the maintainers.
Ok, sure! I'll take you up on that.
On Thu, Aug 27, 2020 at 12:12 PM Arnd Bergmann wrote:
>
> Ah right, that explains why I never saw the warning in my randconfig
> build tests, I run those with COMPILE_TEST force-enabled.
.. but your clang test did enable this?
.. never mind, I have clang locally anyway, and while I usually don't
On Thu, Aug 27, 2020 at 09:11:52PM +0200, Arnd Bergmann wrote:
> On Thu, Aug 27, 2020 at 7:55 PM Linus Torvalds
> wrote:
> >
> > On Thu, Aug 27, 2020 at 10:34 AM Linus Torvalds
> > wrote:
> > >
> > > How are you guys testing? I have UBSAN and GCOV on, and don't see
> > > crazy frames on either i3
On Thu, Aug 27, 2020 at 12:02:12PM -0700, Linus Torvalds wrote:
> On Thu, Aug 27, 2020 at 11:42 AM Kees Cook wrote:
> >
> > Do you mean you checked both gcc and clang and it was only a problem with
> > gcc?
>
> I didn't check with clang, but Arnd claimed it was fine.
>
> > (If so, I can tweak t
On Thu, Aug 27, 2020 at 7:55 PM Linus Torvalds
wrote:
>
> On Thu, Aug 27, 2020 at 10:34 AM Linus Torvalds
> wrote:
> >
> > How are you guys testing? I have UBSAN and GCOV on, and don't see
> > crazy frames on either i386 or x86-64.
>
> Oh, never mind. I also have COMPILE_TEST on, so it ends up di
On Thu, Aug 27, 2020 at 11:42 AM Kees Cook wrote:
>
> Do you mean you checked both gcc and clang and it was only a problem with gcc?
I didn't check with clang, but Arnd claimed it was fine.
> (If so, I can tweak the "depends" below...)
Ugh.
Instead of making the Makefile even uglier, why don't
On Thu, Aug 27, 2020 at 10:55:32AM -0700, Linus Torvalds wrote:
> On Thu, Aug 27, 2020 at 10:34 AM Linus Torvalds
> wrote:
> >
> > How are you guys testing? I have UBSAN and GCOV on, and don't see
> > crazy frames on either i386 or x86-64.
>
> Oh, never mind. I also have COMPILE_TEST on, so it en
V3S contains crypto engine that is compatible with "sun4i-ss".
Tested-by: Martin Cerveny
Signed-off-by: Martin Cerveny
---
.../bindings/crypto/allwinner,sun4i-a10-crypto.yaml| 5 -
arch/arm/boot/dts/sun8i-v3s.dtsi | 10 ++
drivers/crypto/allwinner/sun4i-ss
On Thu, Aug 27, 2020 at 10:34 AM Linus Torvalds
wrote:
>
> How are you guys testing? I have UBSAN and GCOV on, and don't see
> crazy frames on either i386 or x86-64.
Oh, never mind. I also have COMPILE_TEST on, so it ends up disabling
GCOV_PROFILE_ALL and UBSAN_SANITIZE_ALL.
And yeah, this seems
x86_64 zero extends 32bit operations, so for 64bit operands,
XORL r32,r32 is functionally equal to XORQ r64,r64, but avoids
a REX prefix byte when legacy registers are used.
Signed-off-by: Uros Bizjak
Cc: Herbert Xu
Cc: "David S. Miller"
---
arch/x86/crypto/poly1305-x86_64-cryptogams.pl | 8 ++
On Thu, Aug 27, 2020 at 1:25 AM Herbert Xu wrote:
>
> Interestingly this particular file fails with those options on
> gcc 8, 9 and 10.
How are you guys testing? I have UBSAN and GCOV on, and don't see
crazy frames on either i386 or x86-64.
I see 72 bytes and 64 bytes respectively for chacha_per
x86_64 zero extends 32bit operations, so for 64bit operands,
XORL r32,r32 is functionally equal to XORL r64,r64, but avoids
a REX prefix byte when legacy registers are used.
Signed-off-by: Uros Bizjak
Cc: Herbert Xu
Cc: "David S. Miller"
---
arch/x86/crypto/curve25519-x86_64.c | 68 +++
Ok. I will send patch ASAP.
Regards, Martin
On Wed, 26 Aug 2020, Corentin Labbe wrote:
On Wed, Aug 26, 2020 at 01:33:20PM +0200, Martin Cerveny wrote:
Hello.
On Wed, 26 Aug 2020, Corentin Labbe wrote:
On Wed, Aug 26, 2020 at 09:52:30AM +0200, Martin Cerveny wrote:
Hello.
[1.] One line sum
On Thu, Aug 27, 2020 at 1:51 PM Herbert Xu wrote:
>
> On Thu, Aug 27, 2020 at 12:41:53PM +0200, Ard Biesheuvel wrote:
> >
> > That does not help, unfortunately.
> >
> > What does seem to work is
> >
> > struct chacha_state { u32 x[16]; };
> >
> > struct chacha_state chacha_permute(struct chacha_st
Remove redundant memzero_explicit() in sun8i_ss_cipher() before calling
kfree_sensitive(). kfree_sensitive() will zero the memory with
memzero_explicit().
Fixes: 453431a54934 ("mm, treewide: rename kzfree() to kfree_sensitive()")
Signed-off-by: Denis Efremov
---
Changes in v2:
- fixes tag added
On Thu, Aug 27, 2020 at 09:43:59AM +0300, Denis Efremov wrote:
> Use kfree_sensitive() instead of open-coding it.
>
> Signed-off-by: Denis Efremov
> ---
> drivers/crypto/inside-secure/safexcel_hash.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/insid
On Thu, Aug 27, 2020 at 09:44:00AM +0300, Denis Efremov wrote:
> Use kfree_sensitive() instead of open-coding it.
>
> Signed-off-by: Denis Efremov
> ---
> drivers/crypto/amlogic/amlogic-gxl-cipher.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
For the whole serie you di
On Thu, Aug 27, 2020 at 09:44:02AM +0300, Denis Efremov wrote:
> Use kfree_sensitive() instead of open-coding it.
>
> Signed-off-by: Denis Efremov
> ---
> .../crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c | 15 +++
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
Acked-by: Core
On Thu, Aug 27, 2020 at 09:44:01AM +0300, Denis Efremov wrote:
> Use kfree_sensitive() instead of open-coding it.
>
> Signed-off-by: Denis Efremov
> ---
> .../crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c | 15 +++
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
Acked-by: Core
Hi Krzysztof,
> Common pattern of handling deferred probe can be simplified with
> dev_err_probe(). Less code and also it prints the error value.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/char/hw_random/cctrng.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
>
On 8/27/20 11:03 AM, Corentin Labbe wrote:
> Could you add:
> Fixes: 453431a54934 ("mm, treewide: rename kzfree() to kfree_sensitive()")
I doubt this change deserves fixes tag, since this is just a cleanup.
Anyway, I will send v2 with it.
Thanks,
Denis
On Thu, Aug 27, 2020 at 12:41:53PM +0200, Ard Biesheuvel wrote:
>
> That does not help, unfortunately.
>
> What does seem to work is
>
> struct chacha_state { u32 x[16]; };
>
> struct chacha_state chacha_permute(struct chacha_state st, int nrounds)
Passing 64 bytes by value is not good.
Passin
On Thu, 27 Aug 2020 at 11:20, Arnd Bergmann wrote:
>
> On Thu, Aug 27, 2020 at 10:42 AM Ard Biesheuvel wrote:
> >
> > In that case, I suppose we should simply disable instrumentation for
> > chacha_permute()? It is a straight-forward arithmetic transformation
> > on a u32[16] array, where ubsan h
On Thu, Aug 27, 2020 at 10:42 AM Ard Biesheuvel wrote:
>
> In that case, I suppose we should simply disable instrumentation for
> chacha_permute()? It is a straight-forward arithmetic transformation
> on a u32[16] array, where ubsan has limited value afaict.
I guess that always works as a last re
4
> > > > commit: 5fb8ef25803ef33e2eb60b626435828b937bed75 crypto: chacha - move
> > > > existing library code into lib/crypto
> > > > date: 9 months ago
> > > > config: i386-randconfig-r015-20200827 (attached as .config)
> > > > compil
tree:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > head: 15bc20c6af4ceee97a1f90b43c0e386643c071b4
> > > commit: 5fb8ef25803ef33e2eb60b626435828b937bed75 crypto: chacha - move
> > > existing library code into lib/cry
On Thu, Aug 27, 2020 at 10:10:19AM +0200, Ard Biesheuvel wrote:
>
> Is it really worth it to obsess about this? Special compiler
> instrumentation simply leads to a larger stack footprint in many
> cases, which is why we use a larger stack to begin with (at least we
> do so for Kasan, so if we don'
linux.git
> > master
> > head: 15bc20c6af4ceee97a1f90b43c0e386643c071b4
> > commit: 5fb8ef25803ef33e2eb60b626435828b937bed75 crypto: chacha - move
> > existing library code into lib/crypto
> > date: 9 months ago
> > config: i386-randconfig-r015-20200827 (attached as .confi
643c071b4
> commit: 5fb8ef25803ef33e2eb60b626435828b937bed75 crypto: chacha - move
> existing library code into lib/crypto
> date: 9 months ago
> config: i386-randconfig-r015-20200827 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
> reproduce (this is a W=1 build):
> git checkout 5
On Thu, Aug 27, 2020 at 10:40:23AM +0300, Denis Efremov wrote:
> Remove redundant memzero_explicit() in sun8i_ss_cipher() before calling
> kfree_sensitive(). kfree_sensitive() will zero the memory with
> memzero_explicit().
>
> Signed-off-by: Denis Efremov
> ---
> drivers/crypto/allwinner/sun8i-
On Thu, 27 Aug 2020 at 06:56, Caleb Jorden wrote:
>
> I can tell you all assumed this, but just by way as a quick update on the
> original issue:
>
> I have confirmed that Herbert's patch (crypto: af_alg - Work around empty
> control messages without MSG_MORE) does indeed fix the original iwd 1.
Remove redundant memzero_explicit() in sun8i_ss_cipher() before calling
kfree_sensitive(). kfree_sensitive() will zero the memory with
memzero_explicit().
Signed-off-by: Denis Efremov
---
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drive
On Thu, 27 Aug 2020 at 09:15, Herbert Xu wrote:
>
> On Thu, Aug 27, 2020 at 08:40:01AM +0200, Ard Biesheuvel wrote:
> >
> > It is part of iwd - just build that and run 'make check'
> >
> > With your patch applied, the occurrence of sendmsg() in
> > operate_cipher() triggers the warn_once(), but if
On Thu, Aug 27, 2020 at 08:40:01AM +0200, Ard Biesheuvel wrote:
>
> It is part of iwd - just build that and run 'make check'
>
> With your patch applied, the occurrence of sendmsg() in
> operate_cipher() triggers the warn_once(), but if I add MSG_MORE
> there, the test hangs.
I see. This is a di
38 matches
Mail list logo
