From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753252AbdJSL5V (ORCPT ); Thu, 19 Oct 2017 07:57:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55950 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752613AbdJSL5T (ORCPT ); Thu, 19 Oct 2017 07:57:19 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6D736C075BE1 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=pbonzini@redhat.com Subject: Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support. To: Jim Mattson , kvm list , LKML , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Alex Williamson References: <250725286.12444082.1507929205754.JavaMail.zimbra@redhat.com> <20171016000841.GB66870@dazhang1-ssd.sh.intel.com> <96efaece-306c-cde3-06d6-553505612136@redhat.com> <20171018140715.GB28204@dazhang1-ssd.sh.intel.com> From: Paolo Bonzini Message-ID: Date: Thu, 19 Oct 2017 13:57:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171018140715.GB28204@dazhang1-ssd.sh.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 19 Oct 2017 11:57:19 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/10/2017 16:07, Yi Zhang wrote: > On 2017-10-18 at 11:35:12 +0200, Paolo Bonzini wrote: >>> >>> Currently, We only block the write access, As far as I know an example, >>> we now using it in a security daemon: >> >> Understood. However, I think QEMU is the wrong place to set this up. >> >> If the kernel wants to protect _itself_, it should use a hypercall. If >> an introspector appliance wants to protect the guest kernel, it should >> use the socket that connects it to the hypervisor. >> >> Paolo >> > > Thanks Paolo, > > Yes, that correctable, I will think about to switch the interface to a > hypercall, How about we keep these 2 interface together(hyper call + > ioctl)? think about that if VMM manager have some way could intercept > the guest kernel memory accessing, the page protection would like a > hardware watch point, is it an easy way to let VMM manager debug the > guest kernel? I would leave out the ioctl without a use case. It's always tricky to add APIs without a user, as the risk of bit rot is high. But if somebody comes up with a matching useful patch for QEMU or kvmtool, it's fine. > Except the interface change, could you please help to review the other > patch series? just skip the ioctl patch( patch 7). Yes, of course. Paolo