From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Jan Beulich <JBeulich@suse.com>
Subject: [PATCH 6/6] x86/xstate: Fix latent bugs in compress_xsave_states()
Date: Mon, 12 Sep 2016 10:51:40 +0100 [thread overview]
Message-ID: <1473673900-8585-7-git-send-email-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <1473673900-8585-1-git-send-email-andrew.cooper3@citrix.com>
compress_xsave_states() mustn't read xstate_bv or xcomp_bv before first
confirming that the input buffer is large enough. It also doesn't cope with
compressed input. Make all of these problems the callers responsbility to
ensure.
The logic cant cope with an xstate change which would force the use of xrstors
when the vcpu is unpaused. Leave a TODO and BUG_ON() to make this obvious to
whomever is first to implement an xsaves-only state, rather than causing data
corruption.
Finally, avoid silently discarding incoming states if something ends up wrong
with comp_offsets[]. This case shouldn't be able to happen if the preceeding
verification is correct.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
---
xen/arch/x86/xstate.c | 37 +++++++++++++++++++++++++++++--------
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index f6157f5..937abc6 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -224,17 +224,36 @@ void expand_xsave_states(struct vcpu *v, void *dest, unsigned int size)
}
}
+/*
+ * Deserialise a toolstack's xsave state representation suitably for a vcpu.
+ *
+ * Internally a vcpus xsave state may be compressed or uncompressed, depending
+ * on the features in use, but the ABI with the toolstack is strictly
+ * uncompressed.
+ *
+ * It is the callers responsibility to ensure that the source buffer contains
+ * xsave state, is uncompressed, and is exactly the right size.
+ */
void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size)
{
struct xsave_struct *xsave = v->arch.xsave_area;
uint16_t comp_offsets[sizeof(xfeature_mask)*8];
- u64 xstate_bv = ((const struct xsave_struct *)src)->xsave_hdr.xstate_bv;
- u64 valid;
+ u64 xstate_bv, valid;
+
+ BUG_ON(!v->arch.xcr0_accum);
+ BUG_ON(size != xstate_ctxt_size(v->arch.xcr0_accum));
+ BUG_ON(xsave_area_compressed(src));
- ASSERT(!xsave_area_compressed(src));
+ xstate_bv = ((const struct xsave_struct *)src)->xsave_hdr.xstate_bv;
if ( !(v->arch.xcr0_accum & XSTATE_XSAVES_ONLY) )
{
+ /*
+ * TODO: This logic doesn't currently handle restoration of xsave
+ * state which would force the vcpu from uncompressed to compressed.
+ */
+ BUG_ON(xstate_bv & XSTATE_XSAVES_ONLY);
+
memcpy(xsave, src, size);
return;
}
@@ -262,11 +281,13 @@ void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size)
unsigned int index = fls(feature) - 1;
void *dest = get_xsave_addr(xsave, comp_offsets, index);
- if ( dest )
- {
- ASSERT((xstate_offsets[index] + xstate_sizes[index]) <= size);
- memcpy(dest, src + xstate_offsets[index], xstate_sizes[index]);
- }
+ /*
+ * We previously verified xstate_bv. If we don't have valid
+ * comp_offset[] information, something is very broken.
+ */
+ BUG_ON(!dest);
+ BUG_ON((xstate_offsets[index] + xstate_sizes[index]) <= size);
+ memcpy(dest, src + xstate_offsets[index], xstate_sizes[index]);
valid &= ~feature;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-09-12 9:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-12 9:51 [PATCH 0/6] Fix multiple issues with xsave state handling on migrate Andrew Cooper
2016-09-12 9:51 ` [PATCH 1/6] x86/domctl: Introduce PV_XSAVE_HDR_SIZE and remove its opencoding Andrew Cooper
2016-09-12 11:05 ` Jan Beulich
2016-09-12 9:51 ` [PATCH 2/6] x86/domctl: Fix TOCTOU race with the use of XEN_DOMCTL_getvcpuextstate Andrew Cooper
2016-09-12 11:17 ` Jan Beulich
2016-09-12 12:02 ` Andrew Cooper
2016-09-12 12:33 ` Jan Beulich
2016-09-12 13:09 ` Andrew Cooper
2016-09-12 13:35 ` Jan Beulich
2016-09-12 13:37 ` Jan Beulich
2016-09-12 9:51 ` [PATCH 3/6] x86/domctl: Simplfy XEN_DOMCTL_getvcpuextstate when xsave is not in use Andrew Cooper
2016-09-12 11:26 ` Jan Beulich
2016-09-12 9:51 ` [PATCH 4/6] x86/xstate: Fix latent bugs in expand_xsave_states() Andrew Cooper
2016-09-12 11:41 ` Jan Beulich
2016-09-12 12:29 ` Andrew Cooper
2016-09-12 12:41 ` Jan Beulich
2016-09-12 12:43 ` Jan Beulich
2016-09-12 13:57 ` Andrew Cooper
2016-09-12 14:13 ` Jan Beulich
2016-09-12 9:51 ` [PATCH 5/6] x86/domctl: Fix migration of guests which are not using xsave Andrew Cooper
2016-09-12 12:14 ` Jan Beulich
2016-09-12 12:46 ` Andrew Cooper
2016-09-12 13:41 ` Jan Beulich
2016-09-12 9:51 ` Andrew Cooper [this message]
2016-09-12 12:27 ` [PATCH 6/6] x86/xstate: Fix latent bugs in compress_xsave_states() Jan Beulich
2016-09-12 12:59 ` Andrew Cooper
2016-09-12 13:47 ` Jan Beulich
2016-09-12 15:28 ` Andrew Cooper
2016-09-12 16:10 ` 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=1473673900-8585-7-git-send-email-andrew.cooper3@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.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 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).