linux-kernel - Re: [PATCH 2/4] kvm: svm: Enable UMIP feature on AMD

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: <CALCETrXdo2arN=s9Bt1LmYkPajcBj1NuTPC8dwuw2mMZqT0tRw@mail.gmail.com>
Date:   Fri, 1 Nov 2019 12:24:45 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     "Moger, Babu" <Babu.Moger@....com>
Cc:     Jim Mattson <jmattson@...gle.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>, "hpa@...or.com" <hpa@...or.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "rkrcmar@...hat.com" <rkrcmar@...hat.com>,
        "sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "wanpengli@...cent.com" <wanpengli@...cent.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "joro@...tes.org" <joro@...tes.org>,
        "luto@...nel.org" <luto@...nel.org>,
        "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
        "yamada.masahiro@...ionext.com" <yamada.masahiro@...ionext.com>,
        "nayna@...ux.ibm.com" <nayna@...ux.ibm.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH 2/4] kvm: svm: Enable UMIP feature on AMD

On Fri, Nov 1, 2019 at 12:20 PM Moger, Babu <Babu.Moger@....com> wrote:
>
>
>
> On 11/1/19 1:29 PM, Jim Mattson wrote:
> > On Fri, Nov 1, 2019 at 10:33 AM Moger, Babu <Babu.Moger@....com> wrote:
> >>
> >> AMD 2nd generation EPYC processors support UMIP (User-Mode Instruction
> >> Prevention) feature. The UMIP feature prevents the execution of certain
> >> instructions if the Current Privilege Level (CPL) is greater than 0.
> >> If any of these instructions are executed with CPL > 0 and UMIP
> >> is enabled, then kernel reports a #GP exception.
> >>
> >> The idea is taken from articles:
> >> https://lwn.net/Articles/738209/
> >> https://lwn.net/Articles/694385/
> >>
> >> Enable the feature if supported on bare metal and emulate instructions
> >> to return dummy values for certain cases.
> >>
> >> Signed-off-by: Babu Moger <babu.moger@....com>
> >> ---
> >>  arch/x86/kvm/svm.c |   21 ++++++++++++++++-----
> >>  1 file changed, 16 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> >> index 4153ca8cddb7..79abbdeca148 100644
> >> --- a/arch/x86/kvm/svm.c
> >> +++ b/arch/x86/kvm/svm.c
> >> @@ -2533,6 +2533,11 @@ static void svm_decache_cr4_guest_bits(struct kvm_vcpu *vcpu)
> >>  {
> >>  }
> >>
> >> +static bool svm_umip_emulated(void)
> >> +{
> >> +       return boot_cpu_has(X86_FEATURE_UMIP);
> >> +}
> >
> > This makes no sense to me. If the hardware actually supports UMIP,
> > then it doesn't have to be emulated.
> My understanding..
>
> If the hardware supports the UMIP, it will generate the #GP fault when
> these instructions are executed at CPL > 0. Purpose of the emulation is to
> trap the GP and return a dummy value. Seems like this required in certain
> legacy OSes running in protected and virtual-8086 modes. In long mode no
> need to emulate. Here is the bit explanation https://lwn.net/Articles/738209/
>

Indeed.  Again, what does this have to do with your patch?

>
> >
> > To the extent that kvm emulates UMIP on Intel CPUs without hardware
> > UMIP (i.e. smsw is still allowed at CPL>0), we can always do the same
> > emulation on AMD, because SVM has always offered intercepts of sgdt,
> > sidt, sldt, and str. So, if you really want to offer this emulation on
> > pre-EPYC 2 CPUs, this function should just return true. But, I have to
> > ask, "why?"
>
>
> Trying to support UMIP feature only on EPYC 2 hardware. No intention to
> support pre-EPYC 2.
>

I think you need to totally rewrite your changelog to explain what you
are doing.

As I understand it, there are a couple of things KVM can do:

1. If the underlying hardware supports UMIP, KVM can expose UMIP to
the guest.  SEV should be irrelevant here.

2. Regardless of whether the underlying hardware supports UMIP, KVM
can try to emulate UMIP in the guest.  This may be impossible if SEV
is enabled.

Which of these are you doing?