All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x86_64: Add a comment explaining the TASK_SIZE_MAX guard page
@ 2014-11-04 23:46 Andy Lutomirski
  2014-11-10  9:45 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
  0 siblings, 1 reply; 2+ messages in thread
From: Andy Lutomirski @ 2014-11-04 23:46 UTC (permalink / raw)
  To: x86; +Cc: linux-kernel, Andy Lutomirski

That guard page is absolutely necessary; explain why for posterity.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/include/asm/processor.h | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index eb71ec794732..82d93ea13c0c 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -893,7 +893,13 @@ extern unsigned long thread_saved_pc(struct task_struct *tsk);
 
 #else
 /*
- * User space process size. 47bits minus one guard page.
+ * User space process size. 47bits minus one guard page.  The guard
+ * page is necessary on Intel CPUs: if a SYSCALL instruction is at
+ * the highest possible canonical userspace address, then that
+ * syscall will enter the kernel with a non-canonical return
+ * address, and SYSRET will explode dangerously.  We avoid this
+ * particular problem by preventing anything from being mapped
+ * at the maximum canonical address.
  */
 #define TASK_SIZE_MAX	((1UL << 47) - PAGE_SIZE)
 
-- 
1.9.3


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* [tip:x86/vdso] x86_64: Add a comment explaining the TASK_SIZE_MAX guard page
  2014-11-04 23:46 [PATCH] x86_64: Add a comment explaining the TASK_SIZE_MAX guard page Andy Lutomirski
@ 2014-11-10  9:45 ` tip-bot for Andy Lutomirski
  0 siblings, 0 replies; 2+ messages in thread
From: tip-bot for Andy Lutomirski @ 2014-11-10  9:45 UTC (permalink / raw)
  To: linux-tip-commits; +Cc: hpa, mingo, linux-kernel, tglx, luto

Commit-ID:  07114f0f1cda8b2ef6e884d0c7b268a32cce7903
Gitweb:     http://git.kernel.org/tip/07114f0f1cda8b2ef6e884d0c7b268a32cce7903
Author:     Andy Lutomirski <luto@amacapital.net>
AuthorDate: Tue, 4 Nov 2014 15:46:21 -0800
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 10 Nov 2014 10:43:13 +0100

x86_64: Add a comment explaining the TASK_SIZE_MAX guard page

That guard page is absolutely necessary; explain why for
posterity.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Link: http://lkml.kernel.org/r/23320cb5017c2da8475ec20fcde8089d82aa2699.1415144745.git.luto@amacapital.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/include/asm/processor.h | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index eb71ec7..82d93ea 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -893,7 +893,13 @@ extern unsigned long thread_saved_pc(struct task_struct *tsk);
 
 #else
 /*
- * User space process size. 47bits minus one guard page.
+ * User space process size. 47bits minus one guard page.  The guard
+ * page is necessary on Intel CPUs: if a SYSCALL instruction is at
+ * the highest possible canonical userspace address, then that
+ * syscall will enter the kernel with a non-canonical return
+ * address, and SYSRET will explode dangerously.  We avoid this
+ * particular problem by preventing anything from being mapped
+ * at the maximum canonical address.
  */
 #define TASK_SIZE_MAX	((1UL << 47) - PAGE_SIZE)
 

^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-11-10  9:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-04 23:46 [PATCH] x86_64: Add a comment explaining the TASK_SIZE_MAX guard page Andy Lutomirski
2014-11-10  9:45 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.