From: Adrian Pop <apop@bitdefender.com>
To: Tamas K Lengyel <tamas@tklengyel.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: Tue, 23 May 2017 15:03:59 +0300 [thread overview]
Message-ID: <20170523120359.GA24725@hel> (raw)
In-Reply-To: <CABfawhmUX2M1EthtbNZabUk23XX=Yrya_4Qf=rwrsqKWnN1xyg@mail.gmail.com>
On Thu, May 18, 2017 at 11:27:44AM -0600, Tamas K Lengyel wrote:
> 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
Ok, a check can be added easily. The reasoning behind not adding it in
the first place was that should the #VE be disabled in the VM's VMCS,
setting/clearing the suppress #VE bit would do nothing (it is ignored).
> 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)?
AFAIK there isn't any safeguard of this sort. I might just be
excessively ignorant, though. On the other hand the current default
behavior is to enable #VE for all the pages. The default with these
patches would be to issue a VM-Exit, and either a SVA, the Dom0 or the
target DomU itself could modify this behavior to generate #VE instead of
VM-Exit. In any case I'll investigate some more.
Thanks!
> > +
> > + 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-23 12:04 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
2017-05-23 12:03 ` Adrian Pop [this message]
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=20170523120359.GA24725@hel \
--to=apop@bitdefender.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=rcojocaru@bitdefender.com \
--cc=tamas@tklengyel.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).