Re: CRYPTO_MAX_ALG_NAME is too low

Hello! On 10/03/17 12:55, Alexander Sverdlin wrote: > 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

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

On 3/16/2017 5:16 AM, Borislav Petkov wrote: On Fri, Mar 10, 2017 at 10:35:30AM -0600, Brijesh Singh wrote: We could update this patch to use the below logic: * CPUID(0) - Check for AuthenticAMD * CPID(1) - Check if under hypervisor * CPUID(0x8000) - Check for highest supported leaf *

[PATCH] md5: remove from lib and only live in crypto

The md5_transform function is no longer used any where in the tree, except for the crypto api's actual implementation of md5, so we can drop the function from lib and put it as a static function of the crypto file, where it belongs. There should be no new users of md5_transform, anyway, since

Re: [RFC 0/7] crypto: caam - add Queue Interface (QI) support

On 3/16/2017 10:43 AM, Herbert Xu wrote: > On Fri, Mar 03, 2017 at 04:52:06PM +0200, Horia Geantă wrote: >> The patchset adds support for CAAM Queue Interface (QI), the additional >> interface (besides job ring) available for submitting jobs to the engine >> on platforms having DPAA (Datapath

Re: [RFC PATCH v2 32/32] x86: kvm: Pin the guest memory when SEV is active

On 03/16/2017 05:38 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: The SEV memory encryption engine uses a tweak such that two identical plaintexts at different location will have a different ciphertexts. So swapping or moving ciphertexts of two pages will not result in

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Fri, Mar 10, 2017 at 04:41:56PM -0600, Brijesh Singh wrote: > 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

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

On Thu, Mar 16, 2017 at 11:11:26AM -0500, Tom Lendacky wrote: > Not quite. The guest still needs to understand about the encryption mask > so that it can protect memory by setting the encryption mask in the > pagetable entries. It can also decide when to share memory with the > hypervisor by not

Re: [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0

Hi Herbert, Herbert Xu writes: > On Wed, Feb 22, 2017 at 07:55:24AM +0100, Heiner Kallweit wrote: >> Expose clock CLKID_RNG0 which is needed for the HW random number generator. >> >> Signed-off-by: Heiner Kallweit > > All patches applied.

Re: [RFC PATCH v2 30/32] kvm: svm: Add support for SEV DEBUG_ENCRYPT command

On 03/16/2017 06:03 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: + data = (void *) get_zeroed_page(GFP_KERNEL); The page does not need to be zeroed, does it? No, we don't have to zero it. I will fix it. + + if ((len & 15) || (dst_addr & 15)) { +

Re: [RFC PATCH v2 26/32] kvm: svm: Add support for SEV LAUNCH_UPDATE_DATA command

On 03/16/2017 05:48 AM, Paolo Bonzini wrote: On 02/03/2017 16:17, Brijesh Singh wrote: +static struct page **sev_pin_memory(unsigned long uaddr, unsigned long ulen, + unsigned long *n) +{ + struct page **pages; + int first, last; + unsigned

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

On Thu, Mar 16, 2017 at 09:28:58AM -0500, Tom Lendacky wrote: > Because there are differences between how SME and SEV behave > (instruction fetches are always decrypted under SEV, DMA to an > encrypted location is not supported under SEV, etc.) we need to > determine which mode we are in so that

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

On 3/16/2017 10:09 AM, Borislav Petkov wrote: On Thu, Mar 16, 2017 at 09:28:58AM -0500, Tom Lendacky wrote: Because there are differences between how SME and SEV behave (instruction fetches are always decrypted under SEV, DMA to an encrypted location is not supported under SEV, etc.) we need to

Re: [PATCH v5 1/2] crypto: skcipher AF_ALG - overhaul memory management

On Fri, Feb 17, 2017 at 11:31:41PM +0100, Stephan Müller wrote: > > + } else { > + /* Synchronous operation */ > + skcipher_request_set_callback(>req, > + CRYPTO_TFM_REQ_MAY_SLEEP | > +

Re: [RFC 0/7] crypto: caam - add Queue Interface (QI) support

On Fri, Mar 03, 2017 at 04:52:06PM +0200, Horia Geantă wrote: > The patchset adds support for CAAM Queue Interface (QI), the additional > interface (besides job ring) available for submitting jobs to the engine > on platforms having DPAA (Datapath Acceleration Architecture). > > Patches 1-4 are

Re: [PATCH v5 1/2] crypto: skcipher AF_ALG - overhaul memory management

Am Donnerstag, 16. März 2017, 09:39:23 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Feb 17, 2017 at 11:31:41PM +0100, Stephan Müller wrote: > > + } else { > > + /* Synchronous operation */ > > + skcipher_request_set_callback(>req, > > +

Re: [PATCH v5 1/2] crypto: skcipher AF_ALG - overhaul memory management

On Thu, Mar 16, 2017 at 09:55:17AM +0100, Stephan Müller wrote: > > With this approach I thought that the while loop could be a thing of the > past, > considering that this is also the approach taken in skcipher_recvmsg_async > that is present in the current upstream code base. The reason

Re: [PATCH v5 1/2] crypto: skcipher AF_ALG - overhaul memory management

Am Donnerstag, 16. März 2017, 10:08:23 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Mar 16, 2017 at 09:55:17AM +0100, Stephan Müller wrote: > > With this approach I thought that the while loop could be a thing of the > > past, considering that this is also the approach taken in > >

Re: [PATCH v5 1/2] crypto: skcipher AF_ALG - overhaul memory management

Am Donnerstag, 16. März 2017, 11:18:33 CET schrieb Stephan Müller: Hi Stephan, > Am Donnerstag, 16. März 2017, 10:52:48 CET schrieb Herbert Xu: > > Hi Herbert, > > > First of all you're only limiting the amount of memory occupied > > by the SG list which is not the same thing as the memory

Re: [PATCH 1/4] crypto: powerpc - Factor out the core CRC vpmsum algorithm

> So although this sits in arch/powerpc, it's heavy on the crypto which is > not my area of expertise (to say the least!), so I think it should > probably go via Herbert and the crypto tree? That was my thought as well. Sorry - probably should have put that in the comments somewhere. Regards,

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On 02/03/2017 16:15, Brijesh Singh wrote: > > __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); Just one comment and

Re: [RFC PATCH v2 05/32] x86: Use encrypted access of BOOT related data with SEV

On 3/7/2017 5:09 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:12:59AM -0500, Brijesh Singh wrote: From: Tom Lendacky When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as EFI related data, setup data) is encrypted and needs to be accessed

Re: [RFC PATCH v2 29/32] kvm: svm: Add support for SEV DEBUG_DECRYPT command

On 03/16/2017 05:54 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: +static int __sev_dbg_decrypt_page(struct kvm *kvm, unsigned long src, + void *dst, int *error) +{ + inpages = sev_pin_memory(src, PAGE_SIZE, ); + if (!inpages) { +

Re: [RFC 0/7] crypto: caam - add Queue Interface (QI) support

On Thu, 2017-03-16 at 14:13 +, Horia Geantă wrote: > On 3/16/2017 10:43 AM, Herbert Xu wrote: > > > > On Fri, Mar 03, 2017 at 04:52:06PM +0200, Horia Geantă wrote: > > > > > > The patchset adds support for CAAM Queue Interface (QI), the additional > > > interface (besides job ring) available

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On 10/03/2017 23:41, Brijesh Singh wrote: >> 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

Re: [RFC 4/7] soc/qman: add helper functions needed by caam/qi driver

On Fri, 2017-03-03 at 16:52 +0200, Horia Geantă wrote: > Add helper functions, macros, #defines for accessing / enabling > qman functionality from caam/qi driver, such that this driver > is not aware of the need for data conversion to big endian. Why?  I complained about that (probably

Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

On 3/7/2017 8:59 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote: From: Tom Lendacky In order for memory pages to be properly mapped when SEV is active, we need to use the PAGE_KERNEL protection attribute as the base

[PATCH 6/7] md/raid10, LLVM: get rid of variable length array

Replace a variable length array in a struct by allocating the memory for the entire struct in a char array on the stack. Signed-off-by: Michael Davidson --- drivers/md/raid10.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/md/raid10.c

[PATCH 7/7] crypto, x86, LLVM: aesni - fix token pasting

aes_ctrby8_avx-x86_64.S uses the C preprocessor for token pasting of character sequences that are not valid preprocessor tokens. While this is allowed when preprocessing assembler files it exposes an incompatibilty between the clang and gcc preprocessors where clang does not strip leading white

[PATCH 1/7] Makefile, LLVM: add -no-integrated-as to KBUILD_[AC]FLAGS

Add -no-integrated-as to KBUILD_AFLAGS and KBUILD_CFLAGS for clang. Signed-off-by: Michael Davidson --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index b841fb36beb2..b21fd0ca2946 100644 --- a/Makefile +++ b/Makefile @@ -704,6 +704,8 @@

[PATCH 5/7] x86, boot, LLVM: Use regparm=0 for memcpy and memset

Use the standard regparm=0 calling convention for memcpy and memset when building with clang. This is a work around for a long standing clang bug (see https://llvm.org/bugs/show_bug.cgi?id=3997) where clang always uses the standard regparm=0 calling convention for any implcit calls to memcpy and

[PATCH 0/7] LLVM: make x86_64 kernel build with clang.

This patch set is sufficient to get the x86_64 kernel to build and boot correctly with clang-3.8 or greater. The resulting build still has about 300 warnings, very few of which appear to be significant. Most of them should be fixable with some minor code refactoring although a few of them, such

[PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses

Suppress clang warnings about potential unaliged accesses to members in packed structs. This gets rid of almost 10,000 warnings about accesses to the ring 0 stack pointer in the TSS. Signed-off-by: Michael Davidson --- arch/x86/Makefile | 5 + 1 file changed, 5

Re: [PATCH v5 1/2] crypto: skcipher AF_ALG - overhaul memory management

On Thu, Mar 16, 2017 at 10:23:49AM +0100, Stephan Müller wrote: > Am Donnerstag, 16. März 2017, 10:08:23 CET schrieb Herbert Xu: > > Hi Herbert, > > > On Thu, Mar 16, 2017 at 09:55:17AM +0100, Stephan Müller wrote: > > > With this approach I thought that the while loop could be a thing of the >

Re: [PATCH] crypto: ccp - Assign DMA commands to the channel's CCP

On Fri, Mar 10, 2017 at 12:28:18PM -0600, Gary R Hook wrote: > From: Gary R Hook > > 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.

Re: [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0

On Wed, Feb 22, 2017 at 07:55:24AM +0100, Heiner Kallweit wrote: > Expose clock CLKID_RNG0 which is needed for the HW random number generator. > > Signed-off-by: Heiner Kallweit All patches applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH v2] MAINTAINERS: Add maintianer entry for crypto/s5p-sss

On Sat, Mar 11, 2017 at 08:11:00AM +0200, Krzysztof Kozlowski wrote: > 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 > Cc: Herbert Xu

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

Fabien Dessenne wrote: > Add missing " " in api-samples.rst > > Signed-off-by: Fabien Dessenne Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

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

On Fri, Mar 10, 2017 at 10:35:30AM -0600, Brijesh Singh wrote: > We could update this patch to use the below logic: > > * CPUID(0) - Check for AuthenticAMD > * CPID(1) - Check if under hypervisor > * CPUID(0x8000) - Check for highest supported leaf > * CPUID(0x801F).EAX - Check for

RE: [PATCH 1/4] crypto: powerpc - Factor out the core CRC vpmsum algorithm

From: Daniel Axtens > Sent: 15 March 2017 22:30 > Hi David, > > > While not part of this change, the unrolled loops look as though > > they just destroy the cpu cache. > > I'd like be convinced that anything does CRC over long enough buffers > > to make it a gain at all. > > > > With modern (not

Re: [RFC PATCH v2 24/32] kvm: x86: prepare for SEV guest management API support

On 02/03/2017 16:17, Brijesh Singh wrote: > ASID management: > - Reserve asid range for SEV guest, SEV asid range is obtained through >CPUID Fn8000_001f[ECX]. A non-SEV guest can use any asid outside the SEV >asid range. How is backwards compatibility handled? > - SEV guest must have

Re: [RFC PATCH v2 30/32] kvm: svm: Add support for SEV DEBUG_ENCRYPT command

On 02/03/2017 16:18, Brijesh Singh wrote: > + data = (void *) get_zeroed_page(GFP_KERNEL); The page does not need to be zeroed, does it? > + > + if ((len & 15) || (dst_addr & 15)) { > + /* if destination address and length are not 16-byte > + * aligned then: >

Re: [PATCH 1/4] crypto: powerpc - Factor out the core CRC vpmsum algorithm

Hi David, > While not part of this change, the unrolled loops look as though > they just destroy the cpu cache. > I'd like be convinced that anything does CRC over long enough buffers > to make it a gain at all. btrfs data checksumming is one area. > With modern (not that modern now)

[PATCH 4/7] x86, boot, LLVM: #undef memcpy etc in string.c

undef memcpy and friends in boot/string.c so that the functions defined here will have the correct names, otherwise we end up up trying to redefine __builtin_memcpy etc. Surprisingly, gcc allows this (and, helpfully, discards the __builtin_ prefix from the function name when compiling it), but

[PATCH 2/7] Makefile, x86, LLVM: disable unsupported optimization flags

Unfortunately, while clang generates a warning about these flags being unsupported it still exits with a status of 0 so we have to explicitly disable them instead of just using a cc-option check. Signed-off-by: Michael Davidson --- Makefile | 2 ++ arch/x86/Makefile |

Re: [RFC PATCH v2 23/32] kvm: introduce KVM_MEMORY_ENCRYPT_OP ioctl

On 02/03/2017 16:17, Brijesh Singh wrote: > If hardware supports encrypting then KVM_MEMORY_ENCRYPT_OP ioctl can > be used by qemu to issue platform specific memory encryption commands. > > Signed-off-by: Brijesh Singh > --- > arch/x86/include/asm/kvm_host.h |2 ++ >

Re: [PATCH 1/4] crypto: powerpc - Factor out the core CRC vpmsum algorithm

Daniel Axtens writes: > The core nuts and bolts of the crc32c vpmsum algorithm will > also work for a number of other CRC algorithms with different > polynomials. Factor out the function into a new asm file. > > To handle multiple users of the function, a user simply > provides

Re: [PATCH 2/4] crypto: powerpc - Re-enable non-REFLECTed CRCs

Daniel Axtens writes: > When CRC32c was included in the kernel, Anton ripped out > the #ifdefs around reflected polynomials, because CRC32c > is always reflected. However, not all CRCs use reflection > so we'd like to make it optional. > > Restore the REFLECT parts from Anton's

Re: [RFC PATCH v2 29/32] kvm: svm: Add support for SEV DEBUG_DECRYPT command

On 02/03/2017 16:18, Brijesh Singh wrote: > +static int __sev_dbg_decrypt_page(struct kvm *kvm, unsigned long src, > + void *dst, int *error) > +{ > + inpages = sev_pin_memory(src, PAGE_SIZE, ); > + if (!inpages) { > + ret = -ENOMEM; > + goto err_1; >

Re: [RFC PATCH v2 16/32] x86: kvm: Provide support to create Guest and HV shared per-CPU variables

On 02/03/2017 16:15, Brijesh Singh wrote: > Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU > variable at compile time and share its physical address with hypervisor. > It presents a challege when SEV is active in guest OS. When SEV is active, > guest memory is

Re: [PATCH 0/2] hwrng: revert managed API changes for amd and geode

On Tue, Mar 14, 2017 at 07:36:00AM -0400, Prarit Bhargava wrote: > When booting top-of-tree the following WARN_ON triggers in the kernel on > a 15h AMD system. > > WARNING: CPU: 2 PID: 621 at drivers/base/dd.c:349 driver_probe_device+0x38c > Modules linked in: i2c_amd756(+) amd_rng sg pcspkr

Re: [PATCH 0/4] hwrng: omap - fixes and improvements

On Tue, Mar 07, 2017 at 03:14:45PM +0100, Thomas Petazzoni wrote: > Hello, > > This small patch series brings a few fixes and improvements to the > omap_rng driver. The first fix is particularly important, as it fixes > using the driver built as a module on SoCs that require a clock for > the IP

Re: [PATCH v1 0/8] improve performances on mediatek crypto driver

On Thu, Mar 09, 2017 at 10:11:11AM +0800, Ryder Lee wrote: > Hi all, > > Some patches of this series improve the performances whereas others > clean up code and refine data structure to make it more efficient > > Changes since v1: > - drop OFB and CFB patch > > Ryder Lee (8): > crypto:

Re: [PATCH v5 1/2] crypto: skcipher AF_ALG - overhaul memory management

Am Donnerstag, 16. März 2017, 10:52:48 CET schrieb Herbert Xu: Hi Herbert, > First of all you're only limiting the amount of memory occupied > by the SG list which is not the same thing as the memory pinned > down by the actual recvmsg. I am fully aware of that. As this was present in the code,

Re: [RFC PATCH v2 32/32] x86: kvm: Pin the guest memory when SEV is active

On 02/03/2017 16:18, Brijesh Singh wrote: > The SEV memory encryption engine uses a tweak such that two identical > plaintexts at different location will have a different ciphertexts. > So swapping or moving ciphertexts of two pages will not result in > plaintexts being swapped. Relocating (or

Re: [RFC PATCH v2 26/32] kvm: svm: Add support for SEV LAUNCH_UPDATE_DATA command

On 02/03/2017 16:17, Brijesh Singh wrote: > +static struct page **sev_pin_memory(unsigned long uaddr, unsigned long ulen, > + unsigned long *n) > +{ > + struct page **pages; > + int first, last; > + unsigned long npages, pinned; > + > + /* Get