From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751643AbdJXHz2 (ORCPT ); Tue, 24 Oct 2017 03:55:28 -0400 Received: from mga01.intel.com ([192.55.52.88]:41156 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751323AbdJXHzZ (ORCPT ); Tue, 24 Oct 2017 03:55:25 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,427,1503385200"; d="scan'208";a="913072262" Date: Tue, 24 Oct 2017 15:52:33 +0800 From: Yi Zhang To: Mihai =?utf-8?B?RG9uyJt1?= Cc: Paolo Bonzini , Jim Mattson , kvm list , LKML , Radim =?utf-8?B?S3LEjW3DocWZ?= , Alex Williamson Subject: Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support. Message-ID: <20171024075232.GA34879@dazhang1-ssd.sh.intel.com> Mail-Followup-To: Mihai =?utf-8?B?RG9uyJt1?= , Paolo Bonzini , Jim Mattson , kvm list , LKML , Radim =?utf-8?B?S3LEjW3DocWZ?= , Alex Williamson References: <250725286.12444082.1507929205754.JavaMail.zimbra@redhat.com> <20171016000841.GB66870@dazhang1-ssd.sh.intel.com> <96efaece-306c-cde3-06d6-553505612136@redhat.com> <1508335998.3230.118.camel@bitdefender.com> <20171020084715.GG88002@dazhang1-ssd.sh.intel.com> <1508519207.29329.67.camel@bitdefender.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1508519207.29329.67.camel@bitdefender.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-10-20 at 20:06:47 +0300, Mihai Donțu wrote: > On Fri, 2017-10-20 at 16:47 +0800, Yi Zhang wrote: > > Could you mind to provide more information and history about your > > investigation? > > We are using VMI to secure certain parts of a guest kernel in memory > (like prevent a certain data structure from being overriten). However, > it sometimes happens for that part to be placed in the same page with > other data, of no interest to us, that gets written frequently. This > makes using the EPT problematic (a 4k page is just too big and > generates too many violations). However, SPP (with its 128 bytes > granularity) is ideal here. > > > > Also, if Intel doesn't have a specific use case for it that requires > > > separate access to SPP control, then maybe we can fold it into the VMI > > > API we are working on? > > > > That's totally Excellent as we really don't have a specific user case at > > this time. > > OK. We will spend some time thinking at a proper way of exposing SPP > with the VMI API. > > For example, we now work on implementing something similar to this: > > kvm_set_page_access( struct kvm *kvm, gfn_t gfn, u8 access ); > > The simplest approach would be to add something like: > > kvm_set_sub_page_access( struct kvm *kvm, gfn_t gfn, u32 mask ); > > where every bit from 'mask' indicates the write-allowed state of every > 128-byte subpage. Got it, seems very compatible with current implementation by us. > > > BTW, I have already submit the SPP implementation draft in Xen side. > > when you got some time, you can take a look at if that match your > > requirement. > > I believe my colleague Răzvan Cojocaru has already commented on that > patch set. :-) Oh, yes, pls send my best thanks to him. > > -- > Mihai Donțu >