| 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: <BYAPR21MB16886D446C3AC972AFF8DAB9D7F29@BYAPR21MB1688.namprd21.prod.outlook.com>
Date: Wed, 28 Dec 2022 19:15:31 +0000
From: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To: Tianyu Lan <ltykernel@...il.com>, Borislav Petkov <bp@...en8.de>
CC: "luto@...nel.org" <luto@...nel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"seanjc@...gle.com" <seanjc@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"jgross@...e.com" <jgross@...e.com>,
Tianyu Lan <Tianyu.Lan@...rosoft.com>,
"kirill@...temov.name" <kirill@...temov.name>,
"jiangshan.ljs@...group.com" <jiangshan.ljs@...group.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"ashish.kalra@....com" <ashish.kalra@....com>,
"srutherford@...gle.com" <srutherford@...gle.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"anshuman.khandual@....com" <anshuman.khandual@....com>,
"pawan.kumar.gupta@...ux.intel.com"
<pawan.kumar.gupta@...ux.intel.com>,
"adrian.hunter@...el.com" <adrian.hunter@...el.com>,
"daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
"alexander.shishkin@...ux.intel.com"
<alexander.shishkin@...ux.intel.com>,
"sandipan.das@....com" <sandipan.das@....com>,
"ray.huang@....com" <ray.huang@....com>,
"brijesh.singh@....com" <brijesh.singh@....com>,
"michael.roth@....com" <michael.roth@....com>,
"thomas.lendacky@....com" <thomas.lendacky@....com>,
"venu.busireddy@...cle.com" <venu.busireddy@...cle.com>,
"sterritt@...gle.com" <sterritt@...gle.com>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"samitolvanen@...gle.com" <samitolvanen@...gle.com>,
"fenghua.yu@...el.com" <fenghua.yu@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: RE: [RFC PATCH V2 01/18] x86/sev: Pvalidate memory gab for
decompressing kernel
From: Tianyu Lan <ltykernel@...il.com> Sent: Tuesday, November 29, 2022 6:43 AM
>
> On 11/29/2022 8:56 PM, Borislav Petkov wrote:
> >> +/* Check SEV-SNP via MSR */
> >> +static bool sev_snp_runtime_check(void)
> > Functions need to have a verb in the name.
> >
> >> +{
> >> + unsigned long low, high;
> >> + u64 val;
> >> +
> >> + asm volatile("rdmsr\n" : "=a" (low), "=d" (high) :
> >> + "c" (MSR_AMD64_SEV));
> >> +
> >> + val = (high << 32) | low;
> >> + if (val & MSR_AMD64_SEV_SNP_ENABLED)
> >> + return true;
> > There already is a sev_snp_enabled() in that very same file. Did you not
> > see it?
> >
> > Why are you even adding such a function?!
>
> Hi Boris:
> Thanks for your review. sev_snp_enabled() is used after
> sev_status was initialized in sev_enable() while pvalidate_for_startup_
> 64() is called before sev_enable(). So add sev_snp_runtime_check() to
> check sev snp capability before calling sev_enable().
I understand needing to find out if SEV-SNP is enabled before sev_enable()
has set the value of sev_status. Unfortunately, just checking the
SEV_SNP_ENABLED bit in MSR_AMD64_SEV isn't sufficient. sev_enable()
correctly does a more complex check. The CPUID bit is checked first, and
the MSR is read only if the CPUID bit indicating SEV is set. The reason for
this behavior is described in the commit message for 009767dbf42a.
Furthermore, even if the MSR is safe to read, just checking the
SEV_SNP_ENABLED bit isn't sufficient because that bit is "1" in a vTOM VM.
The MSR check would need to be that SEV_SNP_ENABLED is set, and
VTOM_ENABLED is not set.
Michael
>
> >
> >> + return false;
> >> +}
> >> +
> >> static inline bool sev_snp_enabled(void)
> >> {
> >> return sev_status & MSR_AMD64_SEV_SNP_ENABLED;
> >> @@ -456,3 +475,68 @@ void sev_prep_identity_maps(unsigned long top_level_pgt)
> >>
> >> sev_verify_cbit(top_level_pgt);
> >> }
> >> +
> >> +static void extend_e820_on_demand(struct boot_e820_entry *e820_entry,
> >> + u64 needed_ram_end)
> >> +{
> >> + u64 end, paddr;
> >> + unsigned long eflags;
> >> + int rc;
> >> +
> >> + if (!e820_entry)
> >> + return;
> >> +
> >> + /* Validated memory must be aligned by PAGE_SIZE. */
> >> + end = ALIGN(e820_entry->addr + e820_entry->size, PAGE_SIZE);
> >> + if (needed_ram_end > end && e820_entry->type == E820_TYPE_RAM) {
> >> + for (paddr = end; paddr < needed_ram_end; paddr += PAGE_SIZE) {
> >> + rc = pvalidate(paddr, RMP_PG_SIZE_4K, true);
> >> + if (rc) {
> >> + error("Failed to validate address.n");
> >> + return;
> >> + }
> >> + }
> >> + e820_entry->size = needed_ram_end - e820_entry->addr;
> >> + }
> >> +}
> >> +
> >> +/*
> >> + * Explicitly pvalidate needed pages for decompressing the kernel.
> >> + * The E820_TYPE_RAM entry includes only validated memory. The kernel
> >> + * expects that the RAM entry's addr is fixed while the entry size is to be
> >> + * extended to cover addresses to the start of next entry.
> >> + * The function increases the RAM entry size to cover all possible memory
> > Similar issue as above: you don't need to say "this function" above this
> > function. IOW, it should say:
> >
> > "Increase the RAM entry size..."
> >
> > I.e., imperative mood above.
> >
> >> + * addresses until init_size.
> >> + * For example, init_end = 0x4000000,
> >> + * [RAM: 0x0 - 0x0], M[RAM: 0x0 - 0xa0000]
> >> + * [RSVD: 0xa0000 - 0x10000] [RSVD: 0xa0000 - 0x10000]
> >> + * [ACPI: 0x10000 - 0x20000] ==> [ACPI: 0x10000 - 0x20000]
> >> + * [RSVD: 0x800000 - 0x900000] [RSVD: 0x800000 - 0x900000]
> >> + * [RAM: 0x1000000 - 0x2000000] M[RAM: 0x1000000 - 0x2001000]
> >> + * [RAM: 0x2001000 - 0x2007000] M[RAM: 0x2001000 - 0x4000000]
> > What is this trying to tell me?
> >
> > That the end range 0x2007000 gets raised to 0x4000000?
> >
> > Why?
> >
> > This all sounds like there is some requirement somewhere but nothing
> > says what that requirement is and why.
> >
> >> + * Other RAM memory after init_end is pvalidated by ms_hyperv_init_platform
> >> + */
> >> +__visible void pvalidate_for_startup_64(struct boot_params *boot_params)
> > This doesn't do any validation. And yet it has "pvalidate" in the name.
> >
> >> +{
> >> + struct boot_e820_entry *e820_entry;
> >> + u64 init_end =
> >> + boot_params->hdr.pref_address + boot_params->hdr.init_size;
> > Nope, we never break lines like that.
> >
> >> + u8 i, nr_entries = boot_params->e820_entries;
> >> + u64 needed_end;
> > The tip-tree preferred ordering of variable declarations at the
> > beginning of a function is reverse fir tree order::
> >
> > struct long_struct_name *descriptive_name;
> > unsigned long foo, bar;
> > unsigned int tmp;
> > int ret;
> >
> > The above is faster to parse than the reverse ordering::
> >
> > int ret;
> > unsigned int tmp;
> > unsigned long foo, bar;
> > struct long_struct_name *descriptive_name;
> >
> > And even more so than random ordering::
> >
> > unsigned long foo, bar;
> > int ret;
> > struct long_struct_name *descriptive_name;
> > unsigned int tmp;
> >
> >> + if (!sev_snp_runtime_check())
> >> + return;
> >> +
> >> + for (i = 0; i < nr_entries; ++i) {
> >> + /* Pvalidate memory holes in e820 RAM entries. */
> >> + e820_entry = &boot_params->e820_table[i];
> >> + if (i < nr_entries - 1) {
> >> + needed_end = boot_params->e820_table[i + 1].addr;
> >> + if (needed_end < e820_entry->addr)
> >> + error("e820 table is not sorted.\n");
> >> + } else {
> >> + needed_end = init_end;
> >> + }
> >> + extend_e820_on_demand(e820_entry, needed_end);
> > Now*this* function does call pvalidate() and yet it doesn't have
> > "pvalidate" in the name. This all looks real confused.
> >
> > So first of all, you need to explain*why* you're doing this.
> >
> > It looks like it is because the guest needs to do the memory validation
> > by itself because nobody else does that.
> >
> > If so, this needs to be explained in detail in the commit message.
>
> Yes, I will update in the next version. Thanks for suggestion.
>
> >
> > Also, why is that ok for SNP guests on other hypervisors which get the
> > memory validated by the boot loader or firmware?
>
> This is for Linux direct boot mode and so it needs to do such check
> here. Will fix this in the next version.
Powered by blists - more mailing lists