linux-kernel - Re: [PATCH v2 19/27] KVM: x86/mmu: Move KVM-only page-track declarations to internal header

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: <ZBLfNLb5z2EYdeXy@yzhao56-desk.sh.intel.com>
Date:   Thu, 16 Mar 2023 17:19:48 +0800
From:   Yan Zhao <yan.y.zhao@...el.com>
To:     Sean Christopherson <seanjc@...gle.com>
CC:     Paolo Bonzini <pbonzini@...hat.com>,
        Zhenyu Wang <zhenyuw@...ux.intel.com>,
        Zhi Wang <zhi.a.wang@...el.com>, <kvm@...r.kernel.org>,
        <intel-gvt-dev@...ts.freedesktop.org>,
        <intel-gfx@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>,
        Ben Gardon <bgardon@...gle.com>
Subject: Re: [PATCH v2 19/27] KVM: x86/mmu: Move KVM-only page-track
 declarations to internal header

On Wed, Mar 15, 2023 at 08:13:37AM -0700, Sean Christopherson wrote:
> > A curious question:
> > are arch/x86/include/asm/kvm_*.h all expected to be external accessible?
> 
> Depends on what you mean by "expected".  Currently, yes, everything in there is
> globally visible.  But the vast majority of structs, defines, functions, etc. aren't
> intended for external non-KVM consumption, things ended up being globally visible
> largely through carelessness and/or a lack of a forcing function.
> 
> E.g. there is absolutely no reason anything outside of KVM should need
> arch/x86/include/asm/kvm-x86-ops.h, but it landed in asm/ because, at the time it
> was added, nothing would be harmed by making kvm-x86-ops.h "public" and we didn't
> scrutinize the patches well enough.
> 
> My primary motivation for this series is to (eventually) get to a state where only
> select symbols/defines/etc. are exposed by KVM to the outside world, and everything
> else is internal only.  The end goal of tightly restricting KVM's global API is to
> allow concurrently loading multiple instances of kvm.ko so that userspace can
> upgrade/rollback KVM without needed to move VMs off the host, i.e. by performing
> intrahost migration between differenate instances of KVM on the same host.  To do
> that safely, anything that is visible outside of KVM needs to be compatible across
> different instances of KVM, e.g. if kvm_vcpu is "public" then a KVM upgrade/rollback
> wouldn't be able to touch "struct kvm_vcpu" in any way.  We'll definitely want to be
> able to modify things like the vCPU structures, thus the push to restrict the API.
> 
> But even if we never realize that end goal, IMO drastically reducing KVM's "public"
> API surface is worthy goal in and of itself.
Got it. Thanks for explanation!