Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1650810 > unrolled thread

[PATCHv1, RFC 7/8] x86/mm: Hacks for boot-time switching between 4- and 5-level paging

Started by"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
First post2017-05-25 22:40 +0200
Last post2017-05-29 13:30 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCHv1, RFC 7/8] x86/mm: Hacks for boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-05-25 22:40 +0200
    KASAN vs. boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-05-27 03:30 +0200
      Re: KASAN vs. boot-time switching between 4- and 5-level paging Dmitry Vyukov <dvyukov@google.com> - 2017-05-29 12:10 +0200
        Re: KASAN vs. boot-time switching between 4- and 5-level paging Dmitry Vyukov <dvyukov@google.com> - 2017-05-29 13:30 +0200

#1650810 — [PATCHv1, RFC 7/8] x86/mm: Hacks for boot-time switching between 4- and 5-level paging

From"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Date2017-05-25 22:40 +0200
Subject[PATCHv1, RFC 7/8] x86/mm: Hacks for boot-time switching between 4- and 5-level paging
Message-ID<tL7I6-4wz-19@gated-at.bofh.it>
There're bunch of workaround to make switching between 4- and 5-level
paging compile.

All of them need to be addressed properly before upstreaming.

Not-yet-signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/Kconfig          | 4 ++--
 arch/x86/entry/entry_64.S | 5 +++++
 arch/x86/kernel/head_64.S | 6 ++++--
 arch/x86/xen/Kconfig      | 2 +-
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0bf81e837cbf..c795207d8a3c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -100,7 +100,7 @@ config X86
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_HUGE_VMAP		if X86_64 || X86_PAE
 	select HAVE_ARCH_JUMP_LABEL
-	select HAVE_ARCH_KASAN			if X86_64 && SPARSEMEM_VMEMMAP
+	select HAVE_ARCH_KASAN			if X86_64 && SPARSEMEM_VMEMMAP && !X86_5LEVEL
 	select HAVE_ARCH_KGDB
 	select HAVE_ARCH_KMEMCHECK
 	select HAVE_ARCH_MMAP_RND_BITS		if MMU
@@ -1980,7 +1980,7 @@ config RELOCATABLE
 
 config RANDOMIZE_BASE
 	bool "Randomize the address of the kernel image (KASLR)"
-	depends on RELOCATABLE
+	depends on RELOCATABLE && !X86_5LEVEL
 	default y
 	---help---
 	  In support of Kernel Address Space Layout Randomization (KASLR),
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index edec30584eb8..9e868fd6d792 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -269,6 +269,11 @@ return_from_SYSCALL_64:
 	 * Change top bits to match most significant bit (47th or 56th bit
 	 * depending on paging mode) in the address.
 	 */
+#ifdef CONFIG_X86_5LEVEL
+#warning FIXME
+#undef __VIRTUAL_MASK_SHIFT
+#define __VIRTUAL_MASK_SHIFT 56
+#endif
 	shl	$(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx
 	sar	$(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx
 
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 2009d9849e98..9dcf7a4d8612 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -37,11 +37,13 @@
  *
  */
 
-#define p4d_index(x)	(((x) >> P4D_SHIFT) & (PTRS_PER_P4D-1))
 #define pud_index(x)	(((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
 
-PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
+#ifdef CONFIG_XEN
+/* FIXME */
+PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE48)
 PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
+#endif
 L3_START_KERNEL = pud_index(__START_KERNEL_map)
 
 	.text
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 1be9667bd476..c1714cac7595 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -4,7 +4,7 @@
 
 config XEN
 	bool "Xen guest support"
-	depends on PARAVIRT
+	depends on PARAVIRT && !X86_5LEVEL
 	select PARAVIRT_CLOCK
 	depends on X86_64 || (X86_32 && X86_PAE)
 	depends on X86_LOCAL_APIC && X86_TSC
-- 
2.11.0

[toc] | [next] | [standalone]

#1651633 — KASAN vs. boot-time switching between 4- and 5-level paging

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2017-05-27 03:30 +0200
SubjectKASAN vs. boot-time switching between 4- and 5-level paging
Message-ID<tLyIj-4Vw-55@gated-at.bofh.it>
In reply to#1650810
On Thu, May 25, 2017 at 11:33:33PM +0300, Kirill A. Shutemov wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 0bf81e837cbf..c795207d8a3c 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -100,7 +100,7 @@ config X86
>  	select HAVE_ARCH_AUDITSYSCALL
>  	select HAVE_ARCH_HUGE_VMAP		if X86_64 || X86_PAE
>  	select HAVE_ARCH_JUMP_LABEL
> -	select HAVE_ARCH_KASAN			if X86_64 && SPARSEMEM_VMEMMAP
> +	select HAVE_ARCH_KASAN			if X86_64 && SPARSEMEM_VMEMMAP && !X86_5LEVEL
>  	select HAVE_ARCH_KGDB
>  	select HAVE_ARCH_KMEMCHECK
>  	select HAVE_ARCH_MMAP_RND_BITS		if MMU

Looks like KASAN will be a problem for boot-time paging mode switching.
It wants to know CONFIG_KASAN_SHADOW_OFFSET at compile-time to pass to
gcc -fasan-shadow-offset=. But this value varies between paging modes...

I don't see how to solve it. Folks, any ideas?

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]

#1652394 — Re: KASAN vs. boot-time switching between 4- and 5-level paging

FromDmitry Vyukov <dvyukov@google.com>
Date2017-05-29 12:10 +0200
SubjectRe: KASAN vs. boot-time switching between 4- and 5-level paging
Message-ID<tMpMB-6MM-1@gated-at.bofh.it>
In reply to#1651633
On Sat, May 27, 2017 at 12:10 AM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Thu, May 25, 2017 at 11:33:33PM +0300, Kirill A. Shutemov wrote:
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 0bf81e837cbf..c795207d8a3c 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -100,7 +100,7 @@ config X86
>>       select HAVE_ARCH_AUDITSYSCALL
>>       select HAVE_ARCH_HUGE_VMAP              if X86_64 || X86_PAE
>>       select HAVE_ARCH_JUMP_LABEL
>> -     select HAVE_ARCH_KASAN                  if X86_64 && SPARSEMEM_VMEMMAP
>> +     select HAVE_ARCH_KASAN                  if X86_64 && SPARSEMEM_VMEMMAP && !X86_5LEVEL
>>       select HAVE_ARCH_KGDB
>>       select HAVE_ARCH_KMEMCHECK
>>       select HAVE_ARCH_MMAP_RND_BITS          if MMU
>
> Looks like KASAN will be a problem for boot-time paging mode switching.
> It wants to know CONFIG_KASAN_SHADOW_OFFSET at compile-time to pass to
> gcc -fasan-shadow-offset=. But this value varies between paging modes...
>
> I don't see how to solve it. Folks, any ideas?

+kasan-dev

I wonder if we can use the same offset for both modes. If we use
0xFFDFFC0000000000 as start of shadow for 5 levels, then the same
offset that we use for 4 levels (0xdffffc0000000000) will also work
for 5 levels. Namely, ending of 5 level shadow will overlap with 4
level mapping (both end at 0xfffffbffffffffff), but 5 level mapping
extends towards lower addresses. The current 5 level start of shadow
is actually close -- 0xffd8000000000000 and it seems that the required
space after it is unused at the moment (at least looking at mm.txt).
So just try to move it to 0xFFDFFC0000000000?

[toc] | [prev] | [next] | [standalone]

#1652434 — Re: KASAN vs. boot-time switching between 4- and 5-level paging

FromDmitry Vyukov <dvyukov@google.com>
Date2017-05-29 13:30 +0200
SubjectRe: KASAN vs. boot-time switching between 4- and 5-level paging
Message-ID<tMr22-7Aq-19@gated-at.bofh.it>
In reply to#1652394
On Mon, May 29, 2017 at 1:18 PM, Andrey Ryabinin
<aryabinin@virtuozzo.com> wrote:
>
>
> On 05/29/2017 01:02 PM, Dmitry Vyukov wrote:
>> On Sat, May 27, 2017 at 12:10 AM, Kirill A. Shutemov
>> <kirill@shutemov.name> wrote:
>>> On Thu, May 25, 2017 at 11:33:33PM +0300, Kirill A. Shutemov wrote:
>>>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>>>> index 0bf81e837cbf..c795207d8a3c 100644
>>>> --- a/arch/x86/Kconfig
>>>> +++ b/arch/x86/Kconfig
>>>> @@ -100,7 +100,7 @@ config X86
>>>>       select HAVE_ARCH_AUDITSYSCALL
>>>>       select HAVE_ARCH_HUGE_VMAP              if X86_64 || X86_PAE
>>>>       select HAVE_ARCH_JUMP_LABEL
>>>> -     select HAVE_ARCH_KASAN                  if X86_64 && SPARSEMEM_VMEMMAP
>>>> +     select HAVE_ARCH_KASAN                  if X86_64 && SPARSEMEM_VMEMMAP && !X86_5LEVEL
>>>>       select HAVE_ARCH_KGDB
>>>>       select HAVE_ARCH_KMEMCHECK
>>>>       select HAVE_ARCH_MMAP_RND_BITS          if MMU
>>>
>>> Looks like KASAN will be a problem for boot-time paging mode switching.
>>> It wants to know CONFIG_KASAN_SHADOW_OFFSET at compile-time to pass to
>>> gcc -fasan-shadow-offset=. But this value varies between paging modes...
>>>
>>> I don't see how to solve it. Folks, any ideas?
>>
>> +kasan-dev
>>
>> I wonder if we can use the same offset for both modes. If we use
>> 0xFFDFFC0000000000 as start of shadow for 5 levels, then the same
>> offset that we use for 4 levels (0xdffffc0000000000) will also work
>> for 5 levels. Namely, ending of 5 level shadow will overlap with 4
>> level mapping (both end at 0xfffffbffffffffff), but 5 level mapping
>> extends towards lower addresses. The current 5 level start of shadow
>> is actually close -- 0xffd8000000000000 and it seems that the required
>> space after it is unused at the moment (at least looking at mm.txt).
>> So just try to move it to 0xFFDFFC0000000000?
>>
>
> Yeah, this should work, but note that 0xFFDFFC0000000000 is not PGDIR aligned address. Our init code
> assumes that kasan shadow stars and ends on the PGDIR aligned address.
> Fortunately this is fixable, we'd need two more pages for page tables to map unaligned start/end
> of the shadow.

I think we can extend the shadow backwards (to the current address),
provided that it does not affect shadow offset that we pass to
compiler.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web