Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 298996 Details for
Bug 434759
F-9 pv_ops: re-enable execshield patch
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
[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:
xen execshield: fix endless GPF fault loop
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 = ¤t->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 >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 434759
:
298994
| 298996 |
299014