Re: [PATCH] crypto: Add ECB dependency for XTS mode

[Greg KH]

On Fri, Mar 03, 2017 at 07:25:21AM +0100, Milan Broz wrote:
> Patch below should be backported to 4.10 stable
> (only 4.10, older kernels are ok).
> We have reports some systems fail to boot from LUKS now
> (missing ecb module in initramdisk) ...
> 
> Upstream commit is 12cb3a1c4184f891d965d1f39f8cfcc9ef617647

Now queued up, thanks.

greg k-h

Re: [RFC PATCH v2 13/32] KVM: SVM: Enable SEV by setting the SEV_ENABLE CPU feature

[Borislav Petkov]

On Thu, Mar 02, 2017 at 10:15:01AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> Modify the SVM cpuid update function to indicate if Secure Encrypted
> Virtualization (SEV) is active in the guest by setting the SEV KVM CPU
> features bit. SEV is active if Secure Memory Encryption is enabled in
> the host and the SEV_ENABLE bit of the VMCB is set.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/kvm/cpuid.c |4 +++-
>  arch/x86/kvm/svm.c   |   18 ++
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 1639de8..e0c40a8 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -601,7 +601,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
> *entry, u32 function,
>   entry->edx = 0;
>   break;
>   case 0x8000:
> - entry->eax = min(entry->eax, 0x801a);
> + entry->eax = min(entry->eax, 0x801f);
>   break;
>   case 0x8001:
>   entry->edx &= kvm_cpuid_8000_0001_edx_x86_features;
> @@ -634,6 +634,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
> *entry, u32 function,
>   break;
>   case 0x801d:
>   break;
> + case 0x801f:
> + break;

I guess those three case's can be unified:

case 0x801a:
case 0x801d:
case 0x801f:
break;

...

> + sev_info = kvm_find_cpuid_entry(vcpu, 0x801f, 0);
> + if (!sev_info)
> + return;
> +
> + if (ca->nested_ctl & SVM_NESTED_CTL_SEV_ENABLE) {
> + features->eax |= (1 << KVM_FEATURE_SEV);
> + cpuid(0x801f, _info->eax, _info->ebx,
> +   _info->ecx, _info->edx);
> + }

Right, as already mentioned in the previous mail: can we communicate SEV
status to the guest solely through the 0x801f leaf? Then we won't
need KVM_FEATURE_SEV and this way we'll be hypervisor-agnostic, as Paolo
suggested.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [RFC PATCH v2 0/3] Cavium ThunderX ZIP driver

[Mahipal Reddy]

On Thu, Mar 9, 2017 at 4:16 PM, Herbert Xu  wrote:
> On Wed, Feb 15, 2017 at 10:45:07AM +0530, Mahipal Challa wrote:
>> Hi Herbert,
>>
>> This series adds support for hardware accelerated compression & decompression
>> as found on ThunderX (arm64) SOCs.
>>
>> As per your suggestion, we've switched to the new crypto acomp/scomp 
>> interface.
>>
>> To test the ZIP driver, we modified the kernel's ZSWAP to use acomp API's.
>>
>> Performance numbers from ZSWAP look promising.
>> The "average time" for compressing a 4KB page:
>>
>> Compression Software: 278 usec
>> Compression HW deflate  :  17 usec
>> Compression HW LZS  :  11 usec
>>
>> Decompression Software  : 20 usec
>> Decompression HW deflate:  8 usec
>> Decompression HW LZS:  6 usec
>>
>> Addressed the review comments from the RFC v1.
>>  - Added acomp/scomp crypto interface support.
>>  - Improved the error handling.
>>  - ZIP command completion codes are renamed suitably.
>>  - Removed some un-used code.
>>  - raw_smp_processor_id() replaced with smp_processor_id().
>>  - Some more miscellaneous changes.
>>
>> Patches are on top of "kernel/git/herbert/crypto-2.6.git" repository
>>
>> Please provide your feedback.
>
> All applied.  Thanks.
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Thank you Herbert.

Regards,
-Mahipal

Re: [PATCH v2 0/2] Propagate fallback bit for cbc and ctr

[Herbert Xu]

On Mon, Feb 27, 2017 at 09:38:24AM -0300, Marcelo Henrique Cerri wrote:
> Hi Hebert,
> 
> For v2:
> 
> - fixed the memory leakage in cbc.
> - included crypto/algapi.h in crypto/cbc.c for crypto_requires_off();
> - ERR_CAST instead PTR_ERR in ctr.
> - Also propagated the fallback bit for rfc3686.
> 
> Marcelo Henrique Cerri (2):
>   crypto: cbc - Propagate NEED_FALLBACK bit
>   crypto: ctr - Propagate NEED_FALLBACK bit
> 
>  crypto/cbc.c | 15 +--
>  crypto/ctr.c | 23 ++-
>  2 files changed, 31 insertions(+), 7 deletions(-)

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: constify test vectors

[Herbert Xu]

On Fri, Feb 24, 2017 at 03:46:57PM -0800, Eric Biggers wrote:
> From: Eric Biggers 
> 
> These two patches mark all the cryptographic test vectors as 'const'.
> This has several potential advantages and moves a large amount of data
> from .data to .rodata when the tests are enabled.  The second patch does
> the real work; the first just prepares for it by updating a function to
> take a const buffer argument.
> 
> Eric Biggers (2):
>   crypto: kpp - constify buffer passed to crypto_kpp_set_secret()
>   crypto: testmgr - constify all test vectors

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC PATCH v2 0/3] Cavium ThunderX ZIP driver

[Herbert Xu]

On Wed, Feb 15, 2017 at 10:45:07AM +0530, Mahipal Challa wrote:
> Hi Herbert,
> 
> This series adds support for hardware accelerated compression & decompression
> as found on ThunderX (arm64) SOCs.
> 
> As per your suggestion, we've switched to the new crypto acomp/scomp 
> interface.
> 
> To test the ZIP driver, we modified the kernel's ZSWAP to use acomp API's.
> 
> Performance numbers from ZSWAP look promising.
> The "average time" for compressing a 4KB page:
> 
> Compression Software: 278 usec
> Compression HW deflate  :  17 usec
> Compression HW LZS  :  11 usec
> 
> Decompression Software  : 20 usec
> Decompression HW deflate:  8 usec
> Decompression HW LZS:  6 usec
> 
> Addressed the review comments from the RFC v1.
>  - Added acomp/scomp crypto interface support.
>  - Improved the error handling.
>  - ZIP command completion codes are renamed suitably.
>  - Removed some un-used code.
>  - raw_smp_processor_id() replaced with smp_processor_id().
>  - Some more miscellaneous changes. 
> 
> Patches are on top of "kernel/git/herbert/crypto-2.6.git" repository
> 
> Please provide your feedback.

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2 2/2] crypto: algapi - annotate expected branch behavior in crypto_inc()

[Herbert Xu]

On Tue, Feb 14, 2017 at 09:51:02PM +, Ard Biesheuvel wrote:
> To prevent unnecessary branching, mark the exit condition of the
> primary loop as likely(), given that a carry in a 32-bit counter
> occurs very rarely.
> 
> On arm64, the resulting code is emitted by GCC as
> 
>  9a8:   cmp w1, #0x3
>  9ac:   add x3, x0, w1, uxtw
>  9b0:   b.ls9e0 
>  9b4:   ldr w2, [x3,#-4]!
>  9b8:   rev w2, w2
>  9bc:   add w2, w2, #0x1
>  9c0:   rev w4, w2
>  9c4:   str w4, [x3]
>  9c8:   cbz w2, 9d0 
>  9cc:   ret
> 
> where the two remaining branch conditions (one for size < 4 and one for
> the carry) are statically predicted as non-taken, resulting in optimal
> execution in the vast majority of cases.
> 
> Also, replace the open coded alignment test with IS_ALIGNED().
> 
> Cc: Jason A. Donenfeld 
> Signed-off-by: Ard Biesheuvel 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: brcm: fix spelling mistake: "genereate" -> "generate"

[Herbert Xu]

On Wed, Feb 22, 2017 at 11:51:38PM +, Colin King wrote:
> From: Colin Ian King 
> 
> trivial fix to spelling mistake in pr_err message
> 
> Signed-off-by: Colin Ian King 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2 1/2] crypto: arm/aes-neonbs - resolve fallback cipher at runtime

[Herbert Xu]

On Tue, Feb 14, 2017 at 09:51:01PM +, Ard Biesheuvel wrote:
> Currently, the bit sliced NEON AES code for ARM has a link time
> dependency on the scalar ARM asm implementation, which it uses as a
> fallback to perform CBC encryption and the encryption of the initial
> XTS tweak.
> 
> The bit sliced NEON code is both fast and time invariant, which makes
> it a reasonable default on hardware that supports it. However, the
> ARM asm code it pulls in is not time invariant, and due to the way it
> is linked in, cannot be overridden by the new generic time invariant
> driver. In fact, it will not be used at all, given that the ARM asm
> code registers itself as a cipher with a priority that exceeds the
> priority of the fixed time cipher.
> 
> So remove the link time dependency, and allocate the fallback cipher
> via the crypto API. Note that this requires this driver's module_init
> call to be replaced with late_initcall, so that the (possibly generic)
> fallback cipher is guaranteed to be available when the builtin test
> is performed at registration time.
> 
> Signed-off-by: Ard Biesheuvel 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/4] crypto: gf128mul cleanups

[Herbert Xu]

On Tue, Feb 14, 2017 at 01:43:26PM -0800, Eric Biggers wrote:
> This patchset makes a few cleanups to the generic GF(2^128) multiplication 
> code
> to make it slightly easier to understand and modify.  No functional changes 
> are
> intended.
> 
> Eric Biggers (4):
>   crypto: gf128mul - fix some comments
>   crypto: gf128mul - remove xx() macro
>   crypto: gf128mul - rename the byte overflow tables
>   crypto: gf128mul - constify 4k and 64k multiplication tables
> 
>  crypto/gf128mul.c | 86 
> +++
>  include/crypto/gf128mul.h | 32 +-
>  2 files changed, 67 insertions(+), 51 deletions(-)

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: s5p-sss - Fix spinlock recursion on LRW(AES)

[Herbert Xu]

On Wed, Mar 08, 2017 at 11:14:20PM +0200, Krzysztof Kozlowski wrote:
> Running TCRYPT with LRW compiled causes spinlock recursion:
> 
> testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption
> tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 
> seconds (304112 bytes)
> tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 
> seconds (1008192 bytes)
> tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 
> seconds (3659008 bytes)
> tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 
> seconds (12191744 bytes)
> tcrypt: test 4 (256 bit key, 8192 byte blocks):
> BUG: spinlock recursion on CPU#1, irq/84-1083/89
>  lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-1083/89, 
> .owner_cpu: 1
> CPU: 1 PID: 89 Comm: irq/84-1083 Not tainted 
> 4.11.0-rc1-1-g897ca6d0800d #559
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x78/0x8c)
> [] (dump_stack) from [] (do_raw_spin_lock+0x11c/0x120)
> [] (do_raw_spin_lock) from [] 
> (_raw_spin_lock_irqsave+0x20/0x28)
> [] (_raw_spin_lock_irqsave) from [] 
> (s5p_aes_crypt+0x2c/0xb4)
> [] (s5p_aes_crypt) from [] (do_encrypt+0x78/0xb0 
> [lrw])
> [] (do_encrypt [lrw]) from [] (encrypt_done+0x24/0x54 
> [lrw])
> [] (encrypt_done [lrw]) from [] 
> (s5p_aes_complete+0x60/0xcc)
> [] (s5p_aes_complete) from [] 
> (s5p_aes_interrupt+0x134/0x1a0)
> [] (s5p_aes_interrupt) from [] 
> (irq_thread_fn+0x1c/0x54)
> [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1e0)
> [] (irq_thread) from [] (kthread+0x108/0x138)
> [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> 
> Interrupt handling routine was calling req->base.complete() under
> spinlock.  In most cases this wasn't fatal but when combined with some
> of the cipher modes (like LRW) this caused recursion - starting the new
> encryption (s5p_aes_crypt()) while still holding the spinlock from
> previous round (s5p_aes_complete()).
> 
> Beside that, the s5p_aes_interrupt() error handling path could execute
> two completions in case of error for RX and TX blocks.
> 
> Rewrite the interrupt handling routine and the completion by:
> 
> 1. Splitting the operations on scatterlist copies from
>s5p_aes_complete() into separate s5p_sg_done(). This still should be
>done under lock.
>The s5p_aes_complete() now only calls req->base.complete() and it has
>to be called outside of lock.
> 
> 2. Moving the s5p_aes_complete() out of spinlock critical sections.
>In interrupt service routine s5p_aes_interrupts(), it appeared in few
>places, including error paths inside other functions called from ISR.
>This code was not so obvious to read so simplify it by putting the
>s5p_aes_complete() only within ISR level.
> 
> Reported-by: Nathan Royce 
> Cc:  # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix 
> completing
> Cc:  # v4.10.x
> Signed-off-by: Krzysztof Kozlowski 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

[Borislav Petkov]

On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote:
> This is not how you check if running under a hypervisor; you should
> check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx.  This in turn
> tells you if leaf 0x4000 is valid.

Ah, good point, I already do that in the microcode loader :)

/*
 * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
 * completely accurate as xen pv guests don't see that CPUID bit set but
 * that's good enough as they don't land on the BSP path anyway.
 */
if (native_cpuid_ecx(1) & BIT(31))
return *res;

> That said, the main issue with this function is that it hardcodes the
> behavior for KVM.  It is possible that another hypervisor defines its
> 0x4001 leaf in such a way that KVM_FEATURE_SEV has a different meaning.
> 
> Instead, AMD should define a "well-known" bit in its own space (i.e.
> 0x80xx) that is only used by hypervisors that support SEV.  This is
> similar to how Intel defined one bit in leaf 1 to say "is leaf
> 0x4000 valid".
> 
> > +   if (eax > 0x4000) {
> > +   eax = 0x4001;
> > +   ecx = 0;
> > +   native_cpuid(, , , );
> > +   if (!(eax & BIT(KVM_FEATURE_SEV)))
> > +   goto out;
> > +
> > +   eax = 0x801f;
> > +   ecx = 0;
> > +   native_cpuid(, , , );
> > +   if (!(eax & 1))

Right, so this is testing CPUID_0x801f_ECX(0)[0], SME. Why not
simply set that bit for the guest too, in kvm?

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

[Paolo Bonzini]

On 09/03/2017 15:07, Borislav Petkov wrote:
> + /* Check if running under a hypervisor */
> + eax = 0x4000;
> + ecx = 0;
> + native_cpuid(, , , );

This is not how you check if running under a hypervisor; you should
check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx.  This in turn
tells you if leaf 0x4000 is valid.

That said, the main issue with this function is that it hardcodes the
behavior for KVM.  It is possible that another hypervisor defines its
0x4001 leaf in such a way that KVM_FEATURE_SEV has a different meaning.

Instead, AMD should define a "well-known" bit in its own space (i.e.
0x80xx) that is only used by hypervisors that support SEV.  This is
similar to how Intel defined one bit in leaf 1 to say "is leaf
0x4000 valid".

Thanks,

Paolo

> + if (eax > 0x4000) {
> + eax = 0x4001;
> + ecx = 0;
> + native_cpuid(, , , );
> + if (!(eax & BIT(KVM_FEATURE_SEV)))
> + goto out;
> +
> + eax = 0x801f;
> + ecx = 0;
> + native_cpuid(, , , );
> + if (!(eax & 1))
> + goto out;
> +
> + sme_me_mask = 1UL << (ebx & 0x3f);
> + sev_enabled = 1;
> +
> + goto out;
> + }
> +

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

[Borislav Petkov]

On Thu, Mar 02, 2017 at 10:14:48AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> Early in the boot process, add checks to determine if the kernel is
> running with Secure Encrypted Virtualization (SEV) active by issuing
> a CPUID instruction.
> 
> During early compressed kernel booting, if SEV is active the pagetables are
> updated so that data is accessed and decompressed with encryption.
> 
> During uncompressed kernel booting, if SEV is the memory encryption mask is
> set and a flag is set to indicate that SEV is enabled.

I don't know how many times I have to say this but I'm going to keep
doing it until it sticks: :-)

Please, no "WHAT" in the commit messages - I can see the "WHAT - but
"WHY".

Ok?

> diff --git a/arch/x86/boot/compressed/mem_encrypt.S 
> b/arch/x86/boot/compressed/mem_encrypt.S
> new file mode 100644
> index 000..8313c31
> --- /dev/null
> +++ b/arch/x86/boot/compressed/mem_encrypt.S
> @@ -0,0 +1,75 @@
> +/*
> + * AMD Memory Encryption Support
> + *
> + * Copyright (C) 2016 Advanced Micro Devices, Inc.
> + *
> + * Author: Tom Lendacky 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> + .text
> + .code32
> +ENTRY(sev_enabled)
> + xor %eax, %eax
> +
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
> + push%ebx
> + push%ecx
> + push%edx
> +
> + /* Check if running under a hypervisor */
> + movl$0x4000, %eax
> + cpuid
> + cmpl$0x4001, %eax
> + jb  .Lno_sev
> +
> + movl$0x4001, %eax
> + cpuid
> + bt  $KVM_FEATURE_SEV, %eax
> + jnc .Lno_sev
> +
> + /*
> +  * Check for memory encryption feature:
> +  *   CPUID Fn8000_001F[EAX] - Bit 0
> +  */
> + movl$0x801f, %eax
> + cpuid
> + bt  $0, %eax
> + jnc .Lno_sev
> +
> + /*
> +  * Get memory encryption information:
> +  *   CPUID Fn8000_001F[EBX] - Bits 5:0
> +  * Pagetable bit position used to indicate encryption
> +  */
> + movl%ebx, %eax
> + andl$0x3f, %eax
> + movl%eax, sev_enc_bit(%ebp)
> + jmp .Lsev_exit
> +
> +.Lno_sev:
> + xor %eax, %eax
> +
> +.Lsev_exit:
> + pop %edx
> + pop %ecx
> + pop %ebx
> +
> +#endif   /* CONFIG_AMD_MEM_ENCRYPT */
> +
> + ret
> +ENDPROC(sev_enabled)

Right, as said in another mail earlier, this could be written in C. And
then the sme_enable() piece below looks the same as this one above. So
since you want to run it before kernel decompression and after, you
could extract this code into a separate .c file which you can link in
both places, similar to what we do with verify_cpu with the difference
that verify_cpu is getting included.

Alternatively, we still have some room in setup_header.xloadflags to
pass boot info to kernel proper from before the decompression stage.

But I'd prefer linking with both stages as it is cheaper and those flags
we can use for something which really wants to use a flag like that.

> diff --git a/arch/x86/kernel/mem_encrypt_init.c 
> b/arch/x86/kernel/mem_encrypt_init.c
> index 35c5e3d..5d514e6 100644
> --- a/arch/x86/kernel/mem_encrypt_init.c
> +++ b/arch/x86/kernel/mem_encrypt_init.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static char sme_cmdline_arg_on[] __initdata = "mem_encrypt=on";
>  static char sme_cmdline_arg_off[] __initdata = "mem_encrypt=off";
> @@ -232,6 +233,29 @@ unsigned long __init sme_enable(void *boot_data)
>   void *cmdline_arg;
>   u64 msr;
>  
> + /* Check if running under a hypervisor */
> + eax = 0x4000;
> + ecx = 0;
> + native_cpuid(, , , );
> + if (eax > 0x4000) {
> + eax = 0x4001;
> + ecx = 0;
> + native_cpuid(, , , );
> + if (!(eax & BIT(KVM_FEATURE_SEV)))
> + goto out;
> +
> + eax = 0x801f;
> + ecx = 0;
> + native_cpuid(, , , );
> + if (!(eax & 1))
> + goto out;
> +
> + sme_me_mask = 1UL << (ebx & 0x3f);
> + sev_enabled = 1;
> +
> + goto out;
> + }
> +
>   /* Check for an AMD processor */
>   eax = 0;
>   ecx = 0;
> 

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

[Nathan Royce]

Gave it a try on 4.10.1, but still to no avail:
*
[8.516138] raid6: using intx1 recovery algorithm
[ [0;32m  OK   [0m] Started Flush Journal to Persistent Storage.
[9.692091] Unable to handle kernel NULL pointer dereference at
virtual address 0004
[9.698896] pgd = c0004000
[9.701489] [0004] *pgd=
[9.705055] Internal error: Oops: 17 [#1] SMP ARM
[9.709677] Modules linked in: xor_neon zlib_deflate aes_arm
raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
ip_tables x_tables
[9.719177] xor: measuring software checksum speed
[9.727455] CPU: 2 PID: 121 Comm: irq/69-1083 Not tainted 4.10.1-dirty #1
[9.728911]arm4regs  :   304.000 MB/sec
[9.738707] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[9.738913]8regs :   224.000 MB/sec
[9.748924]32regs:   208.000 MB/sec
[9.753095] task: edc80b00 task.stack: edd08000
[9.757626] PC is at post_crypt+0x1b4/0x1c4
[9.758914]neon  :   316.000 MB/sec
[9.758927] xor: using function: neon (316.000 MB/sec)
[9.771040] LR is at post_crypt+0x1a8/0x1c4
[9.775197] pc : []lr : []psr: 200c0013
[9.775197] sp : edd09e90  ip : edcd64f4  fp : 02cfca75
[9.786670] r10: 3df4074e  r9 : c0c0540c  r8 : edcd6400
[9.791831] r7 :   r6 : 0400  r5 :   r4 : 
[9.798333] r3 : ef4a775a  r2 : 0200  r1 : 0200  r0 : 
[9.804834] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[9.811901] Control: 10c5387d  Table: 6c61c06a  DAC: 0051
[9.817618] Process irq/69-1083 (pid: 121, stack limit = 0xedd08218)
[9.824291] Stack: (0xedd09e90 to 0xedd0a000)
[9.828624] 9e80: ef4a7758
ecca6200 ef4a7758 ecca6200
[9.836781] 9ea0: edcd65dc 0400   0400
 eea8f810 0002
[9.844926] 9ec0:     
 0010 0010
[9.853072] 9ee0: 000f 00040a01 ee958390 edcd6400 ee9583bc
000c ee9583e8 
[9.861217] 9f00:  600c0013 ee889d20 c033608c ee958390
c05a7ea8  0001
[9.869363] 9f20: ee957b40 eea8a400 eea8a400 ee957b40 c016ee68
c0c0540c  c016ee84
[9.877508] 9f40: edd08000 ee957b64 eea8a400 c016f198 ee957b80
 c016ef7c 00040a01
[9.885653] 9f60:  eea21380 edd08000  ee957b80
ee957b40 c016f04c eea213a8
[9.893800] 9f80: ee889d20 c0138710 edd08000 ee957b80 c0138608
  
[9.901944] 9fa0:    c0107a38 
  
[9.910089] 9fc0:     
  
[9.918235] 9fe0:     0013
  
[9.926399] [] (post_crypt) from []
(decrypt_done+0x4c/0x54)
[9.933761] [] (decrypt_done) from []
(s5p_aes_interrupt+0x1bc/0x208)
[9.941908] [] (s5p_aes_interrupt) from []
(irq_thread_fn+0x1c/0x54)
[9.949956] [] (irq_thread_fn) from []
(irq_thread+0x14c/0x204)
[9.957585] [] (irq_thread) from [] (kthread+0x108/0x138)
[9.964681] [] (kthread) from []
(ret_from_fork+0x14/0x3c)
[9.971871] Code: eb0114aa e598c118 e58d001c e1a04000 (e5906004)
[9.977963] ---[ end trace 8c160bf6676cfe1c ]---
[9.982560] genirq: exiting task "irq/69-1083" (121) is an
active IRQ thread (irq 69)
[   11.715339] Btrfs loaded, crc32c=crc32c-generic
*

Also for the sake of testing, I did not add any FLAGS for compilation this time.

On Wed, Mar 8, 2017 at 3:15 PM, Krzysztof Kozlowski  wrote:
> On Wed, Mar 08, 2017 at 07:45:42PM +0200, Krzysztof Kozlowski wrote:
> I sent a fix. At least for spin lock recursion in tcrypt.
>
> Could you give it a try?
>
> Best regards,
> Krzysztof

Re: [PATCH V2 2/3] crypto: ccp - Enable support for AES GCM on v5 CCPs

[Herbert Xu]

On Thu, Mar 02, 2017 at 03:26:54PM -0600, Gary R Hook wrote:
> A version 5 device provides the primitive commands
> required for AES GCM. This patch adds support for
> en/decryption.
> 
> Signed-off-by: Gary R Hook 

This patch doesn't apply to the current cryptodev tree.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC] how to handle AAD copy operation for algif_aead

[Stephan Müller]

Am Donnerstag, 9. März 2017, 11:23:16 CET schrieb Herbert Xu:

Hi Herbert,

> I see.  Yes that looks good.

Thank you. I will provide an official patch after the discussion about the 
memory handling is completed.

As the memory handling patch should be considered for stable whereas the AAD 
copy patch should not, I would therefore recommend completing the memory 
handling discussion first.

Ciao
Stephan

Re: [RFC] how to handle AAD copy operation for algif_aead

[Herbert Xu]

On Thu, Mar 09, 2017 at 11:08:32AM +0100, Stephan Müller wrote:
>
> This is the first patch (0001-crypto-algif_aead-copy-AAD-from-src-to-
> dst_separate.patch).
> 
> The second alternative patch (0001-crypto-algif_aead-copy-AAD-from-src-to-
> dst_inplace.patch) does:

I see.  Yes that looks good.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC] how to handle AAD copy operation for algif_aead

[Stephan Müller]

Am Donnerstag, 9. März 2017, 11:05:54 CET schrieb Herbert Xu:

Hi Herbert,

> On Thu, Mar 09, 2017 at 11:02:41AM +0100, Stephan Müller wrote:
> > > > The patch
> > > > 0001-crypto-algif_aead-copy-AAD-from-src-to-dst_separate.patch
> > > > simply copies the AAD over from TX SGL to RX SGL. The pro is that the
> > > > patch is small. The con is that this approach does *not* provide an
> > > > in-place crypto operation.
> > > 
> > > I prefer this patch with the proviso that it copy the whole thing
> > > instead of just the AD.  That way you can just feed the dst memory
> > > to crypto_aead for in-place operation.  Of course you have to mangle
> > > the tag data onto the dst SG list for decryption but it shouldn't
> > > be too hard.
> > 
> > I thought that is exactly the second patch. It copies the entire data to
> > the dst SGL and extends the SGL with the tag in case of decryption.
> 
> Are you sure? The patch says:
> 
> +   /* copy AAD from src to dst */
> +   err = crypto_aead_copy_sgl(ctx->null, areq->tsgl,
> +  areq->first_rsgl.sgl.sg,
> ctx->aead_assoclen);
> 
> Which seems to only copy the AD.

This is the first patch (0001-crypto-algif_aead-copy-AAD-from-src-to-
dst_separate.patch).

The second alternative patch (0001-crypto-algif_aead-copy-AAD-from-src-to-
dst_inplace.patch) does:

+   if (ctx->enc) {
+   /* Copy AAD || PT to RX SGL buffer for in-place operation. */
+   err = crypto_aead_copy_sgl(ctx->null, tsgl->sg,
+  areq->first_rsgl.sgl.sg, processed);
+   if (err)
+   goto free;
+   aead_pull_tsgl(sk, processed, NULL, 0);
+   } else {
+   /* Copy AAD || CT to RX SGL buffer for in-place operation. */
+   err = crypto_aead_copy_sgl(ctx->null, tsgl->sg,
+  areq->first_rsgl.sgl.sg, outlen);
+   if (err)
+   goto free;
+
+   /* Create TX SGL for tag and chain it to RX SGL. */
+   areq->tsgl_entries = aead_count_tsgl(sk, processed);
+   if (!areq->tsgl_entries)
+   areq->tsgl_entries = 1;
+   areq->tsgl = sock_kmalloc(sk, sizeof(*areq->tsgl) *
+ areq->tsgl_entries,
+ GFP_KERNEL);
+   if (!areq->tsgl) {
+   err = -ENOMEM;
+   goto free;
+   }
+   sg_init_table(areq->tsgl, areq->tsgl_entries);
+
+   /* Release TX SGL, except for tag data. */
+   aead_pull_tsgl(sk, processed, areq->tsgl, processed - as);
+
+   /* chain the areq TX SGL holding the tag with RX SGL */
+   if (!last_rsgl) {
+   /* no RX SGL present (e.g. only authentication) */
+   sg_init_table(areq->first_rsgl.sgl.sg, 2);
+   sg_chain(areq->first_rsgl.sgl.sg, 2, areq->tsgl);
+   } else {
+   /* RX SGL present */
+   struct af_alg_sgl *sgl_prev = _rsgl->sgl;
+
+   sg_unmark_end(sgl_prev->sg + sgl_prev->npages - 1);
+   sg_chain(sgl_prev->sg, sgl_prev->npages + 1, 
areq->tsgl);
+   }
}

Ciao
Stephan

Re: [RFC] how to handle AAD copy operation for algif_aead

[Herbert Xu]

On Thu, Mar 09, 2017 at 11:02:41AM +0100, Stephan Müller wrote:
>
> > > The patch 0001-crypto-algif_aead-copy-AAD-from-src-to-dst_separate.patch
> > > simply copies the AAD over from TX SGL to RX SGL. The pro is that the
> > > patch is small. The con is that this approach does *not* provide an
> > > in-place crypto operation.
> > 
> > I prefer this patch with the proviso that it copy the whole thing
> > instead of just the AD.  That way you can just feed the dst memory
> > to crypto_aead for in-place operation.  Of course you have to mangle
> > the tag data onto the dst SG list for decryption but it shouldn't
> > be too hard.
> 
> I thought that is exactly the second patch. It copies the entire data to the 
> dst SGL and extends the SGL with the tag in case of decryption.

Are you sure? The patch says:

+   /* copy AAD from src to dst */
+   err = crypto_aead_copy_sgl(ctx->null, areq->tsgl,
+  areq->first_rsgl.sgl.sg, ctx->aead_assoclen);

Which seems to only copy the AD.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC] how to handle AAD copy operation for algif_aead

[Stephan Müller]

Am Donnerstag, 9. März 2017, 11:00:11 CET schrieb Herbert Xu:

Hi Herbert,

> On Fri, Feb 24, 2017 at 02:24:47PM +0100, Stephan Müller wrote:
> > Hi Herbert et al,
> > 
> > attached are two patches where each patch has a different approach to copy
> > the AAD in the algif_aead operation. I would like to hear your opinion
> > which approach should be taken.
> > 
> > The patch 0001-crypto-algif_aead-copy-AAD-from-src-to-dst_separate.patch
> > simply copies the AAD over from TX SGL to RX SGL. The pro is that the
> > patch is small. The con is that this approach does *not* provide an
> > in-place crypto operation.
> 
> I prefer this patch with the proviso that it copy the whole thing
> instead of just the AD.  That way you can just feed the dst memory
> to crypto_aead for in-place operation.  Of course you have to mangle
> the tag data onto the dst SG list for decryption but it shouldn't
> be too hard.

I thought that is exactly the second patch. It copies the entire data to the 
dst SGL and extends the SGL with the tag in case of decryption.

Ciao
Stephan

Re: [RFC] how to handle AAD copy operation for algif_aead

[Herbert Xu]

On Fri, Feb 24, 2017 at 02:24:47PM +0100, Stephan Müller wrote:
> Hi Herbert et al,
> 
> attached are two patches where each patch has a different approach to copy 
> the 
> AAD in the algif_aead operation. I would like to hear your opinion which 
> approach should be taken.
> 
> The patch 0001-crypto-algif_aead-copy-AAD-from-src-to-dst_separate.patch 
> simply copies the AAD over from TX SGL to RX SGL. The pro is that the patch 
> is 
> small. The con is that this approach does *not* provide an in-place crypto 
> operation.

I prefer this patch with the proviso that it copy the whole thing
instead of just the AD.  That way you can just feed the dst memory
to crypto_aead for in-place operation.  Of course you have to mangle
the tag data onto the dst SG list for decryption but it shouldn't
be too hard.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] crypto: doc - fix typo (struct sdesc)

[Fabien Dessenne]

Add missing " " in api-samples.rst

Signed-off-by: Fabien Dessenne 
---
 Documentation/crypto/api-samples.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/crypto/api-samples.rst 
b/Documentation/crypto/api-samples.rst
index 0a10819..d021fd9 100644
--- a/Documentation/crypto/api-samples.rst
+++ b/Documentation/crypto/api-samples.rst
@@ -155,9 +155,9 @@ Code Example For Use of Operational State Memory With SHASH
 char ctx[];
 };
 
-static struct sdescinit_sdesc(struct crypto_shash *alg)
+static struct sdesc init_sdesc(struct crypto_shash *alg)
 {
-struct sdescsdesc;
+struct sdesc sdesc;
 int size;
 
 size = sizeof(struct shash_desc) + crypto_shash_descsize(alg);
@@ -172,7 +172,7 @@ Code Example For Use of Operational State Memory With SHASH
 static int calc_hash(struct crypto_shashalg,
  const unsigned chardata, unsigned int datalen,
  unsigned chardigest) {
-struct sdescsdesc;
+struct sdesc sdesc;
 int ret;
 
 sdesc = init_sdesc(alg);
-- 
2.7.4