[PATCH] x86_64: fixup TASK_SIZE_MAX comment

[PATCH] x86_64: fixup TASK_SIZE_MAX comment

[Alexey Dobriyan]

Comment says "by preventing anything executable" which is not true.
Even PROT_NONE mapping can't be installed at (1<<47 - 4096).

	mmap(0x7ffffffff000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM

I wonder if CPUs with wider address space carried the bugs...

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---

 arch/x86/include/asm/processor.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -887,7 +887,7 @@ static inline void spin_lock_prefetch(const void *x)
  * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
  * 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 executable
+ * We avoid this particular problem by preventing anything
  * from being mapped at the maximum canonical address.
  *
  * On AMD CPUs in the Ryzen family, there's a nasty bug in which the

Re: [PATCH] x86_64: fixup TASK_SIZE_MAX comment

[Andy Lutomirski]

On Thu, Mar 5, 2020 at 10:17 AM Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
> Comment says "by preventing anything executable" which is not true.
> Even PROT_NONE mapping can't be installed at (1<<47 - 4096).
>
>         mmap(0x7ffffffff000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM

Reviewed-by: Andy Lutomirski <luto@kernel.org>

>
> I wonder if CPUs with wider address space carried the bugs...

I believe they do.  I won't swear to it.

FWIW, I specifically asked Intel to kindly fix this bug^Wfeature as
part of LA57, and I did not get a helpful response.

[tip: x86/cleanups] x86/asm: Fixup TASK_SIZE_MAX comment

[tip-bot2 for Alexey Dobriyan]

The following commit has been merged into the x86/cleanups branch of tip:

Commit-ID:     4f63b320afdd9af406f4426b0ff1a2cdb23e5b8d
Gitweb:        https://git.kernel.org/tip/4f63b320afdd9af406f4426b0ff1a2cdb23e5b8d
Author:        Alexey Dobriyan <adobriyan@gmail.com>
AuthorDate:    Thu, 05 Mar 2020 21:17:19 +03:00
Committer:     Borislav Petkov <bp@suse.de>
CommitterDate: Fri, 05 Feb 2021 10:37:39 +01:00

x86/asm: Fixup TASK_SIZE_MAX comment

Comment says "by preventing anything executable" which is not true. Even
PROT_NONE mapping can't be installed at (1<<47 - 4096).

  mmap(0x7ffffffff000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM

 [ bp: Fixup to the moved location in page_64_types.h. ]

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Link: https://lkml.kernel.org/r/20200305181719.GA5490@avx2
---
 arch/x86/include/asm/page_64_types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 645bd1d..64297ea 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -66,7 +66,7 @@
  * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
  * 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 executable
+ * We avoid this particular problem by preventing anything
  * from being mapped at the maximum canonical address.
  *
  * On AMD CPUs in the Ryzen family, there's a nasty bug in which the