| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <59dd6291-6a99-ab7a-865f-b333a5f57bb9@amd.com>
Date: Wed, 1 Feb 2023 11:14:35 -0600
From: "Kalra, Ashish" <ashish.kalra@....com>
To: Alexander Graf <graf@...zon.com>,
Michael Roth <michael.roth@....com>, kvm@...r.kernel.org
Cc: linux-coco@...ts.linux.dev, linux-mm@...ck.org,
linux-crypto@...r.kernel.org, x86@...nel.org,
linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
jroedel@...e.de, thomas.lendacky@....com, hpa@...or.com,
ardb@...nel.org, pbonzini@...hat.com, seanjc@...gle.com,
vkuznets@...hat.com, wanpengli@...cent.com, jmattson@...gle.com,
luto@...nel.org, dave.hansen@...ux.intel.com, slp@...hat.com,
pgonda@...gle.com, peterz@...radead.org,
srinivas.pandruvada@...ux.intel.com, rientjes@...gle.com,
dovmurik@...ux.ibm.com, tobin@....com, bp@...en8.de,
vbabka@...e.cz, kirill@...temov.name, ak@...ux.intel.com,
tony.luck@...el.com, marcorr@...gle.com,
sathyanarayanan.kuppuswamy@...ux.intel.com, alpergun@...gle.com,
dgilbert@...hat.com, jarkko@...nel.org, harald@...fian.com,
Brijesh Singh <brijesh.singh@....com>,
"Rapan, Sabin" <sabrapan@...zon.com>
Subject: Re: [PATCH RFC v7 16/64] x86/sev: Add helper functions for RMPUPDATE
and PSMASH instruction
On 1/31/2023 3:26 PM, Alexander Graf wrote:
>
> On 14.12.22 20:40, Michael Roth wrote:
>> From: Brijesh Singh <brijesh.singh@....com>
>>
>> The RMPUPDATE instruction writes a new RMP entry in the RMP Table. The
>> hypervisor will use the instruction to add pages to the RMP table. See
>> APM3 for details on the instruction operations.
>>
>> The PSMASH instruction expands a 2MB RMP entry into a corresponding set
>> of contiguous 4KB-Page RMP entries. The hypervisor will use this
>> instruction to adjust the RMP entry without invalidating the previous
>> RMP entry.
>>
>> Add the following external interface API functions:
>>
>> int psmash(u64 pfn);
>> psmash is used to smash a 2MB aligned page into 4K
>> pages while preserving the Validated bit in the RMP.
>>
>> int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, int asid,
>> bool immutable);
>> Used to assign a page to guest using the RMPUPDATE instruction.
>>
>> int rmp_make_shared(u64 pfn, enum pg_level level);
>> Used to transition a page to hypervisor/shared state using the
>> RMPUPDATE instruction.
>>
>> Signed-off-by: Ashish Kalra <ashish.kalra@....com>
>> Signed-off-by: Brijesh Singh <brijesh.singh@....com>
>> [mdr: add RMPUPDATE retry logic for transient FAIL_OVERLAP errors]
>> Signed-off-by: Michael Roth <michael.roth@....com>
>> ---
>> arch/x86/include/asm/sev.h | 24 ++++++++++
>> arch/x86/kernel/sev.c | 95 ++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 119 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
>> index 8d3ce2ad27da..4eeedcaca593 100644
>> --- a/arch/x86/include/asm/sev.h
>> +++ b/arch/x86/include/asm/sev.h
>> @@ -80,10 +80,15 @@ extern bool handle_vc_boot_ghcb(struct pt_regs
>> *regs);
>>
>> /* Software defined (when rFlags.CF = 1) */
>> #define PVALIDATE_FAIL_NOUPDATE 255
>> +/* RMUPDATE detected 4K page and 2MB page overlap. */
>> +#define RMPUPDATE_FAIL_OVERLAP 7
>>
>> /* RMP page size */
>> #define RMP_PG_SIZE_4K 0
>> +#define RMP_PG_SIZE_2M 1
>> #define RMP_TO_X86_PG_LEVEL(level) (((level) == RMP_PG_SIZE_4K)
>> ? PG_LEVEL_4K : PG_LEVEL_2M)
>> +#define X86_TO_RMP_PG_LEVEL(level) (((level) == PG_LEVEL_4K) ?
>> RMP_PG_SIZE_4K : RMP_PG_SIZE_2M)
>> +
>> #define RMPADJUST_VMSA_PAGE_BIT BIT(16)
>>
>> /* SNP Guest message request */
>> @@ -133,6 +138,15 @@ struct snp_secrets_page_layout {
>> u8 rsvd3[3840];
>> } __packed;
>>
>> +struct rmp_state {
>> + u64 gpa;
>> + u8 assigned;
>> + u8 pagesize;
>> + u8 immutable;
>> + u8 rsvd;
>> + u32 asid;
>> +} __packed;
>> +
>> #ifdef CONFIG_AMD_MEM_ENCRYPT
>> extern struct static_key_false sev_es_enable_key;
>> extern void __sev_es_ist_enter(struct pt_regs *regs);
>> @@ -198,6 +212,9 @@ bool snp_init(struct boot_params *bp);
>> void __init __noreturn snp_abort(void);
>> int snp_issue_guest_request(u64 exit_code, struct snp_req_data
>> *input, unsigned long *fw_err);
>> int snp_lookup_rmpentry(u64 pfn, int *level);
>> +int psmash(u64 pfn);
>> +int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, int asid,
>> bool immutable);
>> +int rmp_make_shared(u64 pfn, enum pg_level level);
>> #else
>> static inline void sev_es_ist_enter(struct pt_regs *regs) { }
>> static inline void sev_es_ist_exit(void) { }
>> @@ -223,6 +240,13 @@ static inline int snp_issue_guest_request(u64
>> exit_code, struct snp_req_data *in
>> return -ENOTTY;
>> }
>> static inline int snp_lookup_rmpentry(u64 pfn, int *level) { return
>> 0; }
>> +static inline int psmash(u64 pfn) { return -ENXIO; }
>> +static inline int rmp_make_private(u64 pfn, u64 gpa, enum pg_level
>> level, int asid,
>> + bool immutable)
>> +{
>> + return -ENODEV;
>> +}
>> +static inline int rmp_make_shared(u64 pfn, enum pg_level level) {
>> return -ENODEV; }
>> #endif
>>
>> #endif
>> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
>> index 706675561f49..67035d34adad 100644
>> --- a/arch/x86/kernel/sev.c
>> +++ b/arch/x86/kernel/sev.c
>> @@ -2523,3 +2523,98 @@ int snp_lookup_rmpentry(u64 pfn, int *level)
>> return !!rmpentry_assigned(e);
>> }
>> EXPORT_SYMBOL_GPL(snp_lookup_rmpentry);
>> +
>> +/*
>> + * psmash is used to smash a 2MB aligned page into 4K
>> + * pages while preserving the Validated bit in the RMP.
>> + */
>> +int psmash(u64 pfn)
>> +{
>> + unsigned long paddr = pfn << PAGE_SHIFT;
>> + int ret;
>> +
>> + if (!pfn_valid(pfn))
>> + return -EINVAL;
>
>
> We (and many other clouds) use a neat trick to reduce the number of
> struct pages Linux allocates for guest memory: In its simplest form, add
> mem= to the kernel cmdline and mmap() /dev/mem to access the reserved
> memory instead.
>
> This means that the system covers more RAM than Linux contains, which
> means pfn_valid() is no longer a good indication whether a page is
> indeed valid. KVM handles this case fine, but this code does not.
Hmm...but then is also using max_pfn reliable ?
>
> Is there any particular reason why we need this check (and similar ones
> below and in other RMP related patches) in the first place. I would > expect that PSMASH and friends return failure codes for invalid pfns.
>
Yes, PSMASH does out of bounds check on the input SPA and additionally
checks if SPA is 2M aligned, so guess we can rely on using PSMASH
failing on invalid pfns.
Thanks,
Ashish
Powered by blists - more mailing lists