From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Xen-devel <xen-devel@lists.xen.org>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Kevin Tian <kevin.tian@intel.com>,
Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
Jun Nakajima <jun.nakajima@intel.com>,
Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH 2/2] x86/hvm: Don't intercept #UD exceptions in general
Date: Wed, 27 Jan 2016 18:59:28 +0000 [thread overview]
Message-ID: <56A91390.4030604@citrix.com> (raw)
In-Reply-To: <56A91122.50502@oracle.com>
On 27/01/16 18:49, Boris Ostrovsky wrote:
> On 01/27/2016 01:11 PM, Andrew Cooper wrote:
>> c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM
>> domains to
>> unconditionally intercept #UD exceptions. While cross-vendor
>> migration is
>> cool as a demo, it is extremely niche.
>>
>> Intercepting #UD allows userspace code in a multi-vcpu guest to execute
>> arbitrary instructions in the x86 emulator by having one thread
>> execute a ud2a
>> instruction, and having a second thread rewrite the instruction
>> before the
>> emulator performs an instruction fetch.
>>
>> XSAs 105, 106 and 110 are all examples where guest userspace can use
>> bugs in
>> the x86 emulator to compromise security of the domain, either by
>> privilege
>> escalation or causing a crash.
>>
>> c/s 2d67a7a4 "x86: synchronize PCI config space access decoding"
>> introduced (amongst other things) a per-domain vendor, based on the
>> guests
>> cpuid policy.
>>
>> Use the per-guest vendor to enable #UD interception only when a
>> domain is
>> configured for a vendor different to the current hardware. (#UD
>> interception
>> is also enabled if hvm_fep is specified on the Xen command line.
>> This is a
>> debug-only option whose entire purpose is for testing the x86 emulator.)
>>
>> As a result, the overwhelming majority of usecases now have #UD
>> interception
>> disabled, removing an attack surface for malicious guest userspace.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Jun Nakajima <jun.nakajima@intel.com>
>> CC: Kevin Tian <kevin.tian@intel.com>
>> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> CC: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>> CC: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
>> ---
>> xen/arch/x86/domctl.c | 18 ++++++++++++++++++
>> xen/arch/x86/hvm/hvm.c | 6 ++----
>> xen/arch/x86/hvm/svm/svm.c | 13 +++++++++++++
>> xen/arch/x86/hvm/svm/vmcb.c | 1 +
>> xen/arch/x86/hvm/vmx/vmcs.c | 1 +
>> xen/arch/x86/hvm/vmx/vmx.c | 15 +++++++++++++++
>> xen/include/asm-x86/hvm/hvm.h | 15 ++++++++++++++-
>> 7 files changed, 64 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>> index 1d71216..1084e82 100644
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -65,8 +65,20 @@ static void update_domain_cpuid_info(struct domain
>> *d,
>> .ecx = ctl->ecx
>> }
>> };
>> + int old_vendor = d->arch.x86_vendor;
>> d->arch.x86_vendor = get_cpu_vendor(vendor_id.str,
>> gcv_guest);
>> +
>> + if ( is_hvm_domain(d) && (d->arch.x86_vendor != old_vendor) )
>> + {
>> + struct vcpu *v;
>> +
>> + domain_pause(d);
>> + for_each_vcpu( d, v )
>> + hvm_update_guest_vendor(v);
>> + domain_unpause(d);
>> + }
>> +
>> break;
>> }
>
> Not specific to this patch, but shouldn't we pause/unpause domain for
> the whole routine?
Not specifically, although that might be better lonterm.
In practice, this hypercall is only made as part of domain construction,
and never at domain runtime.
>
>
>> @@ -707,6 +719,12 @@ long arch_do_domctl(
>> xen_domctl_cpuid_t *ctl = &domctl->u.cpuid;
>> cpuid_input_t *cpuid, *unused = NULL;
>> + if ( d == currd ) /* no domain_pause() */
>> + {
>> + ret = -EINVAL;
>> + break;
>> + }
>> +
>> for ( i = 0; i < MAX_CPUID_INPUT; i++ )
>> {
>> cpuid = &d->arch.cpuids[i];
>
> ...
>
>> /* Xen command-line option to enable altp2m */
>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>> index 953e0b5..44a1250 100644
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -597,6 +597,18 @@ static void svm_update_guest_efer(struct vcpu *v)
>> vmcb_set_efer(vmcb, new_efer);
>> }
>> +static void svm_update_guest_vendor(struct vcpu *v)
>> +{
>> + struct arch_svm_struct *arch_svm = &v->arch.hvm_svm;
>> + struct vmcb_struct *vmcb = arch_svm->vmcb;
>> +
>> + if ( opt_hvm_fep ||
>> + (v->domain->arch.x86_vendor != boot_cpu_data.x86_vendor) )
>> + vmcb->_exception_intercepts |= (1U << TRAP_invalid_op);
>> + else
>> + vmcb->_exception_intercepts &= ~(1U << TRAP_invalid_op);
>> +}
>
> I think you need to clear clean bits here (at least bit 0).
Hmm - looks like I copied some other code in need of fixing. I will see
what I can do.
~Andrew
next prev parent reply other threads:[~2016-01-27 18:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 18:11 [PATCH 1/2] x86/vmx: Don't clobber exception_bitmap when entering/leaving emulated real mode Andrew Cooper
2016-01-27 18:11 ` [PATCH 2/2] x86/hvm: Don't intercept #UD exceptions in general Andrew Cooper
2016-01-27 18:49 ` Boris Ostrovsky
2016-01-27 18:59 ` Andrew Cooper [this message]
2016-01-27 19:14 ` Boris Ostrovsky
2016-01-27 19:18 ` Andrew Cooper
2016-01-27 19:13 ` [PATCH v2 " Andrew Cooper
2016-01-27 19:26 ` Boris Ostrovsky
2016-01-27 19:52 ` Konrad Rzeszutek Wilk
2016-01-27 19:57 ` Andrew Cooper
2016-01-27 20:21 ` Konrad Rzeszutek Wilk
2016-01-28 9:42 ` Jan Beulich
2016-01-28 10:55 ` Andrew Cooper
2016-01-28 11:30 ` Jan Beulich
2016-01-29 19:17 ` [PATCH v3 " Andrew Cooper
2016-02-01 12:23 ` Jan Beulich
2016-02-02 7:56 ` Tian, Kevin
2016-01-28 9:22 ` [PATCH 1/2] x86/vmx: Don't clobber exception_bitmap when entering/leaving emulated real mode Jan Beulich
2016-02-02 7:54 ` Tian, Kevin
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=56A91390.4030604@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Aravind.Gopalakrishnan@amd.com \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=suravee.suthikulpanit@amd.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.