* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
From: Nathan Royce @ 2017-03-09 11:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
In-Reply-To: <20170308211543.euqexxlhdgpfcdjk@kozik-lap>
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 00000004
[ 9.698896] pgd = c0004000
[ 9.701489] [00000004] *pgd=00000000
[ 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-10830000 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 : [<c0335c68>] lr : [<c0335c5c>] psr: 200c0013
[ 9.775197] sp : edd09e90 ip : edcd64f4 fp : 02cfca75
[ 9.786670] r10: 3df4074e r9 : c0c0540c r8 : edcd6400
[ 9.791831] r7 : 00000000 r6 : 00000400 r5 : 00000000 r4 : 00000000
[ 9.798333] r3 : ef4a775a r2 : 00000200 r1 : 00000200 r0 : 00000000
[ 9.804834] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 9.811901] Control: 10c5387d Table: 6c61c06a DAC: 00000051
[ 9.817618] Process irq/69-10830000 (pid: 121, stack limit = 0xedd08218)
[ 9.824291] Stack: (0xedd09e90 to 0xedd0a000)
[ 9.828624] 9e80: ef4a7758
ecca6200 ef4a7758 ecca6200
[ 9.836781] 9ea0: edcd65dc 00000400 00000000 00000000 00000400
00000000 eea8f810 00000002
[ 9.844926] 9ec0: 00000000 00000000 00000000 00000000 00000000
00000000 00000010 00000010
[ 9.853072] 9ee0: 0000000f 00040a01 ee958390 edcd6400 ee9583bc
0000000c ee9583e8 00000000
[ 9.861217] 9f00: 00000000 600c0013 ee889d20 c033608c ee958390
c05a7ea8 00000000 00000001
[ 9.869363] 9f20: ee957b40 eea8a400 eea8a400 ee957b40 c016ee68
c0c0540c 00000000 c016ee84
[ 9.877508] 9f40: edd08000 ee957b64 eea8a400 c016f198 ee957b80
00000000 c016ef7c 00040a01
[ 9.885653] 9f60: 00000000 eea21380 edd08000 00000000 ee957b80
ee957b40 c016f04c eea213a8
[ 9.893800] 9f80: ee889d20 c0138710 edd08000 ee957b80 c0138608
00000000 00000000 00000000
[ 9.901944] 9fa0: 00000000 00000000 00000000 c0107a38 00000000
00000000 00000000 00000000
[ 9.910089] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 9.918235] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 9.926399] [<c0335c68>] (post_crypt) from [<c033608c>]
(decrypt_done+0x4c/0x54)
[ 9.933761] [<c033608c>] (decrypt_done) from [<c05a7ea8>]
(s5p_aes_interrupt+0x1bc/0x208)
[ 9.941908] [<c05a7ea8>] (s5p_aes_interrupt) from [<c016ee84>]
(irq_thread_fn+0x1c/0x54)
[ 9.949956] [<c016ee84>] (irq_thread_fn) from [<c016f198>]
(irq_thread+0x14c/0x204)
[ 9.957585] [<c016f198>] (irq_thread) from [<c0138710>] (kthread+0x108/0x138)
[ 9.964681] [<c0138710>] (kthread) from [<c0107a38>]
(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-10830000" (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 <krzk@kernel.org> 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
^ permalink raw reply
* Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active
From: Borislav Petkov @ 2017-03-09 14:07 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas
In-Reply-To: <148846768878.2349.15757532025749214650.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:14:48AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> 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 0000000..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 <thomas.lendacky@amd.com>
> + *
> + * 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 <linux/linkage.h>
> +
> +#include <asm/processor-flags.h>
> +#include <asm/msr.h>
> +#include <asm/asm-offsets.h>
> +#include <uapi/asm/kvm_para.h>
> +
> + .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 $0x40000000, %eax
> + cpuid
> + cmpl $0x40000001, %eax
> + jb .Lno_sev
> +
> + movl $0x40000001, %eax
> + cpuid
> + bt $KVM_FEATURE_SEV, %eax
> + jnc .Lno_sev
> +
> + /*
> + * Check for memory encryption feature:
> + * CPUID Fn8000_001F[EAX] - Bit 0
> + */
> + movl $0x8000001f, %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 <asm/processor-flags.h>
> #include <asm/msr.h>
> #include <asm/cmdline.h>
> +#include <asm/kvm_para.h>
>
> 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 = 0x40000000;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
> + if (eax > 0x40000000) {
> + eax = 0x40000001;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
> + if (!(eax & BIT(KVM_FEATURE_SEV)))
> + goto out;
> +
> + eax = 0x8000001f;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
> + 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)
--
^ permalink raw reply
* Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active
From: Paolo Bonzini @ 2017-03-09 16:13 UTC (permalink / raw)
To: Borislav Petkov, Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas
In-Reply-To: <20170309140748.tg67yo2jmc5ahck3@pd.tnic>
On 09/03/2017 15:07, Borislav Petkov wrote:
> + /* Check if running under a hypervisor */
> + eax = 0x40000000;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
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 0x40000000 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
0x40000001 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.
0x800000xx) 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
0x40000000 valid".
Thanks,
Paolo
> + if (eax > 0x40000000) {
> + eax = 0x40000001;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
> + if (!(eax & BIT(KVM_FEATURE_SEV)))
> + goto out;
> +
> + eax = 0x8000001f;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
> + if (!(eax & 1))
> + goto out;
> +
> + sme_me_mask = 1UL << (ebx & 0x3f);
> + sev_enabled = 1;
> +
> + goto out;
> + }
> +
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active
From: Borislav Petkov @ 2017-03-09 16:29 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Brijesh Singh, simon.guinot, linux-efi, kvm, rkrcmar, matt,
linux-pci, linus.walleij, gary.hook, linux-mm, paul.gortmaker,
hpa, cl, dan.j.williams, aarcange, sfr, andriy.shevchenko,
herbert, bhe, xemul, joro, x86, peterz, piotr.luc, mingo, msalter,
ross.zwisler, dyoung, thomas.lendacky, jroedel, keescook, arnd,
toshi.kani, mathieu.desnoyers, luto, devel, bhelgaas, tglx,
mchehab
In-Reply-To: <5d62b16f-16ef-1bd7-1551-f0c4c43573f4@redhat.com>
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 0x40000000 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
> 0x40000001 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.
> 0x800000xx) 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
> 0x40000000 valid".
>
> > + if (eax > 0x40000000) {
> > + eax = 0x40000001;
> > + ecx = 0;
> > + native_cpuid(&eax, &ebx, &ecx, &edx);
> > + if (!(eax & BIT(KVM_FEATURE_SEV)))
> > + goto out;
> > +
> > + eax = 0x8000001f;
> > + ecx = 0;
> > + native_cpuid(&eax, &ebx, &ecx, &edx);
> > + if (!(eax & 1))
Right, so this is testing CPUID_0x8000001f_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)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 0/2] crypto: constify test vectors
From: Herbert Xu @ 2017-03-09 10:47 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-crypto, David S . Miller, linux-kernel, Eric Biggers
In-Reply-To: <20170224234659.89423-1-ebiggers3@gmail.com>
On Fri, Feb 24, 2017 at 03:46:57PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> 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 <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 2/2] crypto: algapi - annotate expected branch behavior in crypto_inc()
From: Herbert Xu @ 2017-03-09 10:46 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, Jason A . Donenfeld
In-Reply-To: <1487109062-3419-2-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Feb 14, 2017 at 09:51:02PM +0000, 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.ls 9e0 <crypto_inc+0x38>
> 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 <crypto_inc+0x28>
> 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 <Jason@zx2c4.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 1/2] crypto: arm/aes-neonbs - resolve fallback cipher at runtime
From: Herbert Xu @ 2017-03-09 10:46 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1487109062-3419-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Feb 14, 2017 at 09:51:01PM +0000, 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 <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/4] crypto: gf128mul cleanups
From: Herbert Xu @ 2017-03-09 10:46 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-crypto, David S . Miller
In-Reply-To: <20170214214330.99845-1-ebiggers@google.com>
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 <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC PATCH v2 0/3] Cavium ThunderX ZIP driver
From: Mahipal Reddy @ 2017-03-09 18:25 UTC (permalink / raw)
To: Herbert Xu
Cc: davem, linux-crypto, linux-kernel, Jan.Glauber, Vishnu Nair,
pathreya, Mahipal Challa
In-Reply-To: <20170309104654.GD7185@gondor.apana.org.au>
On Thu, Mar 9, 2017 at 4:16 PM, Herbert Xu <herbert@gondor.apana.org.au> 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 <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Thank you Herbert.
Regards,
-Mahipal
^ permalink raw reply
* Re: [RFC PATCH v2 13/32] KVM: SVM: Enable SEV by setting the SEV_ENABLE CPU feature
From: Borislav Petkov @ 2017-03-09 19:29 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas
In-Reply-To: <148846770159.2349.16863375000963463500.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:15:01AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> 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 <thomas.lendacky@amd.com>
> ---
> 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 0x80000000:
> - entry->eax = min(entry->eax, 0x8000001a);
> + entry->eax = min(entry->eax, 0x8000001f);
> break;
> case 0x80000001:
> 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 0x8000001d:
> break;
> + case 0x8000001f:
> + break;
I guess those three case's can be unified:
case 0x8000001a:
case 0x8000001d:
case 0x8000001f:
break;
...
> + sev_info = kvm_find_cpuid_entry(vcpu, 0x8000001f, 0);
> + if (!sev_info)
> + return;
> +
> + if (ca->nested_ctl & SVM_NESTED_CTL_SEV_ENABLE) {
> + features->eax |= (1 << KVM_FEATURE_SEV);
> + cpuid(0x8000001f, &sev_info->eax, &sev_info->ebx,
> + &sev_info->ecx, &sev_info->edx);
> + }
Right, as already mentioned in the previous mail: can we communicate SEV
status to the guest solely through the 0x8000001f 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)
--
^ permalink raw reply
* Re: [PATCH] crypto: Add ECB dependency for XTS mode
From: Greg KH @ 2017-03-10 7:36 UTC (permalink / raw)
To: Milan Broz; +Cc: stable, linux-crypto, herbert
In-Reply-To: <02f80ce3-4c85-78ea-7b15-4467a2ae5be4@gmail.com>
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
^ permalink raw reply
* [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)
From: Stephan Müller @ 2017-03-10 8:21 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-crypto
Hi,
The patch set that can be downloaded at [1] provides a different approach to /
dev/random which I call Linux Random Number Generator (LRNG) to collect
entropy within the Linux kernel. The main improvements compared to the legacy
/dev/random is to provide sufficient entropy during boot time as well as in
virtual environments and when using SSDs or Device Mapper targets. A secondary
design goal is to limit the impact of the entropy collection on massive
parallel systems and also allow the use accelerated cryptographic primitives.
Also, all steps of the entropic data processing are testable. Finally
performance improvements are visible at /dev/urandom and get_random_bytes.
The design and implementation is driven by a set of goals described in [2]
that the LRNG completely implements. Furthermore, [2] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
AIS20/31.
The LRNG has a flexible design by allowing an easy replacement of the
deterministic random number generator component. Currently implemented DRNGs
are an SP800-90A DRBG and a ChaCha20 DRNG.
[1] http://www.chronox.de/lrng.html
[2] http://www.chronox.de/lrng/doc/lrng.pdf
Ciao
Stephan
^ permalink raw reply
* Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages
From: Borislav Petkov @ 2017-03-10 11:06 UTC (permalink / raw)
To: Brijesh Singh, Paolo Bonzini
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas, tglx, mchehab,
iamjoonsoo.kim, labbott
In-Reply-To: <148846771545.2349.9373586041426414252.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote:
> If kernel_maps_pages_in_pgd is called early in boot process to change the
kernel_map_pages_in_pgd()
> memory attributes then it fails to allocate memory when spliting large
> pages. The patch extends the cpa_data to provide the support to use
> memblock_alloc when slab allocator is not available.
>
> The feature will be used in Secure Encrypted Virtualization (SEV) mode,
> where we may need to change the memory region attributes in early boot
> process.
>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> arch/x86/mm/pageattr.c | 51 ++++++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 42 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 46cc89d..9e4ab3b 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -14,6 +14,7 @@
> #include <linux/gfp.h>
> #include <linux/pci.h>
> #include <linux/vmalloc.h>
> +#include <linux/memblock.h>
>
> #include <asm/e820/api.h>
> #include <asm/processor.h>
> @@ -37,6 +38,7 @@ struct cpa_data {
> int flags;
> unsigned long pfn;
> unsigned force_split : 1;
> + unsigned force_memblock :1;
> int curpage;
> struct page **pages;
> };
> @@ -627,9 +629,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
>
> static int
> __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
> - struct page *base)
> + pte_t *pbase, unsigned long new_pfn)
> {
> - pte_t *pbase = (pte_t *)page_address(base);
> unsigned long ref_pfn, pfn, pfninc = 1;
> unsigned int i, level;
> pte_t *tmp;
> @@ -646,7 +647,7 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
> return 1;
> }
>
> - paravirt_alloc_pte(&init_mm, page_to_pfn(base));
> + paravirt_alloc_pte(&init_mm, new_pfn);
>
> switch (level) {
> case PG_LEVEL_2M:
> @@ -707,7 +708,8 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
> * pagetable protections, the actual ptes set above control the
> * primary protection behavior:
> */
> - __set_pmd_pte(kpte, address, mk_pte(base, __pgprot(_KERNPG_TABLE)));
> + __set_pmd_pte(kpte, address,
> + native_make_pte((new_pfn << PAGE_SHIFT) + _KERNPG_TABLE));
>
> /*
> * Intel Atom errata AAH41 workaround.
> @@ -723,21 +725,50 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
> return 0;
> }
>
> +static pte_t *try_alloc_pte(struct cpa_data *cpa, unsigned long *pfn)
> +{
> + unsigned long phys;
> + struct page *base;
> +
> + if (cpa->force_memblock) {
> + phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
Maybe there's a reason this fires:
WARNING: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
WARNING: vmlinux.o(.text+0x48edc): Section mismatch in reference from the function __change_page_attr() to the function .init.text:memblock_alloc()
The function __change_page_attr() references
the function __init memblock_alloc().
This is often because __change_page_attr lacks a __init
annotation or the annotation of memblock_alloc is wrong.
WARNING: vmlinux.o(.text+0x491d1): Section mismatch in reference from the function __change_page_attr() to the function .meminit.text:memblock_free()
The function __change_page_attr() references
the function __meminit memblock_free().
This is often because __change_page_attr lacks a __meminit
annotation or the annotation of memblock_free is wrong.
Why do we need this whole early mapping? For the guest? I don't like
that memblock thing at all.
So I think the approach with the .data..percpu..hv_shared section is
fine and we should consider SEV-ES
http://support.amd.com/TechDocs/Protecting%20VM%20Register%20State%20with%20SEV-ES.pdf
and do this right from the get-go so that when SEV-ES comes along, we
should simply be ready and extend that mechanism to put the whole Guest
Hypervisor Communication Block in there.
But then the fact that you're mapping those decrypted in init_mm.pgd
makes me think you don't need that early mapping thing at all. Those are
the decrypted mappings of the hypervisor. And that you can do late.
Now, what would be better, IMHO (and I have no idea about virtualization
design so take with a grain of salt) is if the guest would allocate
enough memory for the GHCB and mark it decrypted from the very
beginning. It will be the communication vehicle with the hypervisor
anyway.
And we already do similar things in sme_map_bootdata() for the baremetal
kernel to map boot_data, initrd, EFI, ... and so on things decrypted.
And we should extend that mechanism to map the GHCB in the guest too and
then we can get rid of all that need for ->force_memblock which makes
the crazy mess in pageattr.c even crazier. And it would be lovely if we
can do it without it.
But maybe Paolo might have an even better idea...
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* CRYPTO_MAX_ALG_NAME is too low
From: Alexander Sverdlin @ 2017-03-10 11:55 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: linux-crypto
Hello crypto maintainers!
We've found and example of the ipsec algorithm combination, which doesn't fit
into CRYPTO_MAX_ALG_NAME long buffers:
ip x s add src 1.1.1.1 dst 1.1.1.2 proto esp spi 0 mode tunnel enc des3_ede 0x0 auth sha256 0x0 flag esn replay-window 256
produces "echainiv(authencesn(hmac(sha256-generic),cbc(des3_ede-generic)))"
on the machines without optimized crypto drivers, which doesn't fit into current
64-bytes buffers.
I see two possible options:
a) split CRYPTO_MAX_ALG_NAME into CRYPTO_MAX_ALG_NAME + CRYPTO_MAX_DRV_NAME pair
and make later, say, 96, because the former probably cannot be changed because of
numerous user-space exports. And change half of the code to use new define.
b) rename *-generic algorithms to *-gen, so that cra_driver_name will be shortened,
while MODULE_ALIAS_CRYPTO() could still be maintained in old and new form.
What are your thoughts?
--
Best regards,
Alexander Sverdlin.
^ permalink raw reply
* dm-crypt IV generation (summary)
From: Ondrej Mosnacek @ 2017-03-10 13:44 UTC (permalink / raw)
To: Milan Broz
Cc: linux-crypto, dm-devel, Mike Snitzer, Alasdair Kergon,
Mikulas Patocka, Herbert Xu, Binoy Jayan, Gilad Ben-Yossef
Hi all,
I was tasked to post a summary the whole dm-crypt IV generation
problem and all the suggested solutions along with their drawbacks, so
here it goes...
PROBLEM STATEMENT:
Currently, dm-crypt uses a fixed 512-byte sector size and handles
en-/decrypting of a bio by submitting a separate request to the crypto
API for each sector. This causes a performance problem with some
crypto drivers that have a high processing overhead for small
requests, i.e. most crypto accelerators [1][2] and also e.g. the
AES-NI driver [3].
POSSIBLE SOLUTIONS:
1. Move IV generator algorithms to crypto API and allow them to
process the whole bio at once. ([5] or something equivalent)
ISSUES:
a) The 'keycount' parameter.
In order to support multi-key modes from Loop-AES,
dm-crypt accepts a keycount parameter which, if it != 1, causes
consecutive sectors to be encrypted with a different key. This
parameter can be specified with any of the cipher modes, which makes
porting the whole scale of modes supported by dm-crypt to crypto API
rather messy, since a lot of dm-crypt specific stuff needs to be moved
into the crypto drivers.
b) New AEAD functionality; random IV generator.
The soon-to-be-added AEAD functionality in dm-crypt
introduces a new IV generator that generates IVs randomly and stores
them as sector metadata. This means IV generation cannot be handled
solely in the driver. Also, additional AEAD implementation of IV
generators would be eventually needed.
2. Restrict the keycount parameter to allow only reasonable
combinations and then move IV generators to crypto API.
In Loop-AES, the multi-key mode always uses exactly 64 keys and
there is no reasonable scenario where someone would like to use
keycount != 1 with other IV mode than LMK. Thus it might be acceptable
to only work with multiple keys in LMK (and only allow keycount == 64
for it) and work with just one key in all other modes (and only allow
keycount == 1 for them). I.e., the cipher format would remain the
same, just with more restricted values.
Note that this would be basically a breaking change (the keycount
parameter is documented [4], so there may be users somewhere that use
it in some unusual combination...). Still, such combinations would
have to be used explicitly, as they are never used with common
LUKS/Loop-AES/TrueCrypt partitions (something like cryptsetup --type
plain ... or dmsetup would have to be used directly).
Applying this change would allow implementing the IV generators as
simple crypto algorithms that honor the usual interface (without
setkey hacks and passing of special structures via IV).
ISSUES:
a) Backward incompatibility (see above).
b) Again need to somehow handle the new 'random' IV generator.
3. Extend crypto API to allow passing multiple requests at once (each
with a separate IV) to crypto drivers.
(see [3])
ISSUES:
a) HW accelerators would have to specifically support this
scheme (unless they are somehow programmable).
I.e. accelerators that already have the plain64 IV
generator hard-coded could not fully benefit from this (I don't know
how many are already out there). However, future ones could implement
this 'universal' IV mode and enjoy basically the same benefit.
4. Implement support of 4KB sectors (or other sizes, too) in dm-crypt.
This would partially help, since on devices with 4K sectors the
size of each crypto request would then be 8x bigger and overhead would
be reduced without the need to mess with the dm-crypt IV generators.
ISSUES:
a) Only 4KB would be processed at once, not the whole bio (but
it may suffice).
b) Partitions encrypted as 4KB sectors could not be safely
moved to a 512B-sector device (writes would not be atomic).
QUESTIONS:
@Mike/dm-devel: Do you think it would be feasible to apply solution 2
(thus introducing the small incompatibility)?
REFERENCES:
[1] https://nelenkov.blogspot.com/2015/05/hardware-accelerated-disk-encryption-in.html
[2] https://lkml.org/lkml/2017/3/2/274
[3] https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg23007.html
[4] https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt
[5] https://lkml.org/lkml/2017/2/7/182
Cheers,
Ondrej
^ permalink raw reply
* Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active
From: Brijesh Singh @ 2017-03-10 16:35 UTC (permalink / raw)
To: Borislav Petkov, Paolo Bonzini
Cc: brijesh.singh, simon.guinot, linux-efi, kvm, rkrcmar, matt,
linux-pci, linus.walleij, gary.hook, linux-mm, paul.gortmaker,
hpa, cl, dan.j.williams, aarcange, sfr, andriy.shevchenko,
herbert, bhe, xemul, joro, x86, peterz, piotr.luc, mingo, msalter,
ross.zwisler, dyoung, thomas.lendacky, jroedel, keescook, arnd,
toshi.kani, mathieu.desnoyers, luto, devel, <bhel
In-Reply-To: <20170309162942.jwtb3l33632zhbaz@pd.tnic>
Hi Boris and Paolo,
On 03/09/2017 10:29 AM, Borislav Petkov wrote:
> 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 0x40000000 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
>> 0x40000001 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.
>> 0x800000xx) 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
>> 0x40000000 valid".
>>
>>> + if (eax > 0x40000000) {
>>> + eax = 0x40000001;
>>> + ecx = 0;
>>> + native_cpuid(&eax, &ebx, &ecx, &edx);
>>> + if (!(eax & BIT(KVM_FEATURE_SEV)))
>>> + goto out;
>>> +
>>> + eax = 0x8000001f;
>>> + ecx = 0;
>>> + native_cpuid(&eax, &ebx, &ecx, &edx);
>>> + if (!(eax & 1))
>
> Right, so this is testing CPUID_0x8000001f_ECX(0)[0], SME. Why not
> simply set that bit for the guest too, in kvm?
>
CPUID_8000_001F[EAX] indicates whether the feature is supported.
CPUID_0x8000001F[EAX]:
* Bit 0 - SME supported
* Bit 1 - SEV supported
* Bit 3 - SEV-ES supported
We can use MSR_K8_SYSCFG[MemEncryptionModeEnc] to check if memory encryption is enabled.
Currently, KVM returns zero when guest OS read MSR_K8_SYSCFG. I can update my patch sets
to set this bit for SEV enabled guests.
We could update this patch to use the below logic:
* CPUID(0) - Check for AuthenticAMD
* CPID(1) - Check if under hypervisor
* CPUID(0x80000000) - Check for highest supported leaf
* CPUID(0x8000001F).EAX - Check for SME and SEV support
* rdmsr (MSR_K8_SYSCFG)[MemEncryptionModeEnc] - Check if SMEE is set
Paolo,
One question, do we need "AuthenticAMD" check when we are running under hypervisor ?
I was looking at qemu code and found that qemu exposes parameters to change the CPU
vendor id. The above check will fail if user changes the vendor id while launching
the SEV guest.
-Brijesh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
From: Krzysztof Kozlowski @ 2017-03-10 18:06 UTC (permalink / raw)
To: Nathan Royce
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
In-Reply-To: <CALaQ_hrikH8Q8ug9WTgnYR3UwSCip1DZtkkjj2NCLJVqcKQdZA@mail.gmail.com>
On Thu, Mar 09, 2017 at 05:16:35AM -0600, Nathan Royce wrote:
> Gave it a try on 4.10.1, but still to no avail:
(...)
> Also for the sake of testing, I did not add any FLAGS for compilation this time.
Damn, I am fixing bugs around but not the one you are hitting. Can you
also check if exynos_defconfig (+XTS + any other needed setting sfor
you) also has this issue?
I want to reproduce it but my setup does not use cryptswap. Probably I
will have to set it up.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] crypto: ccp - Assign DMA commands to the channel's CCP
From: Gary R Hook @ 2017-03-10 18:28 UTC (permalink / raw)
To: linux-crypto; +Cc: thomas.lendacky, gary.hook, herbert, davem
From: Gary R Hook <ghook@amd.com>
The CCP driver generally uses a round-robin approach when
assigning operations to available CCPs. For the DMA engine,
however, the DMA mappings of the SGs are associated with a
specific CCP. When an IOMMU is enabled, the IOMMU is
programmed based on this specific device.
If the DMA operations are not performed by that specific
CCP then addressing errors and I/O page faults will occur.
Update the CCP driver to allow a specific CCP device to be
requested for an operation and use this in the DMA engine
support.
Cc: <stable@vger.kernel.org> # 4.9.x-
Signed-off-by: Gary R Hook <gary.hook@amd.com>
---
drivers/crypto/ccp/ccp-dev.c | 5 ++++-
drivers/crypto/ccp/ccp-dmaengine.c | 1 +
include/linux/ccp.h | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 511ab04..92d1c69 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -283,11 +283,14 @@ unsigned int ccp_version(void)
*/
int ccp_enqueue_cmd(struct ccp_cmd *cmd)
{
- struct ccp_device *ccp = ccp_get_device();
+ struct ccp_device *ccp;
unsigned long flags;
unsigned int i;
int ret;
+ /* Some commands might need to be sent to a specific device */
+ ccp = cmd->ccp ? cmd->ccp : ccp_get_device();
+
if (!ccp)
return -ENODEV;
diff --git a/drivers/crypto/ccp/ccp-dmaengine.c b/drivers/crypto/ccp/ccp-dmaengine.c
index e5d9278..8d0eeb4 100644
--- a/drivers/crypto/ccp/ccp-dmaengine.c
+++ b/drivers/crypto/ccp/ccp-dmaengine.c
@@ -390,6 +390,7 @@ static struct ccp_dma_desc *ccp_create_desc(struct dma_chan *dma_chan,
goto err;
ccp_cmd = &cmd->ccp_cmd;
+ ccp_cmd->ccp = chan->ccp;
ccp_pt = &ccp_cmd->u.passthru_nomap;
ccp_cmd->flags = CCP_CMD_MAY_BACKLOG;
ccp_cmd->flags |= CCP_CMD_PASSTHRU_NO_DMA_MAP;
diff --git a/include/linux/ccp.h b/include/linux/ccp.h
index c71dd8f..c41b8d99 100644
--- a/include/linux/ccp.h
+++ b/include/linux/ccp.h
@@ -556,7 +556,7 @@ enum ccp_engine {
* struct ccp_cmd - CCP operation request
* @entry: list element (ccp driver use only)
* @work: work element used for callbacks (ccp driver use only)
- * @ccp: CCP device to be run on (ccp driver use only)
+ * @ccp: CCP device to be run on
* @ret: operation return code (ccp driver use only)
* @flags: cmd processing flags
* @engine: CCP operation to perform
^ permalink raw reply related
* [PATCH] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of crypto/s5p-sss
From: Krzysztof Kozlowski @ 2017-03-10 19:10 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, linux-crypto, linux-samsung-soc,
linux-kernel
Cc: Krzysztof Kozlowski, Vladimir Zapolskiy
Beside developing of this driver recently, I handle also reviews and
bug reports from users so having a maintainer entry will ensure that I
will be CC-ed on important emails.
Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 57634d0f3486..5dcd65e98b51 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10985,6 +10985,13 @@ F: Documentation/devicetree/bindings/regulator/samsung,s2m*.txt
F: Documentation/devicetree/bindings/regulator/samsung,s5m*.txt
F: Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
+SAMSUNG S5P Security SubSystem (SSS) DRIVER
+M: Krzysztof Kozlowski <krzk@kernel.org>
+L: linux-crypto@vger.kernel.org
+L: linux-samsung-soc@vger.kernel.org
+S: Maintained
+F: drivers/crypto/s5p-sss.c
+
SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS
M: Kyungmin Park <kyungmin.park@samsung.com>
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of crypto/s5p-sss
From: Vladimir Zapolskiy @ 2017-03-10 21:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Herbert Xu, David S . Miller, linux-crypto,
linux-samsung-soc, linux-kernel
In-Reply-To: <20170310191038.7726-1-krzk@kernel.org>
Hi Krzysztof,
On 03/10/2017 09:10 PM, Krzysztof Kozlowski wrote:
> Beside developing of this driver recently, I handle also reviews and
> bug reports from users so having a maintainer entry will ensure that I
> will be CC-ed on important emails.
if you assume that the driver needs a special maintainership, can you
add me as a co-maintainer? I'll review new changes as usual and do
regression testing on legacy SoCs.
Thanks.
^ permalink raw reply
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
From: Nathan Royce @ 2017-03-10 21:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
In-Reply-To: <20170310180640.dnacw53vqrqji2xo@kozik-lap>
[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]
Sure, I went ahead and rebuilt it just using the bare exynos_defconfig
and adding XTS and ECB and no other changes.
No flags were used. No patches were used other than the 2 you
provided. Just the barest of bears, the barest of bones, the barest of
deserts, the barest of hairless cats.
I also wiped out the 4.10.1 modules directory and zImage and dtb
before copying them into place.
*****
[ 16.280951] s5p-jpeg 11f60000.jpeg: Samsung S5P JPEG codec
[ 16.327434] CPU: 3 PID: 115 Comm: irq/69-10830000 Not tainted 4.10.1-dirty #1
[ 16.334527] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 16.340533] task: edc52d00 task.stack: edcc0000
[ 16.345040] PC is at post_crypt+0x194/0x1a0 [xts]
[ 16.349712] LR is at post_crypt+0x188/0x1a0 [xts]
[ 16.354390] pc : [<bf182370>] lr : [<bf182364>] psr: 200d0113
[ 16.354390] sp : edcc1ea8 ip : ed6f38f4 fp : 30702272
[ 16.365838] r10: 8ee5436d r9 : 00000000 r8 : ed6f3800
[ 16.371023] r7 : 00000000 r6 : 00000400 r5 : 00000000 r4 : 00000000
[ 16.377523] r3 : ef5ead22 r2 : 00000200 r1 : 00000200 r0 : 00000000
[ 16.384024] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 16.391128] Control: 10c5387d Table: 6d6f806a DAC: 00000051
[ 16.396847] Process irq/69-10830000 (pid: 115, stack limit = 0xedcc0210)
[ 16.403519] Stack: (0xedcc1ea8 to 0xedcc2000)
[ 16.407853] 1ea0: c0c08304 ef5ead20 ecd69200
ef5ead20 ecd69200 ed6f39dc
[ 16.416011] 1ec0: 00000400 00000000 00000000 00000400 00000000
c010f774 c0113bac 00000000
[ 16.424156] 1ee0: 00000000 00000000 00000000 00000000 00000000
00000010 00000010 0000000f
[ 16.432302] 1f00: ed6f3800 edcae3bc 0000000c edcae3e8 00000000
600d0113 ee889d5c bf182764
[ 16.440447] 1f20: edcae390 c0566d84 00000000 00000001 edcacec0
eea14b00 00000000 eea14b00
[ 16.448592] 1f40: edcacec0 c01651c4 eeb00528 c01651e0 edcc0000
edcacee4 00000000 c01654b4
[ 16.456738] 1f60: 00000000 c01652b8 eeb00500 edcc0000 00000000
edcacf00 edcacec0 c0165388
[ 16.464884] 1f80: eeb00528 c013673c edcc0000 edcacf00 c0136634
00000000 00000000 00000000
[ 16.473029] 1fa0: 00000000 00000000 00000000 c0107778 00000000
00000000 00000000 00000000
[ 16.481174] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 16.489320] 1fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 16.497473] [<bf182370>] (post_crypt [xts]) from [<bf182764>]
(decrypt_done+0x4c/0x54 [xts])
[ 16.505877] [<bf182764>] (decrypt_done [xts]) from [<c0566d84>]
(s5p_aes_interrupt+0x1bc/0x208)
[ 16.514544] [<c0566d84>] (s5p_aes_interrupt) from [<c01651e0>]
(irq_thread_fn+0x1c/0x54)
[ 16.522592] [<c01651e0>] (irq_thread_fn) from [<c01654b4>]
(irq_thread+0x12c/0x1e0)
[ 16.530220] [<c01654b4>] (irq_thread) from [<c013673c>] (kthread+0x108/0x138)
[ 16.537324] [<c013673c>] (kthread) from [<c0107778>]
(ret_from_fork+0x14/0x3c)
[ 16.544514] Code: eb471ad2 e598c118 e58d0020 e1a04000 (e5906004)
[ 16.550709] ---[ end trace 0e5ce4ea2ad2d7e2 ]---
[ 16.555224] genirq: exiting task "irq/69-10830000" (115) is an
active IRQ thread (irq 69)
*****
I'm sure you could just copy my crypttab and fstab entries that is
shown in my first email.
On Fri, Mar 10, 2017 at 12:06 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Mar 09, 2017 at 05:16:35AM -0600, Nathan Royce wrote:
>> Gave it a try on 4.10.1, but still to no avail:
>
> (...)
>
>> Also for the sake of testing, I did not add any FLAGS for compilation this time.
>
> Damn, I am fixing bugs around but not the one you are hitting. Can you
> also check if exynos_defconfig (+XTS + any other needed setting sfor
> you) also has this issue?
>
> I want to reproduce it but my setup does not use cryptswap. Probably I
> will have to set it up.
>
> Best regards,
> Krzysztof
>
[-- Attachment #2: config_s5psss.tar.gz --]
[-- Type: application/x-gzip, Size: 31980 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages
From: Brijesh Singh @ 2017-03-10 22:41 UTC (permalink / raw)
To: Borislav Petkov, Paolo Bonzini
Cc: brijesh.singh, simon.guinot, linux-efi, kvm, rkrcmar, matt,
linux-pci, linus.walleij, gary.hook, linux-mm, paul.gortmaker,
hpa, cl, dan.j.williams, aarcange, sfr, andriy.shevchenko,
herbert, bhe, xemul, joro, x86, peterz, piotr.luc, mingo, msalter,
ross.zwisler, dyoung, thomas.lendacky, jroedel, keescook, arnd,
toshi.kani
In-Reply-To: <20170310110657.hophlog2juw5hpzz@pd.tnic>
Hi Boris,
On 03/10/2017 05:06 AM, Borislav Petkov wrote:
> On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote:
>> If kernel_maps_pages_in_pgd is called early in boot process to change the
>
> kernel_map_pages_in_pgd()
>
>> memory attributes then it fails to allocate memory when spliting large
>> pages. The patch extends the cpa_data to provide the support to use
>> memblock_alloc when slab allocator is not available.
>>
>> The feature will be used in Secure Encrypted Virtualization (SEV) mode,
>> where we may need to change the memory region attributes in early boot
>> process.
>>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>> arch/x86/mm/pageattr.c | 51 ++++++++++++++++++++++++++++++++++++++++--------
>> 1 file changed, 42 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
>> index 46cc89d..9e4ab3b 100644
>> --- a/arch/x86/mm/pageattr.c
>> +++ b/arch/x86/mm/pageattr.c
>> @@ -14,6 +14,7 @@
>> #include <linux/gfp.h>
>> #include <linux/pci.h>
>> #include <linux/vmalloc.h>
>> +#include <linux/memblock.h>
>>
>> #include <asm/e820/api.h>
>> #include <asm/processor.h>
>> @@ -37,6 +38,7 @@ struct cpa_data {
>> int flags;
>> unsigned long pfn;
>> unsigned force_split : 1;
>> + unsigned force_memblock :1;
>> int curpage;
>> struct page **pages;
>> };
>> @@ -627,9 +629,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
>>
>> static int
>> __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
>> - struct page *base)
>> + pte_t *pbase, unsigned long new_pfn)
>> {
>> - pte_t *pbase = (pte_t *)page_address(base);
>> unsigned long ref_pfn, pfn, pfninc = 1;
>> unsigned int i, level;
>> pte_t *tmp;
>> @@ -646,7 +647,7 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
>> return 1;
>> }
>>
>> - paravirt_alloc_pte(&init_mm, page_to_pfn(base));
>> + paravirt_alloc_pte(&init_mm, new_pfn);
>>
>> switch (level) {
>> case PG_LEVEL_2M:
>> @@ -707,7 +708,8 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
>> * pagetable protections, the actual ptes set above control the
>> * primary protection behavior:
>> */
>> - __set_pmd_pte(kpte, address, mk_pte(base, __pgprot(_KERNPG_TABLE)));
>> + __set_pmd_pte(kpte, address,
>> + native_make_pte((new_pfn << PAGE_SHIFT) + _KERNPG_TABLE));
>>
>> /*
>> * Intel Atom errata AAH41 workaround.
>> @@ -723,21 +725,50 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
>> return 0;
>> }
>>
>> +static pte_t *try_alloc_pte(struct cpa_data *cpa, unsigned long *pfn)
>> +{
>> + unsigned long phys;
>> + struct page *base;
>> +
>> + if (cpa->force_memblock) {
>> + phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
>
> Maybe there's a reason this fires:
>
> WARNING: modpost: Found 2 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>
> WARNING: vmlinux.o(.text+0x48edc): Section mismatch in reference from the function __change_page_attr() to the function .init.text:memblock_alloc()
> The function __change_page_attr() references
> the function __init memblock_alloc().
> This is often because __change_page_attr lacks a __init
> annotation or the annotation of memblock_alloc is wrong.
>
> WARNING: vmlinux.o(.text+0x491d1): Section mismatch in reference from the function __change_page_attr() to the function .meminit.text:memblock_free()
> The function __change_page_attr() references
> the function __meminit memblock_free().
> This is often because __change_page_attr lacks a __meminit
> annotation or the annotation of memblock_free is wrong.
>
I can take a look at fixing those warning. In my initial attempt was to create
a new function to clear encryption bit but it ended up looking very similar to
__change_page_attr_set_clr() hence decided to extend the exiting function to
use memblock_alloc().
> Why do we need this whole early mapping? For the guest? I don't like
> that memblock thing at all.
Early in boot process, guest kernel allocates some structure (its either
statically allocated or dynamic allocated via memblock_alloc). And shares the physical
address of these structure with hypervisor. Since entire guest memory area is mapped
as encrypted hence those structure's are mapped as encrypted memory range. We need
a method to clear the encryption bit. Sometime these structure maybe part of 2M pages
and need to split into smaller pages.
>
> So I think the approach with the .data..percpu..hv_shared section is
> fine and we should consider SEV-ES
>
> http://support.amd.com/TechDocs/Protecting%20VM%20Register%20State%20with%20SEV-ES.pdf
>
> and do this right from the get-go so that when SEV-ES comes along, we
> should simply be ready and extend that mechanism to put the whole Guest
> Hypervisor Communication Block in there.
>
> But then the fact that you're mapping those decrypted in init_mm.pgd
> makes me think you don't need that early mapping thing at all. Those are
> the decrypted mappings of the hypervisor. And that you can do late.
>
In most cases, guest and hypervisor communication starts as soon as guest provides
the physical address to hypervisor. So we must map the pages as decrypted before
sharing the physical address to hypervisor.
> Now, what would be better, IMHO (and I have no idea about virtualization
> design so take with a grain of salt) is if the guest would allocate
> enough memory for the GHCB and mark it decrypted from the very
> beginning. It will be the communication vehicle with the hypervisor
> anyway.
>
> And we already do similar things in sme_map_bootdata() for the baremetal
> kernel to map boot_data, initrd, EFI, ... and so on things decrypted.
>
I will take a look at sme_map_bootdata but I believe the main difference is,
in case of SME those memory regions were allocated by bios or bootloader as
decrypted and sme_map_bootdata clears the encryptions bit.
In case of guest, memory maybe dynamically allocated at boot time and may not have same
attribute as early mapping.
> And we should extend that mechanism to map the GHCB in the guest too and
> then we can get rid of all that need for ->force_memblock which makes
> the crazy mess in pageattr.c even crazier. And it would be lovely if we
> can do it without it.
>
> But maybe Paolo might have an even better idea...
>
I am sure he will have better idea :)
-Brijesh
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of crypto/s5p-sss
From: Krzysztof Kozlowski @ 2017-03-11 6:02 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Herbert Xu, David S . Miller, linux-crypto, linux-samsung-soc,
linux-kernel
In-Reply-To: <6f86bed1-df24-9f0b-b32b-3e00674be8c0@mleia.com>
On Fri, Mar 10, 2017 at 11:18:13PM +0200, Vladimir Zapolskiy wrote:
> Hi Krzysztof,
>
> On 03/10/2017 09:10 PM, Krzysztof Kozlowski wrote:
> > Beside developing of this driver recently, I handle also reviews and
> > bug reports from users so having a maintainer entry will ensure that I
> > will be CC-ed on important emails.
>
> if you assume that the driver needs a special maintainership, can you
> add me as a co-maintainer? I'll review new changes as usual and do
> regression testing on legacy SoCs.
Of course, I'll send a v2.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] MAINTAINERS: Add maintianer entry for crypto/s5p-sss
From: Krzysztof Kozlowski @ 2017-03-11 6:11 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
Cc: Vladimir Zapolskiy, Krzysztof Kozlowski
Add Krzysztof Kozlowski and Vladimir Zapolskiy as maintainers of s5p-sss
driver for handling reviews, testing and getting bug reports from the
users.
Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v1:
1. Add also Vladimir
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 57634d0f3486..94b221714fa8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10985,6 +10985,14 @@ F: Documentation/devicetree/bindings/regulator/samsung,s2m*.txt
F: Documentation/devicetree/bindings/regulator/samsung,s5m*.txt
F: Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
+SAMSUNG S5P Security SubSystem (SSS) DRIVER
+M: Krzysztof Kozlowski <krzk@kernel.org>
+M: Vladimir Zapolskiy <vz@mleia.com>
+L: linux-crypto@vger.kernel.org
+L: linux-samsung-soc@vger.kernel.org
+S: Maintained
+F: drivers/crypto/s5p-sss.c
+
SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS
M: Kyungmin Park <kyungmin.park@samsung.com>
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
--
2.9.3
^ permalink raw reply related
* 11859 linux-crypto
From: e.camilla.johansson @ 2017-03-12 0:54 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: 245663.zip --]
[-- Type: application/zip, Size: 3944 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox