| 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: <81351099-b1f2-0ad5-1a0c-3d7b18bbb115@amd.com>
Date: Wed, 17 Jun 2020 16:42:36 -0500
From: Babu Moger <babu.moger@....com>
To: Jim Mattson <jmattson@...gle.com>
Cc: Wanpeng Li <wanpengli@...cent.com>, Joerg Roedel <joro@...tes.org>,
the arch/x86 maintainers <x86@...nel.org>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
kvm list <kvm@...r.kernel.org>
Subject: RE: [PATCH v2 2/3] KVM:SVM: Add extended intercept support
> -----Original Message-----
> From: Jim Mattson <jmattson@...gle.com>
> Sent: Wednesday, June 17, 2020 3:45 PM
> To: Moger, Babu <Babu.Moger@....com>
> Cc: Wanpeng Li <wanpengli@...cent.com>; Joerg Roedel <joro@...tes.org>;
> the arch/x86 maintainers <x86@...nel.org>; Sean Christopherson
> <sean.j.christopherson@...el.com>; Ingo Molnar <mingo@...hat.com>;
> Borislav Petkov <bp@...en8.de>; H . Peter Anvin <hpa@...or.com>; Paolo
> Bonzini <pbonzini@...hat.com>; Vitaly Kuznetsov <vkuznets@...hat.com>;
> Thomas Gleixner <tglx@...utronix.de>; LKML <linux-kernel@...r.kernel.org>;
> kvm list <kvm@...r.kernel.org>
> Subject: Re: [PATCH v2 2/3] KVM:SVM: Add extended intercept support
>
> On Wed, Jun 17, 2020 at 11:11 AM Babu Moger <babu.moger@....com>
> wrote:
> >
> > Jim,
> >
> > > -----Original Message-----
> > > From: kvm-owner@...r.kernel.org <kvm-owner@...r.kernel.org> On
> Behalf
> > > Of Babu Moger
> > > Sent: Wednesday, June 17, 2020 9:31 AM
> > > To: Jim Mattson <jmattson@...gle.com>
> > > Cc: Wanpeng Li <wanpengli@...cent.com>; Joerg Roedel
> <joro@...tes.org>;
> > > the arch/x86 maintainers <x86@...nel.org>; Sean Christopherson
> > > <sean.j.christopherson@...el.com>; Ingo Molnar <mingo@...hat.com>;
> > > Borislav Petkov <bp@...en8.de>; H . Peter Anvin <hpa@...or.com>; Paolo
> > > Bonzini <pbonzini@...hat.com>; Vitaly Kuznetsov <vkuznets@...hat.com>;
> > > Thomas Gleixner <tglx@...utronix.de>; LKML <linux-
> kernel@...r.kernel.org>;
> > > kvm list <kvm@...r.kernel.org>
> > > Subject: RE: [PATCH v2 2/3] KVM:SVM: Add extended intercept support
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jim Mattson <jmattson@...gle.com>
> > > > Sent: Tuesday, June 16, 2020 6:17 PM
> > > > To: Moger, Babu <Babu.Moger@....com>
> > > > Cc: Wanpeng Li <wanpengli@...cent.com>; Joerg Roedel
> <joro@...tes.org>;
> > > > the arch/x86 maintainers <x86@...nel.org>; Sean Christopherson
> > > > <sean.j.christopherson@...el.com>; Ingo Molnar <mingo@...hat.com>;
> > > > Borislav Petkov <bp@...en8.de>; H . Peter Anvin <hpa@...or.com>; Paolo
> > > > Bonzini <pbonzini@...hat.com>; Vitaly Kuznetsov
> <vkuznets@...hat.com>;
> > > > Thomas Gleixner <tglx@...utronix.de>; LKML <linux-
> kernel@...r.kernel.org>;
> > > > kvm list <kvm@...r.kernel.org>
> > > > Subject: Re: [PATCH v2 2/3] KVM:SVM: Add extended intercept support
> > > >
> > > > On Tue, Jun 16, 2020 at 3:03 PM Babu Moger <babu.moger@....com>
> > > wrote:
> > > > >
> > > > > The new intercept bits have been added in vmcb control
> > > > > area to support the interception of INVPCID instruction.
> > > > >
> > > > > The following bit is added to the VMCB layout control area
> > > > > to control intercept of INVPCID:
> > > > >
> > > > > Byte Offset Bit(s) Function
> > > > > 14h 2 intercept INVPCID
> > > > >
> > > > > Add the interfaces to support these extended interception.
> > > > > Also update the tracing for extended intercepts.
> > > > >
> > > > > AMD documentation for INVPCID feature is available at "AMD64
> > > > > Architecture Programmer’s Manual Volume 2: System Programming,
> > > > > Pub. 24593 Rev. 3.34(or later)"
> > > > >
> > > > > The documentation can be obtained at the links below:
> > > > > Link:
> > > >
> > >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.a
> > > >
> > >
> md.com%2Fsystem%2Ffiles%2FTechDocs%2F24593.pdf&data=02%7C01%7
> > > >
> > >
> Cbabu.moger%40amd.com%7C4cedcb3567194883601e08d8124b6be7%7C3dd8
> > > >
> > >
> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637279463210520563&s
> > > >
> > >
> data=oRQq0hj0O43A4lnl8JEb%2BHt8oCFHWxcqvLaA1%2BacTJc%3D&reser
> > > > ved=0
> > > > > Link:
> > > >
> > >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.
> > > >
> > >
> kernel.org%2Fshow_bug.cgi%3Fid%3D206537&data=02%7C01%7Cbabu.m
> > > >
> > >
> oger%40amd.com%7C4cedcb3567194883601e08d8124b6be7%7C3dd8961fe48
> > > >
> > >
> 84e608e11a82d994e183d%7C0%7C0%7C637279463210520563&sdata=EtA
> > > >
> rCUBB8etloN%2B%2Blx42RZqai12QFvtJefnxBn1ryMQ%3D&reserved=0
> > > >
> > > > Not your change, but this documentation is terrible. There is no
> > > > INVLPCID instruction, nor is there a PCID instruction.
> > >
> > > Sorry about that. I will bring this to their notice.
> > >
> > > >
> > > > > Signed-off-by: Babu Moger <babu.moger@....com>
> > > > > ---
> > > > > arch/x86/include/asm/svm.h | 3 ++-
> > > > > arch/x86/kvm/svm/nested.c | 6 +++++-
> > > > > arch/x86/kvm/svm/svm.c | 1 +
> > > > > arch/x86/kvm/svm/svm.h | 18 ++++++++++++++++++
> > > > > arch/x86/kvm/trace.h | 12 ++++++++----
> > > > > 5 files changed, 34 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> > > > > index 8a1f5382a4ea..62649fba8908 100644
> > > > > --- a/arch/x86/include/asm/svm.h
> > > > > +++ b/arch/x86/include/asm/svm.h
> > > > > @@ -61,7 +61,8 @@ struct __attribute__ ((__packed__))
> > > vmcb_control_area {
> > > > > u32 intercept_dr;
> > > > > u32 intercept_exceptions;
> > > > > u64 intercept;
> > > > > - u8 reserved_1[40];
> > > > > + u32 intercept_extended;
> > > > > + u8 reserved_1[36];
> > > >
> > > > It seems like a more straightforward implementation would simply
> > > > change 'u64 intercept' to 'u32 intercept[3].'
> > >
> > > Sure. Will change it.
> >
> > This involves much more changes than I originally thought. All these
> > following code needs to be modified. Here is my cscope output for the C
> > symbol intercept.
> >
> > 0 nested.c recalc_intercepts 123 c->intercept = h->intercept;
> > 1 nested.c recalc_intercepts 135 c->intercept &= ~(1ULL <<
> > INTERCEPT_VINTR);
> > 2 nested.c recalc_intercepts 139 c->intercept &= ~(1ULL <<
> > INTERCEPT_VMMCALL);
> > 3 nested.c recalc_intercepts 144 c->intercept |= g->intercept;
> > 4 nested.c copy_vmcb_control_area 153 dst->intercept =
> > from->intercept;
> > 5 nested.c nested_svm_vmrun_msrpm 186 if
> > (!(svm->nested.ctl.intercept & (1ULL << INTERCEPT_MSR_PROT)))
> > 6 nested.c nested_vmcb_check_controls 212 if ((control->intercept & (1ULL
> > << INTERCEPT_VMRUN)) == 0)NIT));
> > 7 nested.c nested_svm_vmrun 436
> > nested_vmcb->control.intercept);
> > 8 nested.c nested_svm_exit_handled_msr 648 if
> > (!(svm->nested.ctl.intercept & (1ULL << INTERCEPT_MSR_PROT)))
> > 9 nested.c nested_svm_intercept_ioio 675 if
> > (!(svm->nested.ctl.intercept & (1ULL << INTERCEPT_IOIO_PROT)))
> > a nested.c nested_svm_intercept 732 if
> > (svm->nested.ctl.intercept & exit_bits)
> > b nested.c nested_exit_on_init 840 return
> > (svm->nested.ctl.intercept & (1ULL << INTERCEPT_INIT));
> > c svm.c check_selective_cr0_intercepted 2205 u64 intercept;
> > d svm.c check_selective_cr0_intercepted 2207 intercept =
> > svm->nested.ctl.intercept;
> > e svm.c check_selective_cr0_intercepted 2210 (!(intercept & (1ULL <<
> > INTERCEPT_SELECTIVE_CR0))))
> > f svm.c dump_vmcb 2803 pr_err("%-20s%016llx\n",
> > "intercepts:", control->intercept);
> > m svm.c svm_check_intercept 3687 intercept =
> > svm->nested.ctl.intercept;
> > n svm.c svm_check_intercept 3689 if (!(intercept & (1ULL <<
> > INTERCEPT_SELECTIVE_CR0)))
> > 6 svm.c svm_apic_init_signal_blocked 3948
> > (svm->vmcb->control.intercept & (1ULL << INTERCEPT_INIT));
> > 7 svm.h set_intercept 300 vmcb->control.intercept |=
> > (1ULL << bit);
> > 8 svm.h clr_intercept 309 vmcb->control.intercept &=
> > ~(1ULL << bit);
> > 9 svm.h is_intercept tercept_ioio 316 return
> > (svm->vmcb->control.intercept & (1ULL << bit)) != 0;
> > a svm.h nested_exit_on_smi 377 return
> > (svm->nested.ctl.intercept & (1ULL << INTERCEPT_SMI));
> > b svm.h nested_exit_on_intr 382 return
> > (svm->nested.ctl.intercept & (1ULL << INTERCEPT_INTR));
> > c svm.h nested_exit_on_nmi 387 return
> > (svm->nested.ctl.intercept & (1ULL << INTERCEPT_NMI));
> >
> > I will have to test extensively if I go ahead with these changes. What do
> > you think?
>
> I see a lot of open-coding of the nested version of is_intercept(),
> which would be a good preparatory cleanup. It also looks like it
> might be useful to introduce __set_intercept() and __clr_intercept()
> which do the same thing as set_intercept() and clr_intercept(),
> without calling recalc_intercepts(), for use *in* recalc_intercepts.
> This code needs a little love. While your original proposal is more
> expedient, taking the time to fix up the existing mess will be more
> beneficial in the long run.
Ok. Sounds good. Will start working on it.Thanks
Powered by blists - more mailing lists