On 4/19/21 11:10 AM, Andy Lutomirski wrote:
> I’m confused by this scenario. This should only affect physical pages
> that are in the 2M area that contains guest memory. But, if we have a
> 2M direct map PMD entry that contains kernel data and guest private
> memory, we’re already in a situation in
On 4/19/21 10:46 AM, Brijesh Singh wrote:
> - guest wants to make gpa 0x1000 as a shared page. To support this, we
> need to psmash the large RMP entry into 512 4K entries. The psmash
> instruction breaks the large RMP entry into 512 4K entries without
> affecting the previous validation. Now the w
On 3/25/21 8:24 AM, Brijesh Singh wrote:
> On 3/25/21 9:48 AM, Dave Hansen wrote:
>> On 3/24/21 10:04 AM, Brijesh Singh wrote:
>>> When SEV-SNP is enabled globally in the system, a write from the hypervisor
>>> can raise an RMP violation. We can resolve the RMP vio
On 3/25/21 8:31 AM, Brijesh Singh wrote:
>
> On 3/25/21 9:58 AM, Dave Hansen wrote:
>>> +static int __init mem_encrypt_snp_init(void)
>>> +{
>>> + if (!boot_cpu_has(X86_FEATURE_SEV_SNP))
>>> + return 1;
>>> +
>>> +
On 3/24/21 10:04 AM, Brijesh Singh wrote:
> The spliting of the physmap is a temporary solution until we work to
> improve the kernel page fault handler to split the pages on demand.
> One of the disadvtange of splitting is that eventually, we will end up
> breaking down the entire physmap unless w
> +static int __init mem_encrypt_snp_init(void)
> +{
> + if (!boot_cpu_has(X86_FEATURE_SEV_SNP))
> + return 1;
> +
> + if (rmptable_init()) {
> + setup_clear_cpu_cap(X86_FEATURE_SEV_SNP);
> + return 1;
> + }
> +
> + static_branch_enable(&snp_enabl
On 3/24/21 10:04 AM, Brijesh Singh wrote:
> When SEV-SNP is enabled globally in the system, a write from the hypervisor
> can raise an RMP violation. We can resolve the RMP violation by splitting
> the virtual address to a lower page level.
>
> e.g
> - guest made a page shared in the RMP entry so
On 3/25/21 7:32 AM, Brijesh Singh wrote:
>>> enum x86_pf_error_code {
>>> X86_PF_PROT = 1 << 0,
>>> @@ -21,6 +22,7 @@ enum x86_pf_error_code {
>>> X86_PF_INSTR= 1 << 4,
>>> X86_PF_PK = 1 << 5,
>>> X86_PF_SGX =
On 3/24/21 10:04 AM, Brijesh Singh wrote:
> @@ -1377,6 +1442,22 @@ void do_user_addr_fault(struct pt_regs *regs,
> if (hw_error_code & X86_PF_INSTR)
> flags |= FAULT_FLAG_INSTRUCTION;
>
> + /*
> + * If its an RMP violation, see if we can resolve it.
> + */
> +
> diff --git a/arch/x86/include/asm/trap_pf.h b/arch/x86/include/asm/trap_pf.h
> index 10b1de500ab1..107f9d947e8d 100644
> --- a/arch/x86/include/asm/trap_pf.h
> +++ b/arch/x86/include/asm/trap_pf.h
> @@ -12,6 +12,7 @@
> * bit 4 ==1: fault was an instruction
> f
On 1/22/21 11:28 PM, Megha Dey wrote:
> Other implementations of these crypto algorithms are possible, which would
> result in lower crypto performance but would not cause collateral damage
> from frequency drops (AVX512L vs AVX512VL).
I don't think you told us anywhere what AVX512L and AVX512VL a
On 1/15/21 6:04 PM, Eric Biggers wrote:
> On Fri, Jan 15, 2021 at 04:20:44PM -0800, Dave Hansen wrote:
>> On 1/15/21 4:14 PM, Dey, Megha wrote:
>>> Also, I do not know of any cores that implement PCLMULQDQ and not AES-NI.
>> That's true, bit it's also possible
On 1/15/21 4:14 PM, Dey, Megha wrote:
> Also, I do not know of any cores that implement PCLMULQDQ and not AES-NI.
That's true, bit it's also possible that a hypervisor could enumerate
support for PCLMULQDQ and not AES-NI. In general, we've tried to
implement x86 CPU features independently, even i
On 1/6/21 10:19 PM, Tony W Wang-oc wrote:
> + /*
> + * These CPUs declare support SSE4.2 instruction sets but
> + * having low performance CRC32C instruction implementation.
> + */
> + if (c->x86 == 0x6 || (c->x86 == 0x7 && c->x86_model <= 0x3b))
> + set_cpu_cap(c
On 12/16/20 9:41 AM, Chang S. Bae wrote:
> +config CRYPTO_AES_KL
> + tristate "AES cipher algorithms (AES-KL)"
> + depends on X86_KEYLOCKER
> + select CRYPTO_AES_NI_INTEL
> + help
> + Use AES Key Locker instructions for AES algorithm.
> +
> + AES cipher algorithms (FIPS-
On 12/10/18 3:12 PM, Josh Triplett wrote:
>> Or maybe even python/shell scripts? It looked to me like virtual
>> memory will be "interesting" for enclaves.
> Memory management doesn't seem that hard to deal with.
The problems are:
1. SGX enclave memory (EPC) is statically allocated at boot and ca
with a similar fix. I also added
some sse2/avx/avx2_usable() functions that save a lot of this repetitive
copy/paste. I need to clean those up and submit them (part of the
series is attached).
Feel free to add my acked-by on this though. It looks good to me.
From: Dave Hansen
camellia_aesni_a
On 07/02/2014 11:40 AM, Dmitry Kasatkin wrote:
>> > We should reserve command-line parameters for things that really need
>> > tweaking in early boot or are _needed_ to boot.
...
> Is module param good enough or it should be sysctl?
Doesn't matter to me much. sysctls seem to be the easiest things
On 07/01/2014 01:12 PM, Dmitry Kasatkin wrote:
> + ima_ahash= [IMA] Asynchronous hash usage parameters
> + Format:
> + Set the minimal file size when use asynchronous hash.
> + If ima_ahash is not provided, ahash usage is disable
19 matches
Mail list logo
