linux-kernel - Re: [RFC 04/14] KVM: x86/MMU: Expose functions for paging

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: <CANgfPd8uOgTTF4whwyYw_CWnBhUahAauEryVHmFAL2wZNpwR8w@mail.gmail.com>
Date:   Mon, 9 Jan 2023 10:47:10 -0800
From:   Ben Gardon <bgardon@...gle.com>
To:     David Matlack <dmatlack@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Xu <peterx@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vipin Sharma <vipinsh@...gle.com>,
        Nagareddy Reddy <nspreddy@...gle.com>
Subject: Re: [RFC 04/14] KVM: x86/MMU: Expose functions for paging_tmpl.h

On Fri, Jan 6, 2023 at 11:49 AM David Matlack <dmatlack@...gle.com> wrote:
>
> On Wed, Dec 21, 2022 at 10:24:08PM +0000, Ben Gardon wrote:
> > In preparation for moving paging_tmpl.h to shadow_mmu.c, expose various
> > functions it needs through mmu_internal.h. This includes modifying the
> > BUILD_MMU_ROLE_ACCESSOR macro so that it does not automatically include
> > the static label, since some but not all of the accessors are needed by
> > paging_tmpl.h.
> >
> > No functional change intended.
> >
> > Signed-off-by: Ben Gardon <bgardon@...gle.com>
> > ---
> >  arch/x86/kvm/mmu/mmu.c          | 32 ++++++++++++++++----------------
> >  arch/x86/kvm/mmu/mmu_internal.h | 16 ++++++++++++++++
> >  2 files changed, 32 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index bf14e181eb12..a17e8a79e4df 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -153,18 +153,18 @@ BUILD_MMU_ROLE_REGS_ACCESSOR(efer, lma, EFER_LMA);
> >   * and the vCPU may be incorrect/irrelevant.
> >   */
> >  #define BUILD_MMU_ROLE_ACCESSOR(base_or_ext, reg, name)              \
> > -static inline bool __maybe_unused is_##reg##_##name(struct kvm_mmu *mmu)     \
> > +inline bool __maybe_unused is_##reg##_##name(struct kvm_mmu *mmu)    \
> >  {                                                            \
> >       return !!(mmu->cpu_role. base_or_ext . reg##_##name);   \
> >  }
> >  BUILD_MMU_ROLE_ACCESSOR(base, cr0, wp);
> > -BUILD_MMU_ROLE_ACCESSOR(ext,  cr4, pse);
> > +static BUILD_MMU_ROLE_ACCESSOR(ext,  cr4, pse);
> >  BUILD_MMU_ROLE_ACCESSOR(ext,  cr4, smep);
> > -BUILD_MMU_ROLE_ACCESSOR(ext,  cr4, smap);
> > -BUILD_MMU_ROLE_ACCESSOR(ext,  cr4, pke);
> > -BUILD_MMU_ROLE_ACCESSOR(ext,  cr4, la57);
> > +static BUILD_MMU_ROLE_ACCESSOR(ext,  cr4, smap);
> > +static BUILD_MMU_ROLE_ACCESSOR(ext,  cr4, pke);
> > +static BUILD_MMU_ROLE_ACCESSOR(ext,  cr4, la57);
> >  BUILD_MMU_ROLE_ACCESSOR(base, efer, nx);
> > -BUILD_MMU_ROLE_ACCESSOR(ext,  efer, lma);
> > +static BUILD_MMU_ROLE_ACCESSOR(ext,  efer, lma);
>
> Suggest moving all the BUILD_MMU_ROLE*() macros to mmu_internal.h, since
> they are already static inline. That would be a cleaner patch and reduce
> future churn if shadow_mmu.c ever needs to use a different role accessor
> at some point.

That sounds reasonable. Will do in V1.

>
> >
> >  static inline bool is_cr0_pg(struct kvm_mmu *mmu)
> >  {
> > @@ -210,7 +210,7 @@ void kvm_flush_remote_tlbs_with_address(struct kvm *kvm,
> >       kvm_flush_remote_tlbs_with_range(kvm, &range);
> >  }
> >
> > -static gfn_t get_mmio_spte_gfn(u64 spte)
> > +gfn_t get_mmio_spte_gfn(u64 spte)
> >  {
> >       u64 gpa = spte & shadow_nonpresent_or_rsvd_lower_gfn_mask;
> >
> > @@ -240,7 +240,7 @@ static bool check_mmio_spte(struct kvm_vcpu *vcpu, u64 spte)
> >       return likely(kvm_gen == spte_gen);
> >  }
> >
> > -static int is_cpuid_PSE36(void)
> > +int is_cpuid_PSE36(void)
> >  {
> >       return 1;
> >  }
>
> Can we just drop is_cpuid_PSE36(), e.g. as a precursor patch? It just
> returns 1...

Yeah, good idea. Looks like we can eliminate a little dead code doing that too.