From mboxrd@z Thu Jan  1 00:00:00 1970
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
Subject: Re: [PATCH V3 1/3] xen/mem_access: Support for
	memory-content hiding
Date: Mon, 6 Jul 2015 21:27:12 +0300
Message-ID: <559AC880.3070406@bitdefender.com>
References: <1436197873-4559-1-git-send-email-rcojocaru@bitdefender.com>
	<1436197873-4559-2-git-send-email-rcojocaru@bitdefender.com>
	<CAD33N+5d0-ypEjEhD9Uwc-ShDU=f-+EFMAJX5HXuc0xQqVvHwg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAD33N+5d0-ypEjEhD9Uwc-ShDU=f-+EFMAJX5HXuc0xQqVvHwg@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "Lengyel, Tamas" <tlengyel@novetta.com>
Cc: Jun Nakajima <jun.nakajima@intel.com>, Wei Liu <wei.liu2@citrix.com>, kevin.tian@intel.com, keir@xen.org, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, George Dunlap <george.dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, eddie.dong@intel.com, Xen-devel <xen-devel@lists.xen.org>, Aravind.Gopalakrishnan@amd.com, Jan Beulich <jbeulich@suse.com>, suravee.suthikulpanit@amd.com, boris.ostrovsky@oracle.com, Ian Jackson <ian.jackson@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 07/06/2015 07:50 PM, Lengyel, Tamas wrote:
> Handy feature, thanks for doing it!

You're very welcome, I'm quite happy you find it useful.

>     @@ -1466,6 +1466,10 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
>              }
> 
>              v->arch.vm_event.emulate_flags = violation ? rsp->flags : 0;
>     +
>     +        if ( rsp->flags & MEM_ACCESS_SET_EMUL_READ_DATA &&
> 
> 
> So one of the use-cases for this feature I would have is using it in the
> vm_event response to the software breakpoint event. A little bit of
> context: I have written 0xCC into target memory locations, which are
> further protected by mem_access R/W. This setup right now would suffice
> to hide the content easily from the R mem_access events without having
> to remove it. But for X tracing I'm not using mem_access events. Here
> this feature is locked to be only in response to a mem_access events. I
> can *technically* work around that by changing the response type to the
> mem_access event, but it would be nice if this feature would be clearly
> available for non-mem_access events as well (or at least for software
> breakpoint). What do you think, does that usecase make sense here?

It does make a fair ammount of sense, but with this little time until
the feature freeze it does look like a non-trivial change, so if it
doesn't bother you very much to use the plain mem_access event while we
work towards making the response more general, I'd go for trying to get
this patch into 4.6, whatever its chances are.

If you'd prefer that I do some ground work for the future (i.e. rename
MEM_ACCESS constants, etc.), please let me know.


Thanks,
Razvan