Attachment 298996 Details for Bug 434759 – xen execshield: fix endless GPF fault loop

[patch] xen execshield: fix endless GPF fault loop

0002-xen-execshield-fix-endless-GPF-fault-loop.patch (text/plain), 2.09 KB, created by Mark McLoughlin on 2008-03-25 10:55:38 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Mark McLoughlin

Created: 2008-03-25 10:55:38 UTC

Size: 2.09 KB

patch

obsolete

>From 9bd8e56403172ac6c3504ab2676b44e5b3fe1b3f Mon Sep 17 00:00:00 2001
>From: Stephen Tweedie <sct@redhat.com>
>Date: Tue, 11 Mar 2008 18:07:31 +0000
>Subject: [PATCH] xen execshield: fix endless GPF fault loop
>
>Under Xen, loading the user_cs descriptor does not necessarily load
>the descriptor with the exact same values the kernel requested: some
>of the control bits in the descriptor may be modified by the
>hypervisor.
>
>With execshield, the check_lazy_exec_limit() function is needed to
>test whether a fault has been caused by the existing user_cs
>descriptor being too constrained: if so, it performs a lazy expansion
>of the legal cs segment bounds.  But it does so via an exact match on
>the descriptor values against their current expected values, so if
>Xen modifies any control bits in the descriptor, it looks as if the
>user_cs is out-of-sync; so check_lazy_exec_limit() resets the
>descriptor and retakes the fault unnecessarily.
>
>This means that a GPF fault can be retried indefinitely, with the
>kernel always seeing the wrong values in user_cs and continually
>trying to correct them and retake the fault.
>
>Fix it by masking off the xen-sensitive control bits when checking
>that the segment descriptor is up-to-date, and comparing only the
>bits which affect the segment base and limit.
>
>Affects 32-bit only; execshield on 64-bit uses NX for this
>functionality.
>
>Signed-off-by: Stephen Tweedie <sct@redhat.com>
>---
> arch/x86/kernel/traps_32.c |    3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c
>index 7865615..3d36a99 100644
>--- a/arch/x86/kernel/traps_32.c
>+++ b/arch/x86/kernel/traps_32.c
>@@ -629,7 +629,8 @@ check_lazy_exec_limit(int cpu, struct pt_regs *regs, long error_code)
> 	desc1 = &current->mm->context.user_cs;
> 	desc2 = get_cpu_gdt_table(cpu) + GDT_ENTRY_DEFAULT_USER_CS;
> 
>-	if (desc1->a != desc2->a || desc1->b != desc2->b) {
>+	if ((desc1->a & 0xff0000ff) != (desc2->a & 0xff0000ff) || 
>+	    desc1->b != desc2->b) {
> 		/*
> 		 * The CS was not in sync - reload it and retry the
> 		 * instruction. If the instruction still faults then
>-- 
>1.5.4.1
>

Actions: View | Diff

Attachments on bug 434759: 298994 | 298996 | 299014