Fixups for LDT remap placement change

PATCH Superseded Kirill A. Shutemov 2 participants 9 messages Nov 30, 2018 – Dec 11, 2018

Subsystems (4)

Memory management x86 x86 MM Xen hypervisor x86

lore

Share & tools

lore

Kirill A. Shutemov

author

2018-11-30 20:23 UTC #0 lore raw

v2 cover Fixups for LDT remap placement change

There's a couple fixes for the recent LDT remap placement change.

The first patch fixes crash when kernel booted as Xen dom0.

The second patch fixes address space markers in dump_pagetables output. It's purely cosmetic change, backporting to the stable tree is optional.

v2:
- Fix typo

Kirill A. Shutemov (2):
x86/mm: Fix guard hole handling x86/dump_pagetables: Fix LDT remap address marker

 arch/x86/include/asm/pgtable_64_types.h |  5 +++++
 arch/x86/mm/dump_pagetables.c           | 15 ++++++---------
 arch/x86/xen/mmu_pv.c                   | 11 ++++++-----
 3 files changed, 17 insertions(+), 14 deletions(-)

Signature · 1 line

2.19.2

Kirill A. Shutemov

author

2018-11-30 20:23 UTC #1 lore raw

PATCH v2 1/2 x86/mm: Fix guard hole handling

There is a guard hole at the beginning of kernel address space, also used by hypervisors. It occupies 16 PGD entries.

We do not state the reserved range directly, but calculate it relative to other entities: direct mapping and user space ranges.

The calculation got broken by recent change in kernel memory layout: LDT remap range is now mapped before direct mapping and makes the calculation invalid.

The breakage leads to crash on Xen dom0 boot[1].

State the reserved range directly. It's part of kernel ABI (hypervisors expect it to be stable) and must not depend on changes in the rest of kernel memory layout.

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html

Signed-off-by Kirill A. Shutemov <[email protected]>

Reported-by Hans van Kranenburg <[email protected]>

Tested-by Hans van Kranenburg <[email protected]>

Reviewed-by Juergen Gross <[email protected]>

Fixes d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging")

Signed-off-by Kirill A. Shutemov <[email protected]>

---
 arch/x86/include/asm/pgtable_64_types.h |  5 +++++
 arch/x86/mm/dump_pagetables.c           |  8 ++++----
 arch/x86/xen/mmu_pv.c                   | 11 ++++++-----
 3 files changed, 15 insertions(+), 9 deletions(-)

arch/x86/include/asm/pgtable_64_types.h +5 -0

index 84bd9bdc1987..88bca456da99 100644
@@ -111,6 +111,11 @@ extern unsigned int ptrs_per_p4d;
  */
 #define MAXMEM			(1UL << MAX_PHYSMEM_BITS)
 
+#define GUARD_HOLE_PGD_ENTRY	-256UL
+#define GUARD_HOLE_SIZE		(16UL << PGDIR_SHIFT)
+#define GUARD_HOLE_BASE_ADDR	(GUARD_HOLE_PGD_ENTRY << PGDIR_SHIFT)
+#define GUARD_HOLE_END_ADDR	(GUARD_HOLE_BASE_ADDR + GUARD_HOLE_SIZE)
+
 #define LDT_PGD_ENTRY		-240UL
 #define LDT_BASE_ADDR		(LDT_PGD_ENTRY << PGDIR_SHIFT)
 #define LDT_END_ADDR		(LDT_BASE_ADDR + PGDIR_SIZE)

arch/x86/mm/dump_pagetables.c +4 -4

index fc37bbd23eb8..dad153e5a427 100644
@@ -512,11 +512,11 @@ static inline bool is_hypervisor_range(int idx)
 {
 #ifdef CONFIG_X86_64
 	/*
-	 * ffff800000000000 - ffff87ffffffffff is reserved for
-	 * the hypervisor.
+	 * A hole in the beginning of kernel address space reserved
+	 * for a hypervisor.
 	 */
-	return	(idx >= pgd_index(__PAGE_OFFSET) - 16) &&
-		(idx <  pgd_index(__PAGE_OFFSET));
+	return	(idx >= pgd_index(GUARD_HOLE_BASE_ADDR)) &&
+		(idx <  pgd_index(GUARD_HOLE_END_ADDR));
 #else
 	return false;
 #endif

arch/x86/xen/mmu_pv.c +6 -5

index a5d7ed125337..0f4fe206dcc2 100644
@@ -648,19 +648,20 @@ static int __xen_pgd_walk(struct mm_struct *mm, pgd_t *pgd,
 			  unsigned long limit)
 {
 	int i, nr, flush = 0;
-	unsigned hole_low, hole_high;
+	unsigned hole_low = 0, hole_high = 0;
 
 	/* The limit is the last byte to be touched */
 	limit--;
 	BUG_ON(limit >= FIXADDR_TOP);
 
+#ifdef CONFIG_X86_64
 	/*
 	 * 64-bit has a great big hole in the middle of the address
-	 * space, which contains the Xen mappings.  On 32-bit these
-	 * will end up making a zero-sized hole and so is a no-op.
+	 * space, which contains the Xen mappings.
 	 */
-	hole_low = pgd_index(USER_LIMIT);
-	hole_high = pgd_index(PAGE_OFFSET);
+	hole_low = pgd_index(GUARD_HOLE_BASE_ADDR);
+	hole_high = pgd_index(GUARD_HOLE_END_ADDR);
+#endif
 
 	nr = pgd_index(limit) + 1;
 	for (i = 0; i < nr; i++) {

Signature · 1 line

2.19.2

tip-bot for Kirill A. Shutemov

merge bot

2018-12-11 10:34 UTC #2 lore raw

[tip:x86/urgent] x86/mm: Fix guard hole handling

x86/mm: Fix guard hole handling

Commit-ID:  16877a5570e0c5f4270d5b17f9bab427bcae9514
Gitweb:     https://git.kernel.org/tip/16877a5570e0c5f4270d5b17f9bab427bcae9514
Author:     Kirill A. Shutemov <[email protected]>
AuthorDate: Fri, 30 Nov 2018 23:23:27 +0300
Committer:  Thomas Gleixner <[email protected]>
CommitDate: Tue, 11 Dec 2018 11:19:24 +0100

x86/mm: Fix guard hole handling

There is a guard hole at the beginning of the kernel address space, also used by hypervisors. It occupies 16 PGD entries.

This reserved range is not defined explicitely, it is calculated relative to other entities: direct mapping and user space ranges.

The calculation got broken by recent changes of the kernel memory layout:
LDT remap range is now mapped before direct mapping and makes the calculation invalid.

The breakage leads to crash on Xen dom0 boot[1].

Define the reserved range explicitely. It's part of kernel ABI (hypervisors expect it to be stable) and must not depend on changes in the rest of kernel memory layout.

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html

Fixes d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging")

Reported-by Hans van Kranenburg <[email protected]>

Signed-off-by Kirill A. Shutemov <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Tested-by Hans van Kranenburg <[email protected]>

Reviewed-by Juergen Gross <[email protected]>

Cc [email protected]

Link https://lkml.kernel.org/r/[email protected] open here

---
 arch/x86/include/asm/pgtable_64_types.h |  5 +++++
 arch/x86/mm/dump_pagetables.c           |  8 ++++----
 arch/x86/xen/mmu_pv.c                   | 11 ++++++-----
 3 files changed, 15 insertions(+), 9 deletions(-)

arch/x86/include/asm/pgtable_64_types.h +5 -0

index 84bd9bdc1987..88bca456da99 100644
@@ -111,6 +111,11 @@ extern unsigned int ptrs_per_p4d;
  */
 #define MAXMEM			(1UL << MAX_PHYSMEM_BITS)
 
+#define GUARD_HOLE_PGD_ENTRY	-256UL
+#define GUARD_HOLE_SIZE		(16UL << PGDIR_SHIFT)
+#define GUARD_HOLE_BASE_ADDR	(GUARD_HOLE_PGD_ENTRY << PGDIR_SHIFT)
+#define GUARD_HOLE_END_ADDR	(GUARD_HOLE_BASE_ADDR + GUARD_HOLE_SIZE)
+
 #define LDT_PGD_ENTRY		-240UL
 #define LDT_BASE_ADDR		(LDT_PGD_ENTRY << PGDIR_SHIFT)
 #define LDT_END_ADDR		(LDT_BASE_ADDR + PGDIR_SIZE)

arch/x86/mm/dump_pagetables.c +4 -4

index fc37bbd23eb8..dad153e5a427 100644
@@ -512,11 +512,11 @@ static inline bool is_hypervisor_range(int idx)
 {
 #ifdef CONFIG_X86_64
 	/*
-	 * ffff800000000000 - ffff87ffffffffff is reserved for
-	 * the hypervisor.
+	 * A hole in the beginning of kernel address space reserved
+	 * for a hypervisor.
 	 */
-	return	(idx >= pgd_index(__PAGE_OFFSET) - 16) &&
-		(idx <  pgd_index(__PAGE_OFFSET));
+	return	(idx >= pgd_index(GUARD_HOLE_BASE_ADDR)) &&
+		(idx <  pgd_index(GUARD_HOLE_END_ADDR));
 #else
 	return false;
 #endif

arch/x86/xen/mmu_pv.c +6 -5

index a5d7ed125337..0f4fe206dcc2 100644
@@ -648,19 +648,20 @@ static int __xen_pgd_walk(struct mm_struct *mm, pgd_t *pgd,
 			  unsigned long limit)
 {
 	int i, nr, flush = 0;
-	unsigned hole_low, hole_high;
+	unsigned hole_low = 0, hole_high = 0;
 
 	/* The limit is the last byte to be touched */
 	limit--;
 	BUG_ON(limit >= FIXADDR_TOP);
 
+#ifdef CONFIG_X86_64
 	/*
 	 * 64-bit has a great big hole in the middle of the address
-	 * space, which contains the Xen mappings.  On 32-bit these
-	 * will end up making a zero-sized hole and so is a no-op.
+	 * space, which contains the Xen mappings.
 	 */
-	hole_low = pgd_index(USER_LIMIT);
-	hole_high = pgd_index(PAGE_OFFSET);
+	hole_low = pgd_index(GUARD_HOLE_BASE_ADDR);
+	hole_high = pgd_index(GUARD_HOLE_END_ADDR);
+#endif
 
 	nr = pgd_index(limit) + 1;
 	for (i = 0; i < nr; i++) {

Kirill A. Shutemov

author

2018-11-30 20:23 UTC #3 lore raw

PATCH v2 1/2 x86/mm: Fix guard hole handling

In reply to Kirill A. Shutemov

There is a guard hole at the beginning of kernel address space, also used by hypervisors. It occupies 16 PGD entries.

We do not state the reserved range directly, but calculate it relative to other entities: direct mapping and user space ranges.

The calculation got broken by recent change in kernel memory layout: LDT remap range is now mapped before direct mapping and makes the calculation invalid.

The breakage leads to crash on Xen dom0 boot[1].

State the reserved range directly. It's part of kernel ABI (hypervisors expect it to be stable) and must not depend on changes in the rest of kernel memory layout.

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html

Signed-off-by Kirill A. Shutemov <[email protected]>

Reported-by Hans van Kranenburg <[email protected]>

Tested-by Hans van Kranenburg <[email protected]>

Reviewed-by Juergen Gross <[email protected]>

Fixes d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging")

Signed-off-by Kirill A. Shutemov <[email protected]>

---
 arch/x86/include/asm/pgtable_64_types.h |  5 +++++
 arch/x86/mm/dump_pagetables.c           |  8 ++++----
 arch/x86/xen/mmu_pv.c                   | 11 ++++++-----
 3 files changed, 15 insertions(+), 9 deletions(-)

arch/x86/include/asm/pgtable_64_types.h +5 -0

index 84bd9bdc1987..88bca456da99 100644
@@ -111,6 +111,11 @@ extern unsigned int ptrs_per_p4d;
  */
 #define MAXMEM			(1UL << MAX_PHYSMEM_BITS)
 
+#define GUARD_HOLE_PGD_ENTRY	-256UL
+#define GUARD_HOLE_SIZE		(16UL << PGDIR_SHIFT)
+#define GUARD_HOLE_BASE_ADDR	(GUARD_HOLE_PGD_ENTRY << PGDIR_SHIFT)
+#define GUARD_HOLE_END_ADDR	(GUARD_HOLE_BASE_ADDR + GUARD_HOLE_SIZE)
+
 #define LDT_PGD_ENTRY		-240UL
 #define LDT_BASE_ADDR		(LDT_PGD_ENTRY << PGDIR_SHIFT)
 #define LDT_END_ADDR		(LDT_BASE_ADDR + PGDIR_SIZE)

arch/x86/mm/dump_pagetables.c +4 -4

index fc37bbd23eb8..dad153e5a427 100644
@@ -512,11 +512,11 @@ static inline bool is_hypervisor_range(int idx)
 {
 #ifdef CONFIG_X86_64
 	/*
-	 * ffff800000000000 - ffff87ffffffffff is reserved for
-	 * the hypervisor.
+	 * A hole in the beginning of kernel address space reserved
+	 * for a hypervisor.
 	 */
-	return	(idx >= pgd_index(__PAGE_OFFSET) - 16) &&
-		(idx <  pgd_index(__PAGE_OFFSET));
+	return	(idx >= pgd_index(GUARD_HOLE_BASE_ADDR)) &&
+		(idx <  pgd_index(GUARD_HOLE_END_ADDR));
 #else
 	return false;
 #endif

arch/x86/xen/mmu_pv.c +6 -5

index a5d7ed125337..0f4fe206dcc2 100644
@@ -648,19 +648,20 @@ static int __xen_pgd_walk(struct mm_struct *mm, pgd_t *pgd,
 			  unsigned long limit)
 {
 	int i, nr, flush = 0;
-	unsigned hole_low, hole_high;
+	unsigned hole_low = 0, hole_high = 0;
 
 	/* The limit is the last byte to be touched */
 	limit--;
 	BUG_ON(limit >= FIXADDR_TOP);
 
+#ifdef CONFIG_X86_64
 	/*
 	 * 64-bit has a great big hole in the middle of the address
-	 * space, which contains the Xen mappings.  On 32-bit these
-	 * will end up making a zero-sized hole and so is a no-op.
+	 * space, which contains the Xen mappings.
 	 */
-	hole_low = pgd_index(USER_LIMIT);
-	hole_high = pgd_index(PAGE_OFFSET);
+	hole_low = pgd_index(GUARD_HOLE_BASE_ADDR);
+	hole_high = pgd_index(GUARD_HOLE_END_ADDR);
+#endif
 
 	nr = pgd_index(limit) + 1;
 	for (i = 0; i < nr; i++) {

Signature · 7 lines

2.19.2


_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Kirill A. Shutemov

author

2018-11-30 20:23 UTC #4 lore raw

PATCH v2 2/2 x86/dump_pagetables: Fix LDT remap address marker

In reply to Kirill A. Shutemov

The LDT remap placement has been changed. It's now placed before direct mapping in the kernel virtual address space for both paging modes.

Change address markers order accordingly.

Signed-off-by Kirill A. Shutemov <[email protected]>

Fixes d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging")

---
 arch/x86/mm/dump_pagetables.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

arch/x86/mm/dump_pagetables.c +2 -5

index dad153e5a427..abcb8d00b014 100644
@@ -55,10 +55,10 @@ struct addr_marker {
 enum address_markers_idx {
 	USER_SPACE_NR = 0,
 	KERNEL_SPACE_NR,
-	LOW_KERNEL_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && defined(CONFIG_X86_5LEVEL)
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
 	LDT_NR,
 #endif
+	LOW_KERNEL_NR,
 	VMALLOC_START_NR,
 	VMEMMAP_START_NR,
 #ifdef CONFIG_KASAN

@@ -66,9 +66,6 @@ enum address_markers_idx {
 	KASAN_SHADOW_END_NR,
 #endif
 	CPU_ENTRY_AREA_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && !defined(CONFIG_X86_5LEVEL)
-	LDT_NR,
-#endif
 #ifdef CONFIG_X86_ESPFIX64
 	ESPFIX_START_NR,
 #endif

Signature · 1 line

2.19.2

tip-bot for Kirill A. Shutemov

merge bot

2018-12-11 10:34 UTC #5 lore raw

[tip:x86/urgent] x86/dump_pagetables: Fix LDT remap address marker

x86/dump_pagetables: Fix LDT remap address marker

Commit-ID:  254eb5505ca0ca749d3a491fc6668b6c16647a99
Gitweb:     https://git.kernel.org/tip/254eb5505ca0ca749d3a491fc6668b6c16647a99
Author:     Kirill A. Shutemov <[email protected]>
AuthorDate: Fri, 30 Nov 2018 23:23:28 +0300
Committer:  Thomas Gleixner <[email protected]>
CommitDate: Tue, 11 Dec 2018 11:19:24 +0100

x86/dump_pagetables: Fix LDT remap address marker

The LDT remap placement has been changed. It's now placed before the direct mapping in the kernel virtual address space for both paging modes.

Change address markers order accordingly.

Fixes d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging")

Signed-off-by Kirill A. Shutemov <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Cc [email protected]

Link https://lkml.kernel.org/r/[email protected] open here

---
 arch/x86/mm/dump_pagetables.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

arch/x86/mm/dump_pagetables.c +2 -5

index dad153e5a427..abcb8d00b014 100644
@@ -55,10 +55,10 @@ struct addr_marker {
 enum address_markers_idx {
 	USER_SPACE_NR = 0,
 	KERNEL_SPACE_NR,
-	LOW_KERNEL_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && defined(CONFIG_X86_5LEVEL)
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
 	LDT_NR,
 #endif
+	LOW_KERNEL_NR,
 	VMALLOC_START_NR,
 	VMEMMAP_START_NR,
 #ifdef CONFIG_KASAN

@@ -66,9 +66,6 @@ enum address_markers_idx {
 	KASAN_SHADOW_END_NR,
 #endif
 	CPU_ENTRY_AREA_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && !defined(CONFIG_X86_5LEVEL)
-	LDT_NR,
-#endif
 #ifdef CONFIG_X86_ESPFIX64
 	ESPFIX_START_NR,
 #endif

Kirill A. Shutemov

author

2018-11-30 20:24 UTC #6 lore raw

PATCH v2 2/2 x86/dump_pagetables: Fix LDT remap address marker

In reply to Kirill A. Shutemov

The LDT remap placement has been changed. It's now placed before direct mapping in the kernel virtual address space for both paging modes.

Change address markers order accordingly.

Signed-off-by Kirill A. Shutemov <[email protected]>

Fixes d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging")

---
 arch/x86/mm/dump_pagetables.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

arch/x86/mm/dump_pagetables.c +2 -5

index dad153e5a427..abcb8d00b014 100644
@@ -55,10 +55,10 @@ struct addr_marker {
 enum address_markers_idx {
 	USER_SPACE_NR = 0,
 	KERNEL_SPACE_NR,
-	LOW_KERNEL_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && defined(CONFIG_X86_5LEVEL)
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
 	LDT_NR,
 #endif
+	LOW_KERNEL_NR,
 	VMALLOC_START_NR,
 	VMEMMAP_START_NR,
 #ifdef CONFIG_KASAN

@@ -66,9 +66,6 @@ enum address_markers_idx {
 	KASAN_SHADOW_END_NR,
 #endif
 	CPU_ENTRY_AREA_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && !defined(CONFIG_X86_5LEVEL)
-	LDT_NR,
-#endif
 #ifdef CONFIG_X86_ESPFIX64
 	ESPFIX_START_NR,
 #endif

Signature · 7 lines

2.19.2


_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Kirill A. Shutemov

author

2018-12-10 13:10 UTC #7 lore raw

In reply to Kirill A. Shutemov

Quoted 1 line · Kirill A. Shutemov

There's a couple fixes for the recent LDT remap placement change.

Ping?

Signature · 1 line

 Kirill A. Shutemov

Kirill A. Shutemov

author

2018-12-10 13:10 UTC #8 lore raw

In reply to Kirill A. Shutemov

Quoted 1 line · Kirill A. Shutemov

There's a couple fixes for the recent LDT remap placement change.

Ping?

Signature · 6 lines

 Kirill A. Shutemov

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel