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 p
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
> ||
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 anyt
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
> software-b
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 (offse
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() check
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
> software-b
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 pre
ich memory address was translated into EXITINFO2.
>
> Signed-off-by: Tom Lendacky
> Reviewed-by: Borislav Petkov
I think I already asked you to remove Revewed-by tags when you have to
change an already reviewed patch in non-trivial manner. Why does this
one still have my Reviewed-by tag?
--
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
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 d
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 c
On Fri, Mar 17, 2017 at 01:32:00PM +0100, Alexander Potapenko wrote:
> > IIUC there's only a handful of VLAIS instances in LLVM code, why not
> Sorry, "kernel code", not "LLVM code".
> > just drop them for the sake of better code portability?
And what happens if someone else adds a variable thing
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 functio
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 s
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 th
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 SME
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 supp
On Thu, Mar 02, 2017 at 10:15:01AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Modify the SVM cpuid update function to indicate if Secure Encrypted
> Virtualization (SEV) is active in the guest by setting the SEV KVM CPU
> features bit. SEV is active if Secure Memory Encryption is enable
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 lo
On Thu, Mar 02, 2017 at 10:14:48AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Early in the boot process, add checks to determine if the kernel is
> running with Secure Encrypted Virtualization (SEV) active by issuing
> a CPUID instruction.
>
> During early compressed kernel booting, if
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 is active, the swiotlb boun
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.
>
> Signed-off-by: Tom Lendacky
>
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 changed to early_memremap() call
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 mapping of, e.g. ACPI tables, re
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
> Signed-off-by: Brijesh S
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.
>
> Signed-off-by: Tom Lendacky
B
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 architecture override in early_m
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.
>
> Define the SEV enable bit
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: Felix
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, i
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
> >
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 support to enable it (set bit 23
On Fri, Sep 23, 2016 at 09:33:00PM +1200, Kai Huang wrote:
> How is this even possible? The spec clearly says under SEV only in long mode
> or PAE mode guest can control whether memory is encrypted via c-bit, and in
> other modes guest will be always in encrypted mode.
I was suggesting the hypervi
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 ass
On Thu, Sep 22, 2016 at 02:04:27PM -0500, Tom Lendacky wrote:
> That's not what I mean here. If the BIOS sets the SMEE bit in the
> SYS_CFG msr then, even if the encryption bit is never used, there is
> still a reduction in physical address space.
I thought that reduction is the reservation of bi
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 th
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 p
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 se
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) support"
--
Regards/Gru
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 abou
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
> ---
> arch/x86/platform
t; 2 files changed, 6 insertions(+), 3 deletions(-)
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
t
7 -
> 4 files changed, 24 insertions(+), 1 deletion(-)
FWIW, LGTM. (Gotta love replying in acronyms :-))
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
--
To unsubscribe f
t; 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(-)
FWIW: Reviewed-by: Borislav Petkov
--
Regards/Gruss,
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/kvm_host.h | 11 ++-
> arch/x86/kvm/mmu.c | 20 ++--
> arch/x86/kvm/svm.c |2 +-
> 3 files changed, 29 insertions(+), 4 deletions(-)
FWIW: Reviewed-by: Boris
From: Borislav Petkov
Signed-off-by: Borislav Petkov
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 +-
arch/x86/crypto/serpent_avx2_glue.c| 2
From: Borislav Petkov
Signed-off-by: Borislav Petkov
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 +-
arch/x86/crypto/chacha20_glue.c| 3
From: Borislav Petkov
Signed-off-by: Borislav Petkov
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 files changed, 5 insertions(+), 3 deletions
From: Borislav Petkov
Use boot_cpu_has() instead.
Signed-off-by: Borislav Petkov
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_avx2_glue.c| 2 +-
arch/x86/include/asm
From: Borislav Petkov
Signed-off-by: Borislav Petkov
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 | 2 +-
arch/x86/kernel/cpu/intel.c
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
Error: 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
---
So this is one possibility to address this. Code already
has the ifdeffery
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
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
> >
> > Acked-by: Paul B
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,
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:
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 whi
On Wed, Oct 02, 2013 at 07:54:01PM -0700, Jim Davis wrote:
> Yes, with the change that configuration file didn't generate a build
> error. Tested-by: jim.ep...@gmail.com (if it isn't overkill for for an
> obvious patch!). Thanks.
Of course not. :)
---
From: Borislav Petk
o `mpi_free'
> make: *** [vmlinux] Error 1
Looks like someone has forgotten this completely unused MPILIB_EXTRA
thing in there.
Does this totally untested but obvious patch help?
---
From: Borislav Petkov
Date: Thu, 3 Oct 2013 01:51:15 +0200
Subject: [PATCH] crypto: Correct RSA MPI depend
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
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
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
On Fri, Aug 17, 2012 at 10:37:10AM +0300, Jussi Kivilinna wrote:
> I made few further changes, mainly moving/interleaving 'vmovq/vpextrq'
> ahead so they should be completed before those target registers are
> needed. This only gave 0.5% increase on Sandy-bridge, but might help
> more on Bulldozer.
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 encryptio
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
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-vger&m=134364845024825&w=2
>
> I'd be interested to know, if this is patch helps on Bulldozer.
Sure, can you inline it here too please. The
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 3.6
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 instr
From: Borislav Petkov
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 times unnecessarily
101 - 170 of 170 matches
Mail list logo
