DescriptionGuru Anbalagane
2009-04-03 03:36:12 UTC
Description of problem:
There are two ways to get to the saved value for a CPU's GDT. One is through
cpu_gdt_table[cpu#], the other is through cpu_gdt_descr[cpu#]. The factors
that determine the contents of the two tables are:
1. if you are the boot CPU (CPU0)
2. if you are a PV xen guest
3. if you are non-virtualized (HVM guest or running on a non-virtualized
system).
For a boot CPU, or for any non-virtualized guest/system CPU,
cpu_gdt_descr[CPU#] points to cpu_gdt_table[CPU#] so it is OK to use either
data structure.
A PV guest's non-boot CPU's cpu_gdt_descr[CPU#] will point to a separately
allocated page which is set up correctly. Its cpu_gdt_table[CPU#] is not set
up so the entries are NULL.
These two factors lead to a bug in an MP 32-bit PV guest's general protection
fault (#GPF) handler. A PV guest's non-boot CPU will not handle a user mode
#GPF because that code path references cpu_gdt_table[CPU#]. It will load NULLs
into the GDT and retry the faulting user instruction. This leads to an endless
loop.
This patch changes the #GPF handler to use cpu_gdt_descr[] by way of
get_cpu_gdt_table() instead of cpu_gdt_table[].
--- linux-2.6.9/arch/i386/kernel/traps-xen.c.orig 2009-02-12 16:27:17.000000000 -0800
+++ linux-2.6.9/arch/i386/kernel/traps-xen.c 2009-02-12 16:26:01.000000000 -0800
@@ -622,7 +622,7 @@
set_user_cs(¤t->mm->context.user_cs, limit);
desc1 = ¤t->mm->context.user_cs;
- desc2 = cpu_gdt_table[cpu] + GDT_ENTRY_DEFAULT_USER_CS;
+ desc2 = &get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS];
/*
* The CS was not in sync - reload it and retry the
Version-Release number of selected component (if applicable):
2.6.9-67, 2.6.9-78
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
Oracle bug no 7916406.
Please include the above patch in el4.7 and el4.8 errata.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
http://rhn.redhat.com/errata/RHSA-2011-0263.html
Description of problem: There are two ways to get to the saved value for a CPU's GDT. One is through cpu_gdt_table[cpu#], the other is through cpu_gdt_descr[cpu#]. The factors that determine the contents of the two tables are: 1. if you are the boot CPU (CPU0) 2. if you are a PV xen guest 3. if you are non-virtualized (HVM guest or running on a non-virtualized system). For a boot CPU, or for any non-virtualized guest/system CPU, cpu_gdt_descr[CPU#] points to cpu_gdt_table[CPU#] so it is OK to use either data structure. A PV guest's non-boot CPU's cpu_gdt_descr[CPU#] will point to a separately allocated page which is set up correctly. Its cpu_gdt_table[CPU#] is not set up so the entries are NULL. These two factors lead to a bug in an MP 32-bit PV guest's general protection fault (#GPF) handler. A PV guest's non-boot CPU will not handle a user mode #GPF because that code path references cpu_gdt_table[CPU#]. It will load NULLs into the GDT and retry the faulting user instruction. This leads to an endless loop. This patch changes the #GPF handler to use cpu_gdt_descr[] by way of get_cpu_gdt_table() instead of cpu_gdt_table[]. --- linux-2.6.9/arch/i386/kernel/traps-xen.c.orig 2009-02-12 16:27:17.000000000 -0800 +++ linux-2.6.9/arch/i386/kernel/traps-xen.c 2009-02-12 16:26:01.000000000 -0800 @@ -622,7 +622,7 @@ set_user_cs(¤t->mm->context.user_cs, limit); desc1 = ¤t->mm->context.user_cs; - desc2 = cpu_gdt_table[cpu] + GDT_ENTRY_DEFAULT_USER_CS; + desc2 = &get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS]; /* * The CS was not in sync - reload it and retry the Version-Release number of selected component (if applicable): 2.6.9-67, 2.6.9-78 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Oracle bug no 7916406. Please include the above patch in el4.7 and el4.8 errata.