[PATCH] crypto, xor: Sanitize checksumming function selection output

2012-04-04 Thread Borislav Petkov
From: Borislav Petkov borislav.pet...@amd.com Currently, it says [1.015541] xor: automatically using best checksumming function: generic_sse [1.040769]generic_sse: 6679.000 MB/sec [1.045377] xor: using function: generic_sse (6679.000 MB/sec) and repeats the function name three

Re: [PATCH] crypto: twofish - add x86_64/avx assembler implementation

2012-08-15 Thread Borislav Petkov
On Wed, Aug 15, 2012 at 11:42:16AM +0300, Jussi Kivilinna wrote: I started thinking about the performance on AMD Bulldozer. vmovq/vmovd/vpextr*/vpinsr* between FPU and general purpose registers on AMD CPU is alot slower (latencies from 8 to 12 cycles) than on Intel sandy-bridge (where

Re: [PATCH] crypto: twofish - add x86_64/avx assembler implementation

2012-08-15 Thread Borislav Petkov
Ok, here we go. Raw data below. On Wed, Aug 15, 2012 at 02:00:16PM +0300, Jussi Kivilinna wrote: And if you tell me exactly how to run the tests and on what kernel, I'll try to do so. Ok, the box is a single-socket Bulldozer: AMD FX(tm)-8100 Eight-Core Processor stepping 02; kernel is

Re: [PATCH] crypto: twofish - add x86_64/avx assembler implementation

2012-08-15 Thread Borislav Petkov
On Wed, Aug 15, 2012 at 04:48:54PM +0300, Jussi Kivilinna wrote: I posted patch that optimize twofish-avx few weeks ago: http://marc.info/?l=linux-crypto-vgerm=134364845024825w=2 I'd be interested to know, if this is patch helps on Bulldozer. Sure, can you inline it here too please. The

Re: [PATCH] crypto: twofish - add x86_64/avx assembler implementation

2012-08-15 Thread Borislav Petkov
On Wed, Aug 15, 2012 at 05:22:03PM +0300, Jussi Kivilinna wrote: Patch replaces 'movb' instructions with 'movzbl' to break false register dependencies and interleaves instructions better for out-of-order scheduling. Also move common round code to separate function to reduce object size.

Re: [PATCH] crypto: twofish - add x86_64/avx assembler implementation

2012-08-16 Thread Borislav Petkov
On Wed, Aug 15, 2012 at 08:34:25PM +0300, Jussi Kivilinna wrote: About ~5% slower, probably because I was tuning for sandy-bridge and introduced more FPU=CPU register moves. Here's new version of patch, with FPU=CPU moves from original implementation. (Note: also changes encryption function

Re: [PATCH] crypto: twofish - add x86_64/avx assembler implementation

2012-08-22 Thread Borislav Petkov
On Wed, Aug 22, 2012 at 07:35:12AM +0300, Jussi Kivilinna wrote: Looks that encryption lost ~0.4% while decryption gained ~1.8%. For 256 byte test, it's still slightly slower than twofish-3way (~3%). For 1k and 8k tests, it's ~5% faster. Here's very last test-patch, testing different

Re: [PATCH] crypto: twofish - add x86_64/avx assembler implementation

2012-08-23 Thread Borislav Petkov
On Wed, Aug 22, 2012 at 10:20:03PM +0300, Jussi Kivilinna wrote: Actually it does look better, at least for encryption. Decryption had different ordering for test, which appears to be bad on bulldozer as it is on sandy-bridge. So, yet another patch then :) Here you go: [ 153.736745] [

Re: [PATCH] crypto: twofish - add x86_64/avx assembler implementation

2012-08-28 Thread Borislav Petkov
On Tue, Aug 28, 2012 at 12:17:43PM +0300, Jussi Kivilinna wrote: With this patch twofish-avx is faster than twofish-3way for 256, 1k and 8k tests. sizeold-vs-new new-vs-3way old-vs-3way ecb-enc ecb-dec ecb-enc ecb-dec ecb-enc ecb-dec 256 1.10x 1.11x 1.01x

Re: randconfig build error with next-20131002, in crypto

2013-10-02 Thread Borislav Petkov
MPILIB_EXTRA thing in there. Does this totally untested but obvious patch help? --- From: Borislav Petkov b...@suse.de Date: Thu, 3 Oct 2013 01:51:15 +0200 Subject: [PATCH] crypto: Correct RSA MPI dependency 9e235dcaf4f6 (Revert crypto: GnuPG based MPI lib - additional sources (part 4)) removed the MPI lib

Re: Crypto Update for 3.13

2013-11-12 Thread Borislav Petkov
On Wed, Nov 13, 2013 at 12:41:52AM +0800, Herbert Xu wrote: Hi Linus: Here is the crypto update for 3.13: * Made x86 ablk_helper generic for ARM. * Phase out chainiv in favour of eseqiv (affects IPsec). * Fixed aes-cbc IV corruption on s390. * Added constant-time crypto_memneq which

Re: randconfig build error with next-20131223, in arch/x86/crypto/aesni-intel_avx.S

2013-12-23 Thread Borislav Petkov
On Mon, Dec 23, 2013 at 08:09:18AM -0700, Jim Davis wrote: Building with the attached random configuration file, arch/x86/crypto/aesni-intel_avx.S: Assembler messages: arch/x86/crypto/aesni-intel_avx.S:1449: Error: bad register name `%r12' [...] arch/x86/crypto/aesni-intel_avx.S:2807:

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread Borislav Petkov
On Mon, Jan 06, 2014 at 10:10:55AM -0800, Tim Chen wrote: Yes, the code is in the file named aesni_intel_avx.S. So it should be clear that the code is meant for x86_64. How do you deduce aesni_intel_avx.S is meant for x86_64 only from the name? Shouldn't it be called aesni_intel_avx-x86_64.S,

Re: [PATCH 05/28] Remove MPILIB_EXTRA

2014-04-15 Thread Borislav Petkov
On Tue, Apr 15, 2014 at 11:06:34AM +0200, Paul Bolle wrote: On Sun, 2014-02-09 at 21:18 +0100, Paul Bolle wrote: On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote: The symbol is an orphan, get rid of it. Signed-off-by: Richard Weinberger rich...@nod.at Acked-by: Paul

Re: [PATCH 05/28] Remove MPILIB_EXTRA

2014-06-18 Thread Borislav Petkov
On Wed, Jun 18, 2014 at 10:09:54AM +0200, Paul Bolle wrote: This oneliner is neither part of v3.16-rc1 nor part of linux-next. It applies cleanly to next-20140618. Should I hope that Jiri Kosina wants to take it for trivial (CC-ed)? Yeah, he will. -- Regards/Gruss, Boris. Sent from a

[PATCH] x86, crypto: Check if gas supports CRC32

2014-07-30 Thread Borislav Petkov
: no such instruction: `crc32q -i*8(%rcx),%r8' ... due to the fact that gas doesn't know the CRC32 instruction. Check that before building. Cc: linux-crypto@vger.kernel.org Signed-off-by: Borislav Petkov b...@suse.de --- So this is one possibility to address this. Code already has the ifdeffery

Re: [PATCH] x86, crypto: Check if gas supports CRC32

2014-07-30 Thread Borislav Petkov
On Wed, Jul 30, 2014 at 11:28:14PM +0200, Mathias Krause wrote: Gah, CONFIG_AS_CRC32 gets defined as a preprocessor symbol only so cannot be used in makefiles. So crc32c-pcl-intel-asm_64.S needs a #ifdef CONFIG_AS_CRC32 guard and still be compiled for CONFIG_64BIT, as it is now. It'll be an

[PATCH 07/10] x86/cpufeature: Kill cpu_has_xmm2

2016-03-29 Thread Borislav Petkov
From: Borislav Petkov <b...@suse.de> Signed-off-by: Borislav Petkov <b...@suse.de> Cc: linux-crypto@vger.kernel.org --- arch/x86/crypto/poly1305_glue.c | 2 +- arch/x86/crypto/serpent_sse2_glue.c | 2 +- arch/x86/include/asm/cpufeature.h | 1 - arch/x86/kernel/cpu/amd.c

[PATCH 03/10] x86/cpufeature: Kill cpu_has_osxsave

2016-03-29 Thread Borislav Petkov
From: Borislav Petkov <b...@suse.de> Use boot_cpu_has() instead. Signed-off-by: Borislav Petkov <b...@suse.de> Cc: linux-crypto@vger.kernel.org --- arch/x86/crypto/camellia_aesni_avx2_glue.c | 3 ++- arch/x86/crypto/camellia_aesni_avx_glue.c | 2 +- arch/x86/crypto/serpent

[PATCH 03/10] x86/cpufeature: Remove cpu_has_avx

2016-04-04 Thread Borislav Petkov
From: Borislav Petkov <b...@suse.de> Signed-off-by: Borislav Petkov <b...@suse.de> Cc: linux-crypto@vger.kernel.org --- arch/x86/crypto/aesni-intel_glue.c | 2 +- arch/x86/crypto/camellia_aesni_avx2_glue.c | 3 ++- arch/x86/crypto/camellia_aesni_avx_glue.c | 2 +- arc

[PATCH 02/10] x86/cpufeature: Remove cpu_has_aes

2016-04-04 Thread Borislav Petkov
From: Borislav Petkov <b...@suse.de> Signed-off-by: Borislav Petkov <b...@suse.de> Cc: linux-crypto@vger.kernel.org --- arch/x86/crypto/camellia_aesni_avx2_glue.c | 3 ++- arch/x86/crypto/camellia_aesni_avx_glue.c | 4 +++- arch/x86/include/asm/cpufeature.h | 1 - 3 file

[PATCH 01/10] x86/cpufeature: Remove cpu_has_avx2

2016-04-04 Thread Borislav Petkov
From: Borislav Petkov <b...@suse.de> Signed-off-by: Borislav Petkov <b...@suse.de> Cc: linux-crypto@vger.kernel.org --- arch/x86/crypto/camellia_aesni_avx2_glue.c | 2 +- arch/x86/crypto/chacha20_glue.c| 2 +- arch/x86/crypto/poly1305_glue.c| 2 +- arc

Re: [RFC PATCH v1 01/28] kvm: svm: Add support for additional SVM NPF error codes

2016-09-13 Thread Borislav Petkov
sted virtualization is used. > > Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> > --- > arch/x86/include/asm/kvm_host.h | 11 ++- > arch/x86/kvm/mmu.c | 20 ++-- > arch/x86/kvm/svm.c |2 +- > 3 files changed,

Re: [RFC PATCH v1 02/28] kvm: svm: Add kvm_fast_pio_in support

2016-09-21 Thread Borislav Petkov
m Lendacky <thomas.lenda...@amd.com> > --- > arch/x86/include/asm/kvm_host.h |1 + > arch/x86/kvm/svm.c |5 +++-- > arch/x86/kvm/x86.c | 43 > +++ > 3 files changed, 47 insertions(+), 2 deletions(-)

Re: [RFC PATCH v1 03/28] kvm: svm: Use the hardware provided GPA instead of page walk

2016-09-21 Thread Borislav Petkov
|2 ++ > arch/x86/kvm/x86.c | 17 - > 4 files changed, 24 insertions(+), 1 deletion(-) FWIW, LGTM. (Gotta love replying in acronyms :-)) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, J

Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active

2016-09-22 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 07:25:25PM -0400, Brijesh Singh wrote: > From: Tom Lendacky > > EFI data is encrypted when the kernel is run under SEV. Update the > page table references to be sure the EFI memory areas are accessed > encrypted. > > Signed-off-by: Tom Lendacky

Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active

2016-09-22 Thread Borislav Petkov
On Thu, Sep 22, 2016 at 08:23:36PM +0200, Paolo Bonzini wrote: > Unless this is part of some spec, it's easier if things are the same in > SME and SEV. Yeah, I was pondering over how sprinkling sev_active checks might not be so clean. I'm wondering if we could make the EFI regions presented to

Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active

2016-09-22 Thread Borislav Petkov
On Thu, Sep 22, 2016 at 04:45:51PM +0200, Paolo Bonzini wrote: > The main difference between the SME and SEV encryption, from the point > of view of the kernel, is that real-mode always writes unencrypted in > SME and always writes encrypted in SEV. But UEFI can run in 64-bit mode > and learn

Re: [RFC PATCH v1 04/28] x86: Secure Encrypted Virtualization (SEV) support

2016-09-22 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 07:24:19PM -0400, Brijesh Singh wrote: > From: Tom Lendacky Subject: [RFC PATCH v1 04/28] x86: Secure Encrypted Virtualization (SEV) support Please start patch commit heading with a verb, i.e.: "x86: Add AMD Secure Encrypted Virtualization (SEV)

Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active

2016-09-22 Thread Borislav Petkov
On Thu, Sep 22, 2016 at 02:49:22PM -0500, Tom Lendacky wrote: > > I thought that reduction is the reservation of bits for the SME mask. > > > > What other reduction is there? > > There is a reduction in physical address space for the SME mask and the > bits used to aid in identifying the ASID

Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active

2016-09-22 Thread Borislav Petkov
On Thu, Sep 22, 2016 at 05:05:54PM +0200, Paolo Bonzini wrote: > Which paragraph? "Linux relies on BIOS to set this bit if BIOS has determined that the reduction in the physical address space as a result of enabling memory encryption..." Basically, you can enable SME in the BIOS and you're all

Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active

2016-09-22 Thread Borislav Petkov
On Thu, Sep 22, 2016 at 07:08:50PM +0200, Paolo Bonzini wrote: > That's not how I read it. I just figured that the BIOS has some magic > things high in the physical address space and if you reduce the physical > address space the BIOS (which is called from e.g. EFI runtime services) > would have

Re: [RFC PATCH v2 15/32] x86: Add support for changing memory encryption attribute in early boot

2017-03-24 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:15:28AM -0500, Brijesh Singh wrote: > Some KVM-specific custom MSRs shares the guest physical address with > hypervisor. When SEV is active, the shared physical address must be mapped > with encryption attribute cleared so that both hypervsior and guest can > access the

Re: [RFC PATCH v2 18/32] kvm: svm: Use the hardware provided GPA instead of page walk

2017-03-29 Thread Borislav Petkov
we won't know > which memory address was translated into EXITINFO2. > > Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> > Reviewed-by: Borislav Petkov <b...@suse.de> I think I already asked you to remove Revewed-by tags when you have to change an already reviewed

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

2017-03-29 Thread Borislav Petkov
On Wed, Mar 29, 2017 at 05:21:13PM +0200, Paolo Bonzini wrote: > The GHCB would have to be allocated much earlier, possibly even by > firmware depending on how things will be designed. How about a statically allocated page like we do with the early pagetable pages in head_64.S? > I think it's

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

2017-03-28 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:15:36AM -0500, 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

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

2017-03-16 Thread Borislav Petkov
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

2017-03-16 Thread Borislav Petkov
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: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

2017-03-16 Thread Borislav Petkov
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: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

2017-03-17 Thread Borislav Petkov
On Fri, Mar 17, 2017 at 07:47:33PM +0100, Dmitry Vyukov wrote: > This problem is more general and is not specific to clang. It equally > applies to different versions of gcc, different arches and different > configs (namely, anything else than what a developer used for > testing). I guess. We do

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

2017-03-16 Thread Borislav Petkov
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: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

2017-03-09 Thread 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

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

2017-03-09 Thread 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

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

2017-03-03 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Update the CPU features to include identifying and reporting on the > Secure Encrypted Virtualization (SEV) feature. SME is identified by > CPUID 0x801f, but requires BIOS

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

2017-03-03 Thread Borislav Petkov
On Fri, Mar 03, 2017 at 02:33:23PM -0600, Bjorn Helgaas wrote: > On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: > > This RFC series provides support for AMD's new Secure Encrypted > > Virtualization > > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 >

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

2017-03-04 Thread Borislav Petkov
On Fri, Mar 03, 2017 at 03:01:23PM -0600, Brijesh Singh wrote: > +merely enables SME (sets bit 23 of the MSR_K8_SYSCFG), then Linux can > activate > +memory encryption by default (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y) > or > +by supplying mem_encrypt=on on the kernel command line. However,

Re: [RFC PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support

2017-03-08 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Provide support for Secure Encyrpted Virtualization (SEV). This initial > support defines a flag that is used by the kernel to determine if it is > running with SEV active. > >

Re: [RFC PATCH v2 10/32] x86: DMA support for SEV memory encryption

2017-03-08 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:14:25AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > DMA access to memory mapped as encrypted while SEV is active can not be > encrypted during device write or decrypted during device read. In order > for DMA to properly work when SEV

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

2017-03-09 Thread 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

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

2017-03-10 Thread Borislav Petkov
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

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

2017-03-06 Thread Borislav Petkov
On Mon, Mar 06, 2017 at 01:11:03PM -0500, Brijesh Singh wrote: > Sending it through stg mail to avoid line wrapping. Please let me know if > something > is still messed up. I have tried applying it and it seems to apply okay. Yep, thanks. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF:

Re: [RFC PATCH v2 04/32] KVM: SVM: Add SEV feature definitions to KVM

2017-03-06 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:12:48AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Define a new KVM CPU feature for Secure Encrypted Virtualization (SEV). > The kernel will check for the presence of this feature to determine if > it is running with SEV active. > >

Re: [RFC PATCH v2 07/32] x86/efi: Access EFI data as encrypted when SEV is active

2017-03-07 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:13:21AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > EFI data is encrypted when the kernel is run under SEV. Update the > page table references to be sure the EFI memory areas are accessed > encrypted. > > Signed-off-by: Tom Lendacky

Re: [RFC PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support

2017-03-07 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Provide support for Secure Encyrpted Virtualization (SEV). This initial > support defines a flag that is used by the kernel to determine if it is > running with SEV active. > >

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

2017-03-07 Thread Borislav Petkov
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 as > such when mapped. Update the

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

2017-03-07 Thread Borislav Petkov
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 protection. > This will insure that memory

Re: [RFC PATCH v2 09/32] x86: Change early_ioremap to early_memremap for BOOT data

2017-03-08 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:13:53AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > In order to map BOOT data with the proper encryption bit, the Btw, what does that all-caps spelling "BOOT" denote? Something I'm missing? > early_ioremap() function calls are

Re: [Part2 PATCH v5 12/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-06 Thread Borislav Petkov
space IOCTL to manage the platform certificates." > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: "Radim Krčmář" <rkrc...@redhat.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Herbert Xu <herb...@gondor.apana.org.au> > Cc: Gary Hook <

Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-08 Thread Borislav Petkov
On Sun, Oct 08, 2017 at 08:30:47AM -0500, Brijesh Singh wrote: > During the device probe, sev_ops_init() will be called for every device > instance which claims to support the SEV.  One of the device will be > 'master' but we don't the master until we probe all the instances. Hence > the probe for

Re: [Part2 Patch v4.2] crypto: ccp: Add Platform Security Processor (PSP) device support

2017-10-04 Thread Borislav Petkov
On Wed, Oct 04, 2017 at 12:06:42PM +0530, P J P wrote: > Needs to kfree(sp->psp_data) before setting to NULL. Not if it is allocated with devm_kzalloc(). -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

Re: [Part2 PATCH v4.1 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-04 Thread Borislav Petkov
On Wed, Oct 04, 2017 at 03:24:36PM +0530, P J P wrote: > It appears to cross 80 columns limit, checkpatch.pl throws warnings. Adding > new line would be consistent with coding style. The 80 cols rule is not a hard one and checkpatch should not override common sense. This is a function which maps

Re: [Part2 PATCH v4.1 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-04 Thread Borislav Petkov
On Wed, Oct 04, 2017 at 12:26:11PM +0530, P J P wrote: > Each return above needs to be on its own line. ... because? -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-09 Thread Borislav Petkov
On Sun, Oct 08, 2017 at 07:11:04PM -0500, Brijesh Singh wrote: > There is a single security processor driver (ccp) which provides the > complete functionality including PSP.  But the driver should be able to > work with multiple devices. e.g In my 2P EPYC configuration, security > processor driver

Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-10 Thread Borislav Petkov
On Tue, Oct 10, 2017 at 01:43:22PM -0500, Tom Lendacky wrote: > Maybe for the very first implementation we could do that and that was what > was originally done for the CCP. But as you can see the CCP does not have > a set register offset between various iterations of the device and it can > be

Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command

2017-10-13 Thread Borislav Petkov
On Thu, Oct 12, 2017 at 11:13:44PM -0500, Brijesh Singh wrote: > As per the spec, its perfectly legal to pass input.address = 0x0 and > input.length = 0x0. If userspace wants to query CSR length then it will > fill all the fields with. In response, FW will return error > (LENGTH_TO_SMALL) and

Re: [Part2 PATCH v5.1 12.9/31] crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command

2017-10-13 Thread Borislav Petkov
quot; <rkrc...@redhat.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Herbert Xu <herb...@gondor.apana.org.au> > Cc: Gary Hook <gary.h...@amd.com> > Cc: Tom Lendacky <thomas.lenda...@amd.com> > Cc: linux-crypto@vger.kernel.org > Cc: k...@vger.kernel.or

Re: [Part2 PATCH v5.1 12.8/31] crypto: ccp: Implement SEV_PEK_CERT_IMPORT ioctl command

2017-10-13 Thread Borislav Petkov
On Fri, Oct 06, 2017 at 08:06:06PM -0500, Brijesh Singh wrote: > The SEV_PEK_CERT_IMPORT command can be used to import the signed PEK > certificate. The command is defined in SEV spec section 5.8. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: "Radim Krčmář" <

Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command

2017-10-13 Thread Borislav Petkov
On Thu, Oct 12, 2017 at 09:24:01PM -0500, Brijesh Singh wrote: > I assume you mean performing the SEV state check before allocating the > memory for the CSR blob, right ? I mean, do those first: if (copy_from_user(, (void __user *)argp->data, sizeof(input))) return

Re: [RFC Part2 PATCH v3 02/26] crypto: ccp: Add Platform Security Processor (PSP) device support

2017-09-08 Thread Borislav Petkov
On Thu, Sep 07, 2017 at 05:19:32PM -0500, Brijesh Singh wrote: > At high level, AMD-SP (AMD Secure Processor) (i.e CCP driver) will provide the > support for CCP, SEV and TEE FW commands. > > > +--- CCP > | > AMD-SP --| > |+--- SEV > ||

Re: [RFC Part2 PATCH v3 02/26] crypto: ccp: Add Platform Security Processor (PSP) device support

2017-09-08 Thread Borislav Petkov
On Thu, Sep 07, 2017 at 06:15:55PM -0500, Gary R Hook wrote: > I would prefer that we not shorten this. The prior incarnation, > ccp_alloc_struct(), has/had been around for a while. And there are a > number of similarly named allocation functions in the driver that we > like to keep sorted. If

Re: [RFC Part2 PATCH v3 02/26] crypto: ccp: Add Platform Security Processor (PSP) device support

2017-09-07 Thread Borislav Petkov
On Wed, Sep 06, 2017 at 04:26:52PM -0500, Gary R Hook wrote: > They were included in a pull request (for 4.14) from Herbert, dated Monday. Right. I rebased the SEV pile ontop of latest upstream and now it applies much better: checking file drivers/crypto/ccp/Kconfig Hunk #1 succeeded at 32

Re: [RFC Part2 PATCH v3 02/26] crypto: ccp: Add Platform Security Processor (PSP) device support

2017-09-06 Thread Borislav Petkov
On Wed, Sep 06, 2017 at 03:38:38PM -0500, Brijesh Singh wrote: > This bit of my struggle -- tip/master is not in sync with cryptodev-2.6 [1]. Aaha. > In order to expand the CCP driver we need the following commits from the > cryptodev-2.6 > > 57de3aefb73f crypto: ccp - remove ccp_present()

Re: [RFC Part2 PATCH v3 03/26] crypto: ccp: Add Secure Encrypted Virtualization (SEV) device support

2017-09-13 Thread Borislav Petkov
On Mon, Jul 24, 2017 at 03:02:40PM -0500, Brijesh Singh wrote: > AMDs new Secure Encrypted Virtualization (SEV) feature allows the memory > contents of a virtual machine to be transparently encrypted with a key > unique to the guest VM. The programming and management of the encryption > keys are

Re: [RFC Part2 PATCH v3 02/26] crypto: ccp: Add Platform Security Processor (PSP) device support

2017-09-06 Thread Borislav Petkov
On Mon, Jul 24, 2017 at 03:02:39PM -0500, Brijesh Singh wrote: > Platform Security Processor (PSP) is part of AMD Secure Processor (AMD-SP), > PSP is a dedicated processor that provides the support for key management > commands in a Secure Encrypted Virtualiztion (SEV) mode, along with >

Re: [RFC Part2 PATCH v3 03/26] crypto: ccp: Add Secure Encrypted Virtualization (SEV) device support

2017-09-12 Thread Borislav Petkov
Just a cursory review: more indepth after the redesign. On Mon, Jul 24, 2017 at 03:02:40PM -0500, Brijesh Singh wrote: > AMDs new Secure Encrypted Virtualization (SEV) feature allows the memory > contents of a virtual machine to be transparently encrypted with a key > unique to the guest VM. The

Re: [RFC Part2 PATCH v3 03/26] crypto: ccp: Add Secure Encrypted Virtualization (SEV) device support

2017-09-12 Thread Borislav Petkov
On Tue, Sep 12, 2017 at 10:32:13AM -0500, Brijesh Singh wrote: > The debug statement is very helpful during development, it gives me the full > view of what command we send to PSP, data dump of command buffer before and > after the request completion. e.g when dyndbg is enabled the output looks

Re: [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support

2017-09-30 Thread Borislav Petkov
On Sat, Sep 30, 2017 at 10:55:25AM -0500, Brijesh Singh wrote: > CRYPTO_DEV_CCP_DD is supported on aarch64 and x86. Whereas the PSP > interface I am adding is available on x86 only hence its safe to add add > depend on CPU_SUP_AMD for CRYPTO_DEV_SP_PSP. I think just from having CRYPTO_DEV_CCP_DD

Re: [PATCH] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support

2017-09-30 Thread Borislav Petkov
On Sat, Sep 30, 2017 at 09:06:26AM -0500, Brijesh Singh wrote: > > diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig > > index 627f3e61dcac..f58a6521270b 100644 > > --- a/drivers/crypto/ccp/Kconfig > > +++ b/drivers/crypto/ccp/Kconfig > > @@ -1,5 +1,6 @@ > > config

[PATCH] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support

2017-09-30 Thread Borislav Petkov
Hi, just a small Kconfig correction. Feel free to add it to your patchset. Thx. --- From: Borislav Petkov <b...@suse.de> This is AMD-specific hardware so present it in Kconfig only when AMD CPU support is enabled. Signed-off-by: Borislav Petkov <b...@suse.de> Cc: Brijesh Singh

Re: [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support

2017-09-29 Thread Borislav Petkov
offon", 3 * , 3) in my .vimrc And I'm pretty sure you can do a similar thing with other editors. > software-based Trusted Executation Environment (TEE) to enable the > third-party trusted applications. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: "Radim Krčmář&qu

Re: [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support

2017-10-03 Thread Borislav Petkov
Your patch should concentrate only on adding the PSP and its dependencies. Thx. --- From: Borislav Petkov <b...@suse.de> Date: Sat, 30 Sep 2017 10:06:27 +0200 Subject: [PATCH] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support This is AMD-specific hardware so pr

Re: [Part2 PATCH v5 09/31] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support

2017-10-04 Thread Borislav Petkov
On Wed, Oct 04, 2017 at 08:13:50AM -0500, Brijesh Singh wrote: > From: Borislav Petkov <b...@suse.de> > > This is AMD-specific hardware so present it in Kconfig only when AMD > CPU support is enabled or on ARM64 where it is also used. > > Signed-off-by: <brijesh.

Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-07 Thread Borislav Petkov
- an in-kernel API to communicate with the SEV firmware. The API can be >used by the hypervisor to create encryption context for a SEV guest. > > - a userspace IOCTL to manage the platform certificates. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: "Radim Krčmář&q

Re: [Part2 PATCH v5.1 12.2/31] crypto: ccp: Define SEV userspace ioctl and command id

2017-10-07 Thread Borislav Petkov
On Fri, Oct 06, 2017 at 08:06:00PM -0500, Brijesh Singh wrote: > Add a include file which defines the ioctl and command id used for > issuing SEV platform management specific commands. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: "Radim Krčmář" <rkrc...@re

Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command

2017-10-11 Thread Borislav Petkov
On Wed, Oct 11, 2017 at 03:45:00PM -0500, Brijesh Singh wrote: > OK, if userspace is going to pick bits apart then how about this: > > struct sev_data_status { > u8 api_major; /* Out */ > u8 api_minor; /* Out */ > u8

Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command

2017-10-11 Thread Borislav Petkov
On Wed, Oct 11, 2017 at 03:10:49PM -0500, Brijesh Singh wrote: > The current 'struct sev_data_status' matches with the firmware names and the > bit fields. Only thing I did was the fields with no name is called as > "reservedX" Ok, I see it. So what you actually wanna do is: struct

Re: [Part2 PATCH v5.1 12.3/31] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command

2017-10-11 Thread Borislav Petkov
Cc: "Radim Krčmář" <rkrc...@redhat.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Herbert Xu <herb...@gondor.apana.org.au> > Cc: Gary Hook <gary.h...@amd.com> > Cc: Tom Lendacky <thomas.lenda...@amd.com> > Cc: linux-crypto@vger.kernel.org > Cc

Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-11 Thread Borislav Petkov
On Sun, Oct 08, 2017 at 08:30:47AM -0500, Brijesh Singh wrote: > Basically we need some variable which is outside the per-device > structure so that we don't end up creating multiple /dev/sev nodes. If > needed, I think we can remove 'has_sev_fops' variable from struct > psp_device if we decide to

Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command

2017-10-11 Thread Borislav Petkov
Cc: "Radim Krčmář" <rkrc...@redhat.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Herbert Xu <herb...@gondor.apana.org.au> > Cc: Gary Hook <gary.h...@amd.com> > Cc: Tom Lendacky <thomas.lenda...@amd.com> > Cc: linux-crypto@vger.kernel

Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command

2017-10-11 Thread Borislav Petkov
On Wed, Oct 11, 2017 at 02:49:55PM -0500, Brijesh Singh wrote: > This is OK for now. But in future if FW steals another bit from reserved1 > field to expose a new flag then 'owner' name will no longer be valid. If you > don't to use bit field then we have to use some generic name instead of >

Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command

2017-10-11 Thread Borislav Petkov
On Wed, Oct 11, 2017 at 10:04:44PM +0200, Borislav Petkov wrote: > Then it is easy: > >&= GENMASK(23, 1); [1:23] range cleared, of course: &= ~GENMASK(23, 1); -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norto

Re: [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-12 Thread Borislav Petkov
- an in-kernel API to communicate with the SEV firmware. The API can be >used by the hypervisor to create encryption context for a SEV guest. > > - a userspace IOCTL to manage the platform certificates. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: "Radim Krčmář&q

Re: [Part2 PATCH v5.2 12.3/31] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command

2017-10-12 Thread Borislav Petkov
Cc: "Radim Krčmář" <rkrc...@redhat.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Herbert Xu <herb...@gondor.apana.org.au> > Cc: Gary Hook <gary.h...@amd.com> > Cc: Tom Lendacky <thomas.lenda...@amd.com> > Cc: linux-crypto@vger.kernel.o

Re: [Part2 PATCH v5.1 12.5/31] crypto: ccp: Implement SEV_PEK_GEN ioctl command

2017-10-12 Thread Borislav Petkov
On Fri, Oct 06, 2017 at 08:06:03PM -0500, Brijesh Singh wrote: > The SEV_PEK_GEN command is used to generate a new Platform Endorsement > Key (PEK). The command is defined in SEV spec section 5.6. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: "Radim Krčmář" <

Re: [Part2 PATCH v5.1 12.6/31] crypto: ccp: Implement SEV_PDH_GEN ioctl command

2017-10-12 Thread Borislav Petkov
ář" <rkrc...@redhat.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Herbert Xu <herb...@gondor.apana.org.au> > Cc: Gary Hook <gary.h...@amd.com> > Cc: Tom Lendacky <thomas.lenda...@amd.com> > Cc: linux-crypto@vger.kernel.org > Cc: k...@vger.kernel

Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command

2017-10-12 Thread Borislav Petkov
quot; <rkrc...@redhat.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Herbert Xu <herb...@gondor.apana.org.au> > Cc: Gary Hook <gary.h...@amd.com> > Cc: Tom Lendacky <thomas.lenda...@amd.com> > Cc: linux-crypto@vger.kernel.org > Cc: k...@vger.kernel.or

Re: [Part2 PATCH v5.1 12.5/31] crypto: ccp: Implement SEV_PEK_GEN ioctl command

2017-10-12 Thread Borislav Petkov
On Thu, Oct 12, 2017 at 03:11:07PM -0500, Brijesh Singh wrote: > Lets  consider this scenario > 1- platform is in uninit state, we transition it to INIT > 2- PEK_GEN command failed > 3- since we have transitioned the platform in INIT state hence we must > call the shutdown otherwise we will leave

Re: [Part2 PATCH v5.1 12.6/31] crypto: ccp: Implement SEV_PDH_GEN ioctl command

2017-10-12 Thread Borislav Petkov
On Thu, Oct 12, 2017 at 03:21:04PM -0500, Brijesh Singh wrote: > We need to follow the platform state machine logic defined in SEV spec > section 5.1.2. The PEK_GEN can not be issued when platform is in WORKING > state because the command actually re-generate the identity of the > platform itself

Re: [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-12 Thread Borislav Petkov
On Thu, Oct 12, 2017 at 04:11:18PM -0500, Brijesh Singh wrote: > The sev_exit() will be called for all the psp_device instance. we need > to set psp_misc_dev = NULL after deregistering the device. > > if (psp_misc_dev) { >   misc_deregister(psp_misc_dev); >    psp_misc_dev = NULL; Right, except

Re: [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-12 Thread Borislav Petkov
On Thu, Oct 12, 2017 at 04:52:32PM -0500, Brijesh Singh wrote: > See my above comment, I think the simplest solution is remove psp->sev_misc Ok, so far so good. But now you still need to track which is the last psp device and to call misc_deregister() only when the last device exits. Because if

  1   2   >