All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
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>
Subject: Re: [PATCH V3 1/3] xen/mem_access: Support for memory-content hiding
Date: Mon, 6 Jul 2015 21:27:12 +0300	[thread overview]
Message-ID: <559AC880.3070406@bitdefender.com> (raw)
In-Reply-To: <CAD33N+5d0-ypEjEhD9Uwc-ShDU=f-+EFMAJX5HXuc0xQqVvHwg@mail.gmail.com>

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

  reply	other threads:[~2015-07-06 18:27 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-06 15:51 [PATCH V3 0/3] Vm_event memory introspection helpers Razvan Cojocaru
2015-07-06 15:51 ` [PATCH V3 1/3] xen/mem_access: Support for memory-content hiding Razvan Cojocaru
2015-07-06 16:50   ` Lengyel, Tamas
2015-07-06 18:27     ` Razvan Cojocaru [this message]
2015-07-06 18:30       ` Lengyel, Tamas
2015-07-07  8:10         ` Razvan Cojocaru
2015-07-07 12:04           ` Lengyel, Tamas
2015-07-07 12:33             ` Razvan Cojocaru
2015-07-07 13:09             ` Razvan Cojocaru
2015-07-07 13:15               ` Lengyel, Tamas
2015-07-07 13:21                 ` Razvan Cojocaru
2015-07-07 13:27                   ` Lengyel, Tamas
2015-07-07 10:51   ` George Dunlap
2015-07-07 13:27   ` Jan Beulich
2015-07-07 15:32     ` Razvan Cojocaru
2015-07-07 15:40       ` Jan Beulich
2015-07-07 16:20         ` Razvan Cojocaru
2015-07-07 16:24           ` Jan Beulich
2015-07-06 15:51 ` [PATCH V3 2/3] xen/vm_event: Support for guest-requested events Razvan Cojocaru
2015-07-06 16:55   ` Lengyel, Tamas
2015-07-06 17:57   ` Wei Liu
2015-07-07 11:01   ` George Dunlap
2015-07-07 11:59     ` Razvan Cojocaru
2015-07-07 13:30   ` Jan Beulich
2015-07-07 14:26     ` Daniel De Graaf
2015-07-06 15:51 ` [PATCH V3 3/3] xen/vm_event: Deny register writes if refused by vm_event reply Razvan Cojocaru
2015-07-06 17:05   ` Lengyel, Tamas
2015-07-06 17:16     ` Razvan Cojocaru
2015-07-07  9:06     ` Razvan Cojocaru
2015-07-07 12:55       ` Lengyel, Tamas
2015-07-07 13:21         ` Razvan Cojocaru
2015-07-07 13:26           ` Lengyel, Tamas
2015-07-07 11:05   ` George Dunlap
2015-07-07 13:42   ` Jan Beulich

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=559AC880.3070406@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=eddie.dong@intel.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tlengyel@novetta.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.