linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yang Weijiang <weijiang.yang@intel.com>
To: Jim Mattson <jmattson@google.com>
Cc: "Yang Weijiang" <weijiang.yang@intel.com>,
	"kvm list" <kvm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Sean Christopherson" <sean.j.christopherson@intel.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH v7 0/7] Introduce support for Guest CET feature
Date: Thu, 3 Oct 2019 21:01:45 +0800	[thread overview]
Message-ID: <20191003130145.GA25798@local-michael-cet-test.sh.intel.com> (raw)
In-Reply-To: <CALMp9eQ13Lve+9+61qCF1-7mQkeLLnhDufd-geKtz=34+YJdEg@mail.gmail.com>

On Wed, Oct 02, 2019 at 03:40:20PM -0700, Jim Mattson wrote:
> On Thu, Sep 26, 2019 at 7:17 PM Yang Weijiang <weijiang.yang@intel.com> wrote:
> >
> > Control-flow Enforcement Technology (CET) provides protection against
> > Return/Jump-Oriented Programming (ROP/JOP) attack. It includes two
> > sub-features: Shadow Stack (SHSTK) and Indirect Branch Tracking (IBT).
> >
> > KVM modification is required to support Guest CET feature.
> > This patch serial implemented CET related CPUID/XSAVES enumeration, MSRs
> > and VMEntry configuration etc.so that Guest kernel can setup CET
> > runtime infrastructure based on them. Some MSRs and related feature
> > flags used in the patches reference the definitions in kernel patch.
> 
> I am still trying to make my way through the 358 page (!) spec for
> this feature, but I already have some questions/comments about this
> series:
> 
> 1. Does CET "just work" with shadow paging? Shadow paging knows
> nothing about "shadow-stack pages," and it's not clear to me how
> shadow-stack pages will interact with dirty tracking.
> 2. I see non-trivial changes to task switch under CET. Does
> emulator_do_task_switch need to be updated?
> 3. What about all of the emulator routines that emulate control
> transfers (e.g. em_jmp_{far,abs}, em_call_(near_abs,far},
> em_ret_{far,far_imm,near_imm}, etc)? Don't these have to be modified
> to work correctly when CR4.CET is set?
> 4. You don't use the new "enable supervisor shadow stack control" bit
> in the EPTP. I assume that this is entirely optional, right?
> 5. I think the easiest way to handle the nested issue (rather than
> your explicit check for vmxon when setting CR4.CET when the vCPU is in
> VMX operation) is just to leave CR4.CET out of IA32_VMX_CR4_FIXED1
> (which is already the case).
> 6. The function, exception_class(), in x86.c, should be updated to
> categorize #CP as contributory.
> 7. The function, x86_exception_has_error_code(), in x86.h, should be
> updated to include #CP.
> 8. There appear to be multiple changes to SMM that you haven't
> implemented (e.g saving/restoring the SSP registers in/from SMRAM.
> 
> CET is quite complex. Without any tests, I don't see how you can have
> any confidence in the correctness of this patch series.
Thanks Jim for the detailed comments. 

I missed adding test platform and
result introduction in cover letter. This serial of patch has passed CET
test in guest on Intel x86 emulator platform and develop machine. 
Some feature mentioned in the spec. has not been implemented yet. e.g., 
"supervisor shadow stack control". 

CET feature itself is complex, most of the enabling work is
inside kernel, the role of KVM is to expose CET related CPUID and MSRs
etc. to guest, and make guest take over control of the MSRs directly so that
CET can work efficiently for guest. There're QEMU patches for CET too.

I'll review your comments carefully, thank you again!

  reply	other threads:[~2019-10-03 12:59 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27  2:19 [PATCH v7 0/7] Introduce support for Guest CET feature Yang Weijiang
2019-09-27  2:19 ` [PATCH v7 1/7] KVM: CPUID: Fix IA32_XSS support in CPUID(0xd,i) enumeration Yang Weijiang
2019-10-02 17:26   ` Jim Mattson
2019-10-08  8:30     ` Yang Weijiang
2019-10-17 19:46     ` Sean Christopherson
2019-10-18  1:28       ` Yang Weijiang
2019-10-22 19:46         ` Sean Christopherson
2019-10-23  1:16           ` Yang Weijiang
2019-09-27  2:19 ` [PATCH v7 2/7] kvm: vmx: Define CET VMCS fields and CPUID flags Yang Weijiang
2019-10-02 18:04   ` Jim Mattson
2019-10-09  5:56     ` Yang Weijiang
2019-09-27  2:19 ` [PATCH v7 3/7] KVM: VMX: Pass through CET related MSRs to Guest Yang Weijiang
2019-10-02 18:18   ` Jim Mattson
2019-10-09  6:15     ` Yang Weijiang
2019-10-10 19:04       ` Jim Mattson
2019-10-11  1:51         ` Yang Weijiang
2019-10-17 20:04       ` Sean Christopherson
2019-10-18  1:31         ` Yang Weijiang
2019-09-27  2:19 ` [PATCH v7 4/7] KVM: VMX: Load Guest CET via VMCS when CET is enabled in Guest Yang Weijiang
2019-10-02 18:54   ` Jim Mattson
2019-10-09  6:43     ` Yang Weijiang
2019-10-09 23:08       ` Jim Mattson
2019-10-10  1:30         ` Yang Weijiang
2019-10-10 23:44           ` Jim Mattson
2019-10-11  1:43             ` Yang Weijiang
2019-09-27  2:19 ` [PATCH v7 5/7] kvm: x86: Add CET CR4 bit and XSS support Yang Weijiang
2019-10-02 19:05   ` Jim Mattson
2019-10-17 19:56     ` Sean Christopherson
2019-10-18  1:58       ` Yang Weijiang
2019-10-22 20:13         ` Sean Christopherson
2019-10-23  1:19           ` Yang Weijiang
2019-09-27  2:19 ` [PATCH v7 6/7] KVM: x86: Load Guest fpu state when accessing MSRs managed by XSAVES Yang Weijiang
2019-10-02 19:56   ` Jim Mattson
2019-10-09  6:46     ` Yang Weijiang
2019-09-27  2:19 ` [PATCH v7 7/7] KVM: x86: Add user-space access interface for CET MSRs Yang Weijiang
2019-10-02 20:57   ` Jim Mattson
2019-10-09  6:56     ` Yang Weijiang
2019-10-17 19:58     ` Sean Christopherson
2019-10-18  1:32       ` Yang Weijiang
2019-10-02 22:40 ` [PATCH v7 0/7] Introduce support for Guest CET feature Jim Mattson
2019-10-03 13:01   ` Yang Weijiang [this message]
2019-10-03 16:33     ` Jim Mattson
2019-10-08  8:50       ` Yang Weijiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191003130145.GA25798@local-michael-cet-test.sh.intel.com \
    --to=weijiang.yang@intel.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).