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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220201203507.goibbaln6dxyoogv@amd.com>
Date:   Tue, 1 Feb 2022 14:35:07 -0600
From:   Michael Roth <michael.roth@....com>
To:     Borislav Petkov <bp@...en8.de>
CC:     Brijesh Singh <brijesh.singh@....com>, <x86@...nel.org>,
        <linux-kernel@...r.kernel.org>, <kvm@...r.kernel.org>,
        <linux-efi@...r.kernel.org>, <platform-driver-x86@...r.kernel.org>,
        <linux-coco@...ts.linux.dev>, <linux-mm@...ck.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
        Tom Lendacky <thomas.lendacky@....com>,
        "H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        "Vitaly Kuznetsov" <vkuznets@...hat.com>,
        Jim Mattson <jmattson@...gle.com>,
        "Andy Lutomirski" <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Sergio Lopez <slp@...hat.com>, Peter Gonda <pgonda@...gle.com>,
        "Peter Zijlstra" <peterz@...radead.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        David Rientjes <rientjes@...gle.com>,
        Dov Murik <dovmurik@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@....com>,
        Vlastimil Babka <vbabka@...e.cz>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Andi Kleen <ak@...ux.intel.com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        <brijesh.ksingh@...il.com>, <tony.luck@...el.com>,
        <marcorr@...gle.com>, <sathyanarayanan.kuppuswamy@...ux.intel.com>
Subject: Re: [PATCH v9 05/43] x86/compressed/64: Detect/setup SEV/SME
 features earlier in boot

On Tue, Feb 01, 2022 at 07:08:21PM +0100, Borislav Petkov wrote:
> On Fri, Jan 28, 2022 at 11:17:26AM -0600, Brijesh Singh wrote:
> > diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
> > index fd9441f40457..49064a9f96e2 100644
> > --- a/arch/x86/boot/compressed/head_64.S
> > +++ b/arch/x86/boot/compressed/head_64.S
> > @@ -191,9 +191,8 @@ SYM_FUNC_START(startup_32)
> >  	/*
> >  	 * Mark SEV as active in sev_status so that startup32_check_sev_cbit()
> >  	 * will do a check. The sev_status memory will be fully initialized
> 
> That "sev_status memory" formulation is just weird. Pls fix it while
> you're touching that comment.

Will do.

> 
> > +static inline u64 rd_sev_status_msr(void)
> > +{
> > +	unsigned long low, high;
> > +
> > +	asm volatile("rdmsr" : "=a" (low), "=d" (high) :
> > +			"c" (MSR_AMD64_SEV));
> > +
> > +	return ((high << 32) | low);
> > +}
> 
> Don't you see sev_es_rd_ghcb_msr() in that same file above? Do a common
> rdmsr() helper and call it where needed, pls, instead of duplicating
> code.

Unfortunately rdmsr()/wrmsr()/__rdmsr()/__wrmsr() etc. definitions are all
already getting pulled in via:

  misc.h:
    #include linux/elf.h
      #include linux/thread_info.h
        #include linux/cpufeature.h
          #include linux/processor.h
            #include linux/msr.h

Those definitions aren't usable in boot/compressed because of __ex_table
and possibly some other dependency hellishness.

Would read_msr()/write_msr() be reasonable alternative names for these new
helpers, or something else that better distinguishes them from the
kernel proper definitions?

> 
> misc.h looks like a good place.

It doesn't look like anything in boot/ pulls in boot/compressed/
headers. It seems to be the other way around, with boot/compressed
pulling in headers and whole C files from boot/.

So perhaps these new definitions should be added to a small boot/msr.h
header and pulled in from there?

> 
> Extra bonus points will be given if you unify callers in
> arch/x86/boot/cpucheck.c too but you don't have to - I can do that
> ontop.

I have these new helpers defined with similar signatures to
__rdmsr/__wrmsr:

  /* rdmsr/wrmsr helpers */
  static inline u64 read_msr(unsigned int msr)
  {
         u64 low, high;
  
         asm volatile("rdmsr" : "=a" (low), "=d" (high) : "c" (msr));
  
         return ((high << 32) | low);
  }
  
  static inline void write_msr(unsigned int msr, u32 low, u32 high)
  {
         asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high) : "memory");
  }

but cpucheck.c code flow really lends itself to having a read_msr()
variant that loads into 2 separate high/low u32 values, like what
native_rdmsr does:

  #define native_rdmsr(msr, val1, val2)                   \
  do {                                                    \
          u64 __val = __rdmsr((msr));                     \
          (void)((val1) = (u32)__val);                    \
          (void)((val2) = (u32)(__val >> 32));            \
  } while (0)

Should we introduce something like this as well for cpucheck.c? Or
re-write cpucheck.c to make use of the u64 versions? Or just set the
cpucheck.c rework aside for now? (but still introduce the above helpers
as boot/msr.h in preparation)?

Thanks,

Mike

> 
> Thx.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.kernel.org%2Ftglx%2Fnotes-about-netiquette&amp;data=04%7C01%7Cmichael.roth%40amd.com%7Cec7f8621a6934039cfff08d9e5addaca%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637793357136301050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=FMoP5ZskuxwanWTe5DxMnIYNPBSi%2FhRrOExp9hIHaCo%3D&amp;reserved=0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ