The following changes since commit 7284ce6c9f6153d1777df5f310c959724d1bd446:
Linus Torvalds (1):
Linux 2.6.33-rc4
are available in the git repository at:
git://xenbits.xensource.com/people/ianc/linux-2.6.git for-x86/bugfixes
Cyrill Gorcunov (1):
x86: kernel_thread -- initialize SS to a known state
Ian Campbell (1):
xen: 64 bit kernel RPL should be 0.
arch/x86/kernel/process.c | 2 ++
arch/x86/xen/enlighten.c | 4 ++++
2 files changed, 6 insertions(+), 0 deletions(-)
From: Cyrill Gorcunov <[email protected]>
Before the kernel_thread was converted into "C" we had
pt_regs::ss set to __KERNEL_DS (by SAVE_ALL asm macro).
Though I must admit I didn't find any *explicit* load of
%ss from this structure the better to be on a safe side
and set it to a known value.
Signed-off-by: Cyrill Gorcunov <[email protected]>
Signed-off-by: Ian Campbell <[email protected]>
---
arch/x86/kernel/process.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index c6ee241..02c3ee0 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -288,6 +288,8 @@ int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
regs.es = __USER_DS;
regs.fs = __KERNEL_PERCPU;
regs.gs = __KERNEL_STACK_CANARY;
+#else
+ regs.ss = __KERNEL_DS;
#endif
regs.orig_ax = -1;
--
1.5.6.5
Under Xen 64 bit guests actually run their kernel in ring 3, however the
hypervisor takes care of squashing descriptor the RPLs transparently (in
order to allow them to continue to differentiate between user and kernel
space CS using the RPL). Therefore the Xen paravirt backend should use
RPL==0 instead of 1 (or 3). Using RPL==1 causes generic arch code to
take incorrect code paths because it uses "testl $3, <CS>, je foo" type
tests for a userspace CS and this considers 1==userspace.
This issue was previously masked because get_kernel_rpl() was omitted
when setting CS in kernel_thread(). This was fixed when kernel_thread()
was unified with 32 bit in f443ff4201dd25cd4dec183f9919ecba90c8edc2.
Signed-off-by: Ian Campbell <[email protected]>
---
arch/x86/xen/enlighten.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 2b26dd5..36daccb 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1151,9 +1151,13 @@ asmlinkage void __init xen_start_kernel(void)
/* keep using Xen gdt for now; no urgent need to change it */
+#ifdef CONFIG_X86_32
pv_info.kernel_rpl = 1;
if (xen_feature(XENFEAT_supervisor_mode_kernel))
pv_info.kernel_rpl = 0;
+#else
+ pv_info.kernel_rpl = 0;
+#endif
/* set the limit of our address space */
xen_reserve_top();
--
1.5.6.5
Commit-ID: 864a0922dd128392467611d9857e5138c6a91999
Gitweb: http://git.kernel.org/tip/864a0922dd128392467611d9857e5138c6a91999
Author: Cyrill Gorcunov <[email protected]>
AuthorDate: Wed, 13 Jan 2010 10:16:07 +0000
Committer: Ingo Molnar <[email protected]>
CommitDate: Wed, 13 Jan 2010 11:23:45 +0100
x86: kernel_thread() -- initialize SS to a known state
Before the kernel_thread was converted into "C" we had
pt_regs::ss set to __KERNEL_DS (by SAVE_ALL asm macro).
Though I must admit I didn't find any *explicit* load of
%ss from this structure the better to be on a safe side
and set it to a known value.
Signed-off-by: Cyrill Gorcunov <[email protected]>
Signed-off-by: Ian Campbell <[email protected]>
Cc: Christian Kujau <[email protected]>
Cc: Jeremy Fitzhardinge <[email protected]>
Cc: Brian Gerst <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/process.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index c6ee241..02c3ee0 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -288,6 +288,8 @@ int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
regs.es = __USER_DS;
regs.fs = __KERNEL_PERCPU;
regs.gs = __KERNEL_STACK_CANARY;
+#else
+ regs.ss = __KERNEL_DS;
#endif
regs.orig_ax = -1;
Commit-ID: e68266b7001a4e29af083716f0c36c0d6dbb1b39
Gitweb: http://git.kernel.org/tip/e68266b7001a4e29af083716f0c36c0d6dbb1b39
Author: Ian Campbell <[email protected]>
AuthorDate: Wed, 13 Jan 2010 10:16:08 +0000
Committer: Ingo Molnar <[email protected]>
CommitDate: Wed, 13 Jan 2010 11:23:54 +0100
x86: xen: 64-bit kernel RPL should be 0
Under Xen 64 bit guests actually run their kernel in ring 3,
however the hypervisor takes care of squashing descriptor the
RPLs transparently (in order to allow them to continue to
differentiate between user and kernel space CS using the RPL).
Therefore the Xen paravirt backend should use RPL==0 instead of
1 (or 3). Using RPL==1 causes generic arch code to take
incorrect code paths because it uses "testl $3, <CS>, je foo"
type tests for a userspace CS and this considers 1==userspace.
This issue was previously masked because get_kernel_rpl() was
omitted when setting CS in kernel_thread(). This was fixed when
kernel_thread() was unified with 32 bit in
f443ff4201dd25cd4dec183f9919ecba90c8edc2.
Signed-off-by: Ian Campbell <[email protected]>
Cc: Christian Kujau <[email protected]>
Cc: Jeremy Fitzhardinge <[email protected]>
Cc: Cyrill Gorcunov <[email protected]>
Cc: Brian Gerst <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/xen/enlighten.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 2b26dd5..36daccb 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1151,9 +1151,13 @@ asmlinkage void __init xen_start_kernel(void)
/* keep using Xen gdt for now; no urgent need to change it */
+#ifdef CONFIG_X86_32
pv_info.kernel_rpl = 1;
if (xen_feature(XENFEAT_supervisor_mode_kernel))
pv_info.kernel_rpl = 0;
+#else
+ pv_info.kernel_rpl = 0;
+#endif
/* set the limit of our address space */
xen_reserve_top();