From: Tamas K Lengyel <tamas@tklengyel.com>
To: Adrian Pop <apop@bitdefender.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Razvan Cojocaru <rcojocaru@bitdefender.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Jan Beulich <jbeulich@suse.com>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit
Date: Thu, 18 May 2017 11:27:44 -0600 [thread overview]
Message-ID: <CABfawhmUX2M1EthtbNZabUk23XX=Yrya_4Qf=rwrsqKWnN1xyg@mail.gmail.com> (raw)
In-Reply-To: <20170518150758.9414-3-apop@bitdefender.com>
On Thu, May 18, 2017 at 9:07 AM, Adrian Pop <apop@bitdefender.com> wrote:
> Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
> domain to change the value of the #VE suppress bit for a page.
>
> Signed-off-by: Adrian Pop <apop@bitdefender.com>
> ---
> xen/arch/x86/hvm/hvm.c | 14 ++++++++++++
> xen/arch/x86/mm/mem_access.c | 48 +++++++++++++++++++++++++++++++++++++++++
> xen/include/public/hvm/hvm_op.h | 15 +++++++++++++
> xen/include/xen/mem_access.h | 3 +++
> 4 files changed, 80 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 2e76c2345b..eb01527c5b 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4356,6 +4356,7 @@ static int do_altp2m_op(
> case HVMOP_altp2m_destroy_p2m:
> case HVMOP_altp2m_switch_p2m:
> case HVMOP_altp2m_set_mem_access:
> + case HVMOP_altp2m_set_suppress_ve:
> case HVMOP_altp2m_change_gfn:
> break;
> default:
> @@ -4472,6 +4473,19 @@ static int do_altp2m_op(
> a.u.set_mem_access.view);
> break;
>
> + case HVMOP_altp2m_set_suppress_ve:
> + if ( a.u.set_suppress_ve.pad1 || a.u.set_suppress_ve.pad2 )
> + rc = -EINVAL;
> + else
> + {
> + gfn_t gfn = _gfn(a.u.set_mem_access.gfn);
> + unsigned int altp2m_idx = a.u.set_mem_access.view;
> + uint8_t suppress_ve = a.u.set_suppress_ve.suppress_ve;
> +
> + rc = p2m_set_suppress_ve(d, gfn, suppress_ve, altp2m_idx);
> + }
> + break;
> +
> case HVMOP_altp2m_change_gfn:
> if ( a.u.change_gfn.pad1 || a.u.change_gfn.pad2 )
> rc = -EINVAL;
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index d0b0767855..b9e611d3db 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -466,6 +466,54 @@ int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access)
> }
>
> /*
> + * Set/clear the #VE suppress bit for a page. Only available on VMX.
> + */
> +int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, uint8_t suppress_ve,
> + unsigned int altp2m_idx)
> +{
> + struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
> + struct p2m_domain *ap2m = NULL;
> + struct p2m_domain *p2m = NULL;
> + mfn_t mfn;
> + p2m_access_t a;
> + p2m_type_t t;
> + unsigned long gfn_l;
> + int rc = 0;
> +
> + if ( !cpu_has_vmx )
> + return -EOPNOTSUPP;
> +
> + if ( altp2m_idx > 0 )
> + {
> + if ( altp2m_idx >= MAX_ALTP2M ||
> + d->arch.altp2m_eptp[altp2m_idx] == mfn_x(INVALID_MFN) )
> + return -EINVAL;
> +
> + p2m = ap2m = d->arch.altp2m_p2m[altp2m_idx];
> + }
> + else
> + {
> + p2m = host_p2m;
> + }
IMHO there should be some further checks here to verify that the
domain has issued HVMOP_altp2m_vcpu_enable_notify before and that it
was allowed (ie. this hypercall should not be able to enable the
suppress_bit if there is no veinfo_gfn). That said, is there anything
that would prevent a malicious application issuing rouge altp2m HVMOPs
from messing with this if it is activated (which I guess stands for
the rest of the altp2m ops too)?
> +
> + p2m_lock(host_p2m);
> + if ( ap2m )
> + p2m_lock(ap2m);
> +
> + gfn_l = gfn_x(gfn);
> + mfn = p2m->get_entry(p2m, gfn_l, &t, &a, 0, NULL, NULL);
> + if ( !mfn_valid(mfn) )
> + return -ESRCH;
> + rc = p2m->set_entry(p2m, gfn_l, mfn, PAGE_ORDER_4K, t, a,
> + suppress_ve);
> + if ( ap2m )
> + p2m_unlock(ap2m);
> + p2m_unlock(host_p2m);
> +
> + return rc;
> +}
> +
> +/*
> * Local variables:
> * mode: C
> * c-file-style: "BSD"
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index bc00ef0e65..9736092f58 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -231,6 +231,18 @@ struct xen_hvm_altp2m_set_mem_access {
> typedef struct xen_hvm_altp2m_set_mem_access xen_hvm_altp2m_set_mem_access_t;
> DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
>
> +struct xen_hvm_altp2m_set_suppress_ve {
> + /* view */
> + uint16_t view;
> + uint8_t suppress_ve;
> + uint8_t pad1;
> + uint32_t pad2;
> + /* gfn */
> + uint64_t gfn;
> +};
> +typedef struct xen_hvm_altp2m_set_suppress_ve xen_hvm_altp2m_set_suppress_ve_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_suppress_ve_t);
> +
> struct xen_hvm_altp2m_change_gfn {
> /* view */
> uint16_t view;
> @@ -262,6 +274,8 @@ struct xen_hvm_altp2m_op {
> #define HVMOP_altp2m_set_mem_access 7
> /* Change a p2m entry to have a different gfn->mfn mapping */
> #define HVMOP_altp2m_change_gfn 8
> +/* Set the "Suppress #VE" bit on a page */
> +#define HVMOP_altp2m_set_suppress_ve 9
> domid_t domain;
> uint16_t pad1;
> uint32_t pad2;
> @@ -270,6 +284,7 @@ struct xen_hvm_altp2m_op {
> struct xen_hvm_altp2m_vcpu_enable_notify enable_notify;
> struct xen_hvm_altp2m_view view;
> struct xen_hvm_altp2m_set_mem_access set_mem_access;
> + struct xen_hvm_altp2m_set_suppress_ve set_suppress_ve;
> struct xen_hvm_altp2m_change_gfn change_gfn;
> uint8_t pad[64];
> } u;
> diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
> index 5ab34c1553..b6e6a7650a 100644
> --- a/xen/include/xen/mem_access.h
> +++ b/xen/include/xen/mem_access.h
> @@ -78,6 +78,9 @@ long p2m_set_mem_access_multi(struct domain *d,
> */
> int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access);
>
> +int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, uint8_t suppress_ve,
> + unsigned int altp2m_idx);
> +
> #ifdef CONFIG_HAS_MEM_ACCESS
> int mem_access_memop(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
> --
> 2.12.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-05-18 17:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 15:07 [PATCH 0/3] x86: Add a hvmop for setting the #VE suppress bit Adrian Pop
2017-05-18 15:07 ` [PATCH 1/3] x86/mm: Change default value for suppress #VE in set_mem_access() Adrian Pop
2017-05-18 15:07 ` [PATCH 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit Adrian Pop
2017-05-18 17:27 ` Tamas K Lengyel [this message]
2017-05-23 12:03 ` Adrian Pop
2017-05-29 14:38 ` Jan Beulich
2017-06-06 13:00 ` Adrian Pop
2017-06-06 13:08 ` Jan Beulich
2017-06-08 13:49 ` Adrian Pop
2017-06-08 14:08 ` Jan Beulich
2017-06-09 14:18 ` Adrian Pop
2017-05-18 15:07 ` [PATCH 3/3] libxc: Add support for the altp2m suppress #VE hvmop Adrian Pop
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='CABfawhmUX2M1EthtbNZabUk23XX=Yrya_4Qf=rwrsqKWnN1xyg@mail.gmail.com' \
--to=tamas@tklengyel.com \
--cc=andrew.cooper3@citrix.com \
--cc=apop@bitdefender.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=rcojocaru@bitdefender.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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).