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 3/5] x86/pv: Break handle_ldt_mapping_fault() out of handle_gdt_ldt_mapping_fault()
Date: Fri, 12 Jan 2018 18:37:22 +0000 [thread overview]
Message-ID: <1515782244-6412-4-git-send-email-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <1515782244-6412-1-git-send-email-andrew.cooper3@citrix.com>
Adjust handle_ldt_mapping_fault() exclude the use of this fixup path for
non-PV guests. Well-formed code shouldn't reference the LDT while in HVM vcpu
context, but currently on a context switch from PV to HVM context, there may
be a stale LDT selector loaded, over an unmapped region.
By explicitly excluding HVM context at this point, we avoid erroneous
hypervisor execution resulting in a cascade failure, by falling into
pv_map_ldt_shadow_page().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
---
xen/arch/x86/traps.c | 79 ++++++++++++++++++++++++++++++----------------------
1 file changed, 46 insertions(+), 33 deletions(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index b5849c3..3d6a4d5 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1093,6 +1093,48 @@ static void reserved_bit_page_fault(unsigned long addr,
show_execution_state(regs);
}
+static int handle_ldt_mapping_fault(unsigned int offset,
+ struct cpu_user_regs *regs)
+{
+ struct vcpu *curr = current;
+
+ /*
+ * Not in PV context? Something is very broken. Leave it to the #PF
+ * handler, which will probably result in a panic().
+ */
+ if ( !is_pv_vcpu(curr) )
+ return 0;
+
+ /* Try to copy a mapping from the guest's LDT, if it is valid. */
+ if ( likely(pv_map_ldt_shadow_page(offset)) )
+ {
+ if ( guest_mode(regs) )
+ trace_trap_two_addr(TRC_PV_GDT_LDT_MAPPING_FAULT,
+ regs->rip, offset);
+ }
+ else
+ {
+ /* In hypervisor mode? Leave it to the #PF handler to fix up. */
+ if ( !guest_mode(regs) )
+ return 0;
+
+ /* Access would have become non-canonical? Pass #GP[sel] back. */
+ if ( unlikely(!is_canonical_address(
+ curr->arch.pv_vcpu.ldt_base + offset)) )
+ {
+ uint16_t ec = (offset & ~(X86_XEC_EXT | X86_XEC_IDT)) | X86_XEC_TI;
+
+ pv_inject_hw_exception(TRAP_gp_fault, ec);
+ }
+ else
+ /* else pass the #PF back, with adjusted %cr2. */
+ pv_inject_page_fault(regs->error_code,
+ curr->arch.pv_vcpu.ldt_base + offset);
+ }
+
+ return EXCRET_fault_fixed;
+}
+
static int handle_gdt_ldt_mapping_fault(unsigned long offset,
struct cpu_user_regs *regs)
{
@@ -1114,40 +1156,11 @@ static int handle_gdt_ldt_mapping_fault(unsigned long offset,
offset &= (1UL << (GDT_LDT_VCPU_VA_SHIFT-1)) - 1UL;
if ( likely(is_ldt_area) )
- {
- /* LDT fault: Copy a mapping from the guest's LDT, if it is valid. */
- if ( likely(pv_map_ldt_shadow_page(offset)) )
- {
- if ( guest_mode(regs) )
- trace_trap_two_addr(TRC_PV_GDT_LDT_MAPPING_FAULT,
- regs->rip, offset);
- }
- else
- {
- /* In hypervisor mode? Leave it to the #PF handler to fix up. */
- if ( !guest_mode(regs) )
- return 0;
+ return handle_ldt_mapping_fault(offset, regs);
- /* Access would have become non-canonical? Pass #GP[sel] back. */
- if ( unlikely(!is_canonical_address(
- curr->arch.pv_vcpu.ldt_base + offset)) )
- {
- uint16_t ec = (offset & ~(X86_XEC_EXT | X86_XEC_IDT)) | X86_XEC_TI;
-
- pv_inject_hw_exception(TRAP_gp_fault, ec);
- }
- else
- /* else pass the #PF back, with adjusted %cr2. */
- pv_inject_page_fault(regs->error_code,
- curr->arch.pv_vcpu.ldt_base + offset);
- }
- }
- else
- {
- /* GDT fault: handle the fault as #GP(selector). */
- regs->error_code = offset & ~(X86_XEC_EXT | X86_XEC_IDT | X86_XEC_TI);
- (void)do_general_protection(regs);
- }
+ /* GDT fault: handle the fault as #GP(selector). */
+ regs->error_code = offset & ~(X86_XEC_EXT | X86_XEC_IDT | X86_XEC_TI);
+ do_general_protection(regs);
return EXCRET_fault_fixed;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-01-12 18:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 18:37 [PATCH 0/5] x86: Misc improvements from KAISER-prep work Andrew Cooper
2018-01-12 18:37 ` [PATCH 1/5] x86/idt: Factor out enabling and disabling of ISTs Andrew Cooper
2018-01-12 20:12 ` Doug Goldstein
2018-01-17 14:43 ` Wei Liu
2018-01-18 7:43 ` Jan Beulich
2018-01-12 18:37 ` [PATCH 2/5] x86/pv: Rename invalidate_shadow_ldt() to pv_destroy_ldt() Andrew Cooper
2018-01-12 20:15 ` Doug Goldstein
2018-01-17 14:43 ` Wei Liu
2018-01-18 7:45 ` Jan Beulich
2018-01-12 18:37 ` Andrew Cooper [this message]
2018-01-12 20:22 ` [PATCH 3/5] x86/pv: Break handle_ldt_mapping_fault() out of handle_gdt_ldt_mapping_fault() Doug Goldstein
2018-01-18 7:48 ` Jan Beulich
2018-01-12 18:37 ` [PATCH 4/5] x86/pv: Drop support for paging out the LDT Andrew Cooper
2018-01-12 21:53 ` Doug Goldstein
2018-01-18 7:59 ` Jan Beulich
2018-01-18 10:38 ` George Dunlap
2018-01-18 10:57 ` Jan Beulich
2018-01-18 10:57 ` Andrew Cooper
2018-01-18 11:00 ` Andrew Cooper
2018-01-18 11:37 ` Jan Beulich
2018-01-12 18:37 ` [PATCH 5/5] x86/monitor: Capture Xen's intent to use monitor at boot time Andrew Cooper
2018-01-18 8:05 ` 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=1515782244-6412-4-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).