From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>, xen-devel@lists.xen.org
Cc: mdontu@bitdefender.com, tim@xen.org, JBeulich@suse.com
Subject: Re: [PATCH RFC V2 4/6] xen: Support for VMCALL mem_events
Date: Fri, 11 Jul 2014 18:23:17 +0100 [thread overview]
Message-ID: <53C01D85.3010205@citrix.com> (raw)
In-Reply-To: <1405093418-23481-4-git-send-email-rcojocaru@bitdefender.com>
On 11/07/14 16:43, Razvan Cojocaru wrote:
> Added support for VMCALL events (the memory introspection library
> will have the guest trigger VMCALLs, which will then be sent along
> via the mem_event mechanism).
>
> Changes since V1:
> - Added a #define and an comment explaining a previous magic
> constant.
> - Had MEM_EVENT_REASON_VMCALL explicitly not honour
> HVMPME_onchangeonly.
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
> ---
> xen/arch/x86/hvm/hvm.c | 9 +++++++++
> xen/arch/x86/hvm/vmx/vmx.c | 18 +++++++++++++++++-
> xen/include/asm-x86/hvm/hvm.h | 1 +
> xen/include/public/hvm/params.h | 4 +++-
> xen/include/public/mem_event.h | 5 +++++
> 5 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 89a0382..6e86d7c 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5564,6 +5564,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
> case HVM_PARAM_MEMORY_EVENT_INT3:
> case HVM_PARAM_MEMORY_EVENT_SINGLE_STEP:
> case HVM_PARAM_MEMORY_EVENT_MSR:
> + case HVM_PARAM_MEMORY_EVENT_VMCALL:
> if ( d == current->domain )
> {
> rc = -EPERM;
> @@ -6199,6 +6200,14 @@ void hvm_memory_event_msr(unsigned long msr, unsigned long value)
> value, ~value, 1, msr);
> }
>
> +void hvm_memory_event_vmcall(unsigned long rip, unsigned long eax)
> +{
> + hvm_memory_event_traps(current->domain->arch.hvm_domain
> + .params[HVM_PARAM_MEMORY_EVENT_VMCALL],
> + MEM_EVENT_REASON_VMCALL,
> + rip, ~rip, 1, eax);
> +}
> +
> int hvm_memory_event_int3(unsigned long gla)
> {
> uint32_t pfec = PFEC_page_present;
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2caa04a..6c63225 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2879,8 +2879,24 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> case EXIT_REASON_VMCALL:
> {
> int rc;
> + unsigned long eax = regs->eax;
> +
> HVMTRACE_1D(VMMCALL, regs->eax);
> - rc = hvm_do_hypercall(regs);
> +
> + /* Don't send a VMCALL mem_event unless something
> + * caused the guests's eax register to contain the
> + * VMCALL_EVENT_REQUEST constant. */
> + if ( regs->eax != VMCALL_EVENT_REQUEST )
> + {
> + rc = hvm_do_hypercall(regs);
> + }
> + else
> + {
> + hvm_memory_event_vmcall(guest_cpu_user_regs()->eip, eax);
> + update_guest_eip();
> + break;
> + }
Thinking more about this, it is really a hypercall pretending not to
be. It would be better to introduce a real HVMOP_send_mem_event.
>From the point of view of your in-guest agent, it would be a vmcall with
rax = 34 (hvmop) rdi = $N (send_mem_event subop) rsi = data or pointer
to struct containing data, depending on how exactly you implement the
hypercall.
You would have the bonus of being able to detect errors, e.g. -ENOENT
for "mem_event not active", get SVM support for free, and not need magic
numbers, or vendor specific terms like "vmcall" finding their way into
the Xen public API.
> +
> if ( rc != HVM_HCALL_preempted )
> {
> update_guest_eip(); /* Safe: VMCALL */
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index 0ebd478..3c0af30 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -475,6 +475,7 @@ void hvm_memory_event_cr0(unsigned long value, unsigned long old);
> void hvm_memory_event_cr3(unsigned long value, unsigned long old);
> void hvm_memory_event_cr4(unsigned long value, unsigned long old);
> void hvm_memory_event_msr(unsigned long msr, unsigned long value);
> +void hvm_memory_event_vmcall(unsigned long rip, unsigned long eax);
> /* Called for current VCPU on int3: returns -1 if no listener */
> int hvm_memory_event_int3(unsigned long gla);
>
> diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
> index 614ff5f..d8f89b5 100644
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -151,6 +151,8 @@
> /* Location of the VM Generation ID in guest physical address space. */
> #define HVM_PARAM_VM_GENERATION_ID_ADDR 34
>
> -#define HVM_NR_PARAMS 35
> +#define HVM_PARAM_MEMORY_EVENT_VMCALL 35
What is this hvmparam actually used for? This patch only reads it, and
as indicated previously, it is readwrite to the guest which likely
breaks any assumptions you have about the trustworthness of the value
found there.
~Andrew
> +
> +#define HVM_NR_PARAMS 36
>
> #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_event.h
> index b9af728..7a59083 100644
> --- a/xen/include/public/mem_event.h
> +++ b/xen/include/public/mem_event.h
> @@ -47,6 +47,11 @@
> #define MEM_EVENT_REASON_SINGLESTEP 6 /* single step was invoked: gla/gfn are RIP */
> #define MEM_EVENT_REASON_MSR 7 /* MSR was hit: gfn is MSR value, gla is MSR address;
> does NOT honour HVMPME_onchangeonly */
> +#define MEM_EVENT_REASON_VMCALL 8 /* VMCALL: gfn is RIP, gla is EAX;
> + does NOT honour HVMPME_onchangeonly */
> +
> +/* VMCALL mem_events will only be sent when the guest's EAX holds this value. */
> +#define VMCALL_EVENT_REQUEST 0x494E5452 /* 'INTR' */
>
> /* Using a custom struct (not hvm_hw_cpu) so as to not fill
> * the mem_event ring buffer too quickly. */
next prev parent reply other threads:[~2014-07-11 17:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-11 15:43 [PATCH RFC V2 1/6] xen: Emulate with no writes Razvan Cojocaru
2014-07-11 15:43 ` [PATCH RFC V2 2/6] xen: Optimize introspection access to guest state Razvan Cojocaru
2014-07-11 16:54 ` Andrew Cooper
2014-07-11 16:57 ` Andrew Cooper
2014-07-11 18:03 ` Razvan Cojocaru
2014-07-11 18:09 ` Andrew Cooper
2014-07-11 15:43 ` [PATCH RFC V2 3/6] xen: Force-enable relevant MSR events; optimize the number of sent MSR events Razvan Cojocaru
2014-07-11 17:03 ` Andrew Cooper
2014-07-11 18:09 ` Razvan Cojocaru
[not found] ` <CAGU+ausrcu=L7Kf30gZJXRnnxrKe7EMYXTGByOY4agwoK0nXeA@mail.gmail.com>
2014-07-11 18:18 ` Aravindh Puthiyaparambil (aravindp)
2014-07-11 18:19 ` Andrew Cooper
2014-07-11 18:22 ` Razvan Cojocaru
2014-07-11 18:29 ` Andrew Cooper
2014-07-11 15:43 ` [PATCH RFC V2 4/6] xen: Support for VMCALL mem_events Razvan Cojocaru
2014-07-11 17:23 ` Andrew Cooper [this message]
2014-07-11 18:15 ` Razvan Cojocaru
2015-03-17 13:50 ` Razvan Cojocaru
2015-03-17 13:58 ` Jan Beulich
2015-03-17 14:07 ` Razvan Cojocaru
2015-03-17 14:20 ` Jan Beulich
2015-03-17 14:33 ` Razvan Cojocaru
2014-07-11 15:43 ` [PATCH RFC V2 5/6] xen, libxc: Request page fault injection via libxc Razvan Cojocaru
2014-07-11 18:06 ` Andrew Cooper
2014-07-17 11:53 ` Ian Campbell
2014-07-17 12:07 ` Razvan Cojocaru
2014-07-17 12:22 ` Razvan Cojocaru
2014-07-17 12:38 ` Andrew Cooper
2014-07-11 15:43 ` [PATCH RFC V2 6/6] xen: Handle resumed instruction based on previous mem_event reply Razvan Cojocaru
2014-07-11 18:36 ` Andrew Cooper
2014-07-11 18:41 ` Razvan Cojocaru
2014-07-11 19:12 ` Andrew Cooper
2014-07-11 16:23 ` [PATCH RFC V2 1/6] xen: Emulate with no writes Andrew Cooper
2014-07-11 18:00 ` Razvan Cojocaru
2014-07-14 8:37 ` Razvan Cojocaru
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=53C01D85.3010205@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=mdontu@bitdefender.com \
--cc=rcojocaru@bitdefender.com \
--cc=tim@xen.org \
--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 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).