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

Groups > linux.kernel > #1684192 > unrolled thread

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

Started by"Kirill A. Shutemov" <kirill@shutemov.name>
First post2017-07-10 14:40 +0200
Last post2017-07-13 16:20 +0200
Articles 14 — 5 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

  Re: KASAN vs. boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-07-10 14:40 +0200
    Re: KASAN vs. boot-time switching between 4- and 5-level paging Dmitry Vyukov <dvyukov@google.com> - 2017-07-10 14:50 +0200
      Re: KASAN vs. boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-07-10 16:20 +0200
        Re: KASAN vs. boot-time switching between 4- and 5-level paging Andy Lutomirski <luto@amacapital.net> - 2017-07-10 18:00 +0200
          Re: KASAN vs. boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-07-10 20:50 +0200
            Re: KASAN vs. boot-time switching between 4- and 5-level paging Andy Lutomirski <luto@kernel.org> - 2017-07-10 22:10 +0200
              Re: KASAN vs. boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-07-10 23:30 +0200
                Re: KASAN vs. boot-time switching between 4- and 5-level paging Andy Lutomirski <luto@kernel.org> - 2017-07-11 02:40 +0200
                  Re: KASAN vs. boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-07-11 12:40 +0200
                    Re: KASAN vs. boot-time switching between 4- and 5-level paging Andy Lutomirski <luto@kernel.org> - 2017-07-11 17:10 +0200
                      Re: KASAN vs. boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-07-11 19:10 +0200
                        Re: KASAN vs. boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-07-11 21:10 +0200
                          Re: KASAN vs. boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-07-13 16:00 +0200
                            Re: KASAN vs. boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-07-13 16:20 +0200

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

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2017-07-10 14:40 +0200
SubjectRe: KASAN vs. boot-time switching between 4- and 5-level paging
Message-ID<u1G8N-53s-5@gated-at.bofh.it>
On Thu, Jun 01, 2017 at 05:56:30PM +0300, Andrey Ryabinin wrote:
> On 05/29/2017 03:46 PM, Andrey Ryabinin wrote:
> > On 05/29/2017 02:45 PM, Andrey Ryabinin wrote:
> >>>>>> 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.
> >>
> >> I thought about this. We can round down shadow start to 0xffdf000000000000, but we can't
> >> round up shadow end, because in that case shadow would end at 0xffffffffffffffff.
> >> So we still need at least one more page to cover unaligned end.
> > 
> > Actually, I'm wrong here. I assumed that we would need an additional page to store p4d entries,
> > but in fact we don't need it, as such page should already exist. It's the same last pgd where kernel image
> > is mapped.
> > 
> 
> 
> Something like bellow might work. It's just a proposal to demonstrate the idea, so some code might look ugly.
> And it's only build-tested.

[Sorry for loong delay.]

The patch works for me for legacy boot. But it breaks EFI boot with
5-level paging. And I struggle to understand why.

What I see is many page faults at mm/kasan/kasan.c:758 --
"DEFINE_ASAN_LOAD_STORE(4)". Handling one of them I get double-fault at
arch/x86/kernel/head_64.S:298 -- "pushq %r14", which ends up with triple
fault.

Any ideas?

If you want to play with this by yourself, qemu supports la57 -- use
-cpu "qemu64,+la57".

-- 
 Kirill A. Shutemov

[toc] | [next] | [standalone]

#1684202

FromDmitry Vyukov <dvyukov@google.com>
Date2017-07-10 14:50 +0200
Message-ID<u1Giu-56Z-19@gated-at.bofh.it>
In reply to#1684192
On Mon, Jul 10, 2017 at 2:33 PM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Thu, Jun 01, 2017 at 05:56:30PM +0300, Andrey Ryabinin wrote:
>> On 05/29/2017 03:46 PM, Andrey Ryabinin wrote:
>> > On 05/29/2017 02:45 PM, Andrey Ryabinin wrote:
>> >>>>>> 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.
>> >>
>> >> I thought about this. We can round down shadow start to 0xffdf000000000000, but we can't
>> >> round up shadow end, because in that case shadow would end at 0xffffffffffffffff.
>> >> So we still need at least one more page to cover unaligned end.
>> >
>> > Actually, I'm wrong here. I assumed that we would need an additional page to store p4d entries,
>> > but in fact we don't need it, as such page should already exist. It's the same last pgd where kernel image
>> > is mapped.
>> >
>>
>>
>> Something like bellow might work. It's just a proposal to demonstrate the idea, so some code might look ugly.
>> And it's only build-tested.
>
> [Sorry for loong delay.]
>
> The patch works for me for legacy boot. But it breaks EFI boot with
> 5-level paging. And I struggle to understand why.
>
> What I see is many page faults at mm/kasan/kasan.c:758 --
> "DEFINE_ASAN_LOAD_STORE(4)". Handling one of them I get double-fault at
> arch/x86/kernel/head_64.S:298 -- "pushq %r14", which ends up with triple
> fault.
>
> Any ideas?


Just playing the role of the rubber duck:
 - what is the fault address?
 - is it within the shadow range?
 - was the shadow mapped already?


> If you want to play with this by yourself, qemu supports la57 -- use
> -cpu "qemu64,+la57".
>
> --
>  Kirill A. Shutemov

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

#1684282

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2017-07-10 16:20 +0200
Message-ID<u1HHA-64w-5@gated-at.bofh.it>
In reply to#1684202
On Mon, Jul 10, 2017 at 02:43:17PM +0200, Dmitry Vyukov wrote:
> On Mon, Jul 10, 2017 at 2:33 PM, Kirill A. Shutemov
> <kirill@shutemov.name> wrote:
> > On Thu, Jun 01, 2017 at 05:56:30PM +0300, Andrey Ryabinin wrote:
> >> On 05/29/2017 03:46 PM, Andrey Ryabinin wrote:
> >> > On 05/29/2017 02:45 PM, Andrey Ryabinin wrote:
> >> >>>>>> 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.
> >> >>
> >> >> I thought about this. We can round down shadow start to 0xffdf000000000000, but we can't
> >> >> round up shadow end, because in that case shadow would end at 0xffffffffffffffff.
> >> >> So we still need at least one more page to cover unaligned end.
> >> >
> >> > Actually, I'm wrong here. I assumed that we would need an additional page to store p4d entries,
> >> > but in fact we don't need it, as such page should already exist. It's the same last pgd where kernel image
> >> > is mapped.
> >> >
> >>
> >>
> >> Something like bellow might work. It's just a proposal to demonstrate the idea, so some code might look ugly.
> >> And it's only build-tested.
> >
> > [Sorry for loong delay.]
> >
> > The patch works for me for legacy boot. But it breaks EFI boot with
> > 5-level paging. And I struggle to understand why.
> >
> > What I see is many page faults at mm/kasan/kasan.c:758 --
> > "DEFINE_ASAN_LOAD_STORE(4)". Handling one of them I get double-fault at
> > arch/x86/kernel/head_64.S:298 -- "pushq %r14", which ends up with triple
> > fault.
> >
> > Any ideas?
> 
> 
> Just playing the role of the rubber duck:
>  - what is the fault address?
>  - is it within the shadow range?
>  - was the shadow mapped already?

I misread trace. The initial fault is at arch/x86/kernel/head_64.S:270,
which is ".endr" in definition of early_idt_handler_array.

The fault address for all three faults is 0xffffffff7ffffff8, which is
outside shadow range. It's just before kernel text mapping.

Codewise, it happens in load_ucode_bsp() -- after kasan_early_init(), but
before kasan_init().

-- 
 Kirill A. Shutemov

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

#1684385

FromAndy Lutomirski <luto@amacapital.net>
Date2017-07-10 18:00 +0200
Message-ID<u1Jgm-6Vr-31@gated-at.bofh.it>
In reply to#1684282

> On Jul 10, 2017, at 7:17 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> 
>> On Mon, Jul 10, 2017 at 02:43:17PM +0200, Dmitry Vyukov wrote:
>> On Mon, Jul 10, 2017 at 2:33 PM, Kirill A. Shutemov
>> <kirill@shutemov.name> wrote:
>>> On Thu, Jun 01, 2017 at 05:56:30PM +0300, Andrey Ryabinin wrote:
>>>>> On 05/29/2017 03:46 PM, Andrey Ryabinin wrote:
>>>>> On 05/29/2017 02:45 PM, Andrey Ryabinin wrote:
>>>>>>>>>> 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.
>>>>>> 
>>>>>> I thought about this. We can round down shadow start to 0xffdf000000000000, but we can't
>>>>>> round up shadow end, because in that case shadow would end at 0xffffffffffffffff.
>>>>>> So we still need at least one more page to cover unaligned end.
>>>>> 
>>>>> Actually, I'm wrong here. I assumed that we would need an additional page to store p4d entries,
>>>>> but in fact we don't need it, as such page should already exist. It's the same last pgd where kernel image
>>>>> is mapped.
>>>>> 
>>>> 
>>>> 
>>>> Something like bellow might work. It's just a proposal to demonstrate the idea, so some code might look ugly.
>>>> And it's only build-tested.
>>> 
>>> [Sorry for loong delay.]
>>> 
>>> The patch works for me for legacy boot. But it breaks EFI boot with
>>> 5-level paging. And I struggle to understand why.
>>> 
>>> What I see is many page faults at mm/kasan/kasan.c:758 --
>>> "DEFINE_ASAN_LOAD_STORE(4)". Handling one of them I get double-fault at
>>> arch/x86/kernel/head_64.S:298 -- "pushq %r14", which ends up with triple
>>> fault.
>>> 
>>> Any ideas?
>> 
>> 
>> Just playing the role of the rubber duck:
>> - what is the fault address?
>> - is it within the shadow range?
>> - was the shadow mapped already?
> 
> I misread trace. The initial fault is at arch/x86/kernel/head_64.S:270,
> which is ".endr" in definition of early_idt_handler_array.
> 
> The fault address for all three faults is 0xffffffff7ffffff8, which is
> outside shadow range. It's just before kernel text mapping.
> 
> Codewise, it happens in load_ucode_bsp() -- after kasan_early_init(), but
> before kasan_init().

My theory is that, in 5 level mode, the early IDT code isn't all mapped in the page tables.  This could sometimes be papered over by lazy page table setup, but lazy setup can't handle faults in the page fault code or data structures.

EFI sometimes uses separate page tables, which could contribute.

> 
> -- 
> Kirill A. Shutemov

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

#1684576

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2017-07-10 20:50 +0200
Message-ID<u1LUS-cs-11@gated-at.bofh.it>
In reply to#1684385
On Mon, Jul 10, 2017 at 08:56:37AM -0700, Andy Lutomirski wrote:
> 
> 
> > On Jul 10, 2017, at 7:17 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> > 
> >> On Mon, Jul 10, 2017 at 02:43:17PM +0200, Dmitry Vyukov wrote:
> >> On Mon, Jul 10, 2017 at 2:33 PM, Kirill A. Shutemov
> >> <kirill@shutemov.name> wrote:
> >>> On Thu, Jun 01, 2017 at 05:56:30PM +0300, Andrey Ryabinin wrote:
> >>>>> On 05/29/2017 03:46 PM, Andrey Ryabinin wrote:
> >>>>> On 05/29/2017 02:45 PM, Andrey Ryabinin wrote:
> >>>>>>>>>> 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.
> >>>>>> 
> >>>>>> I thought about this. We can round down shadow start to 0xffdf000000000000, but we can't
> >>>>>> round up shadow end, because in that case shadow would end at 0xffffffffffffffff.
> >>>>>> So we still need at least one more page to cover unaligned end.
> >>>>> 
> >>>>> Actually, I'm wrong here. I assumed that we would need an additional page to store p4d entries,
> >>>>> but in fact we don't need it, as such page should already exist. It's the same last pgd where kernel image
> >>>>> is mapped.
> >>>>> 
> >>>> 
> >>>> 
> >>>> Something like bellow might work. It's just a proposal to demonstrate the idea, so some code might look ugly.
> >>>> And it's only build-tested.
> >>> 
> >>> [Sorry for loong delay.]
> >>> 
> >>> The patch works for me for legacy boot. But it breaks EFI boot with
> >>> 5-level paging. And I struggle to understand why.
> >>> 
> >>> What I see is many page faults at mm/kasan/kasan.c:758 --
> >>> "DEFINE_ASAN_LOAD_STORE(4)". Handling one of them I get double-fault at
> >>> arch/x86/kernel/head_64.S:298 -- "pushq %r14", which ends up with triple
> >>> fault.
> >>> 
> >>> Any ideas?
> >> 
> >> 
> >> Just playing the role of the rubber duck:
> >> - what is the fault address?
> >> - is it within the shadow range?
> >> - was the shadow mapped already?
> > 
> > I misread trace. The initial fault is at arch/x86/kernel/head_64.S:270,
> > which is ".endr" in definition of early_idt_handler_array.
> > 
> > The fault address for all three faults is 0xffffffff7ffffff8, which is
> > outside shadow range. It's just before kernel text mapping.
> > 
> > Codewise, it happens in load_ucode_bsp() -- after kasan_early_init(), but
> > before kasan_init().
> 
> My theory is that, in 5 level mode, the early IDT code isn't all mapped
> in the page tables.  This could sometimes be papered over by lazy page
> table setup, but lazy setup can't handle faults in the page fault code
> or data structures.
> 
> EFI sometimes uses separate page tables, which could contribute.

As far as I can see all involved code is within the same page:

(gdb) p/x &x86_64_start_kernel
$1 = 0xffffffff84bad2ae
(gdb) p/x &early_idt_handler_array
$2 = 0xffffffff84bad000
(gdb) p/x &early_idt_handler_common
$3 = 0xffffffff84bad120
(gdb) p/x &early_make_pgtable
$4 = 0xffffffff84bad3b4

-- 
 Kirill A. Shutemov

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

#1684614

FromAndy Lutomirski <luto@kernel.org>
Date2017-07-10 22:10 +0200
Message-ID<u1Nai-16y-15@gated-at.bofh.it>
In reply to#1684576
On Mon, Jul 10, 2017 at 11:47 AM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Mon, Jul 10, 2017 at 08:56:37AM -0700, Andy Lutomirski wrote:
>>
>>
>> > On Jul 10, 2017, at 7:17 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
>> >
>> >> On Mon, Jul 10, 2017 at 02:43:17PM +0200, Dmitry Vyukov wrote:
>> >> On Mon, Jul 10, 2017 at 2:33 PM, Kirill A. Shutemov
>> >> <kirill@shutemov.name> wrote:
>> >>> On Thu, Jun 01, 2017 at 05:56:30PM +0300, Andrey Ryabinin wrote:
>> >>>>> On 05/29/2017 03:46 PM, Andrey Ryabinin wrote:
>> >>>>> On 05/29/2017 02:45 PM, Andrey Ryabinin wrote:
>> >>>>>>>>>> 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.
>> >>>>>>
>> >>>>>> I thought about this. We can round down shadow start to 0xffdf000000000000, but we can't
>> >>>>>> round up shadow end, because in that case shadow would end at 0xffffffffffffffff.
>> >>>>>> So we still need at least one more page to cover unaligned end.
>> >>>>>
>> >>>>> Actually, I'm wrong here. I assumed that we would need an additional page to store p4d entries,
>> >>>>> but in fact we don't need it, as such page should already exist. It's the same last pgd where kernel image
>> >>>>> is mapped.
>> >>>>>
>> >>>>
>> >>>>
>> >>>> Something like bellow might work. It's just a proposal to demonstrate the idea, so some code might look ugly.
>> >>>> And it's only build-tested.
>> >>>
>> >>> [Sorry for loong delay.]
>> >>>
>> >>> The patch works for me for legacy boot. But it breaks EFI boot with
>> >>> 5-level paging. And I struggle to understand why.
>> >>>
>> >>> What I see is many page faults at mm/kasan/kasan.c:758 --
>> >>> "DEFINE_ASAN_LOAD_STORE(4)". Handling one of them I get double-fault at
>> >>> arch/x86/kernel/head_64.S:298 -- "pushq %r14", which ends up with triple
>> >>> fault.
>> >>>
>> >>> Any ideas?
>> >>
>> >>
>> >> Just playing the role of the rubber duck:
>> >> - what is the fault address?
>> >> - is it within the shadow range?
>> >> - was the shadow mapped already?
>> >
>> > I misread trace. The initial fault is at arch/x86/kernel/head_64.S:270,
>> > which is ".endr" in definition of early_idt_handler_array.
>> >
>> > The fault address for all three faults is 0xffffffff7ffffff8, which is
>> > outside shadow range. It's just before kernel text mapping.
>> >
>> > Codewise, it happens in load_ucode_bsp() -- after kasan_early_init(), but
>> > before kasan_init().
>>
>> My theory is that, in 5 level mode, the early IDT code isn't all mapped
>> in the page tables.  This could sometimes be papered over by lazy page
>> table setup, but lazy setup can't handle faults in the page fault code
>> or data structures.
>>
>> EFI sometimes uses separate page tables, which could contribute.
>
> As far as I can see all involved code is within the same page:
>
> (gdb) p/x &x86_64_start_kernel
> $1 = 0xffffffff84bad2ae
> (gdb) p/x &early_idt_handler_array
> $2 = 0xffffffff84bad000
> (gdb) p/x &early_idt_handler_common
> $3 = 0xffffffff84bad120
> (gdb) p/x &early_make_pgtable
> $4 = 0xffffffff84bad3b4
>

Can you give the disassembly of the backtrace lines?  Blaming the
.endr doesn't make much sense to me.

Or maybe Andrey will figure it out quickly.

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

#1684651

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2017-07-10 23:30 +0200
Message-ID<u1OpJ-1Qy-39@gated-at.bofh.it>
In reply to#1684614
On Mon, Jul 10, 2017 at 01:07:13PM -0700, Andy Lutomirski wrote:
> Can you give the disassembly of the backtrace lines?  Blaming the
> .endr doesn't make much sense to me.

I don't have backtrace. It's before printk() is functional. I only see
triple fault and reboot.

I had to rely on qemu tracing and gdb.

-- 
 Kirill A. Shutemov

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

#1684706

FromAndy Lutomirski <luto@kernel.org>
Date2017-07-11 02:40 +0200
Message-ID<u1Rnz-3CH-1@gated-at.bofh.it>
In reply to#1684651
On Mon, Jul 10, 2017 at 2:24 PM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Mon, Jul 10, 2017 at 01:07:13PM -0700, Andy Lutomirski wrote:
>> Can you give the disassembly of the backtrace lines?  Blaming the
>> .endr doesn't make much sense to me.
>
> I don't have backtrace. It's before printk() is functional. I only see
> triple fault and reboot.
>
> I had to rely on qemu tracing and gdb.

Can you ask GDB or objtool to disassemble around those addresses?  Can
you also attach the big dump that QEMU throws out that shows register
state?  In particular, CR2, CR3, and CR4 could be useful.

--Andy

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

#1684947

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2017-07-11 12:40 +0200
Message-ID<u20Ke-15l-3@gated-at.bofh.it>
In reply to#1684706
On Mon, Jul 10, 2017 at 05:30:38PM -0700, Andy Lutomirski wrote:
> On Mon, Jul 10, 2017 at 2:24 PM, Kirill A. Shutemov
> <kirill@shutemov.name> wrote:
> > On Mon, Jul 10, 2017 at 01:07:13PM -0700, Andy Lutomirski wrote:
> >> Can you give the disassembly of the backtrace lines?  Blaming the
> >> .endr doesn't make much sense to me.
> >
> > I don't have backtrace. It's before printk() is functional. I only see
> > triple fault and reboot.
> >
> > I had to rely on qemu tracing and gdb.
> 
> Can you ask GDB or objtool to disassemble around those addresses?  Can
> you also attach the big dump that QEMU throws out that shows register
> state?  In particular, CR2, CR3, and CR4 could be useful.

The last three execptions:

check_exception old: 0xffffffff new 0xe, cr2: 0xffffffff7ffffff8, rip: 0xffffffff84bb3036
RAX=00000000ffffffff RBX=ffffffff800000d8 RCX=ffffffff84be4021 RDX=dffffc0000000000
RSI=0000000000000006 RDI=ffffffff84c57000 RBP=ffffffff800000c8 RSP=ffffffff80000000
R8 =6d756e2032616476 R9 =2f7665642f3d746f R10=6f72203053797474 R11=3d656c6f736e6f63
R12=0000000000000006 R13=000000003fffb000 R14=ffffffff82a07ed8 R15=000000000140008e
RIP=ffffffff84bb3036 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 0000000000000000 00000000 00000000
CS =0010 0000000000000000 ffffffff 00af9b00 DPL=0 CS64 [-RA]
SS =0000 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0000 0000000000000000 00000000 00000000
FS =0000 0000000000000000 00000000 00000000
GS =0000 ffffffff84b8f000 00000000 00000000
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     ffffffff84ba1000 0000007f
IDT=     ffffffff84d92000 00000fff
CR0=80050033 CR2=ffffffff7ffffff8 CR3=0000000009c58000 CR4=000010a0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000d01

check_exception old: 0xe new 0xe, cr2: 0xffffffff7ffffff8, rip: 0xffffffff84bb3141
RAX=00000000ffffffff RBX=ffffffff800000d8 RCX=ffffffff84be4021 RDX=dffffc0000000000
RSI=0000000000000006 RDI=ffffffff84c57000 RBP=ffffffff800000c8 RSP=ffffffff80000000
R8 =6d756e2032616476 R9 =2f7665642f3d746f R10=6f72203053797474 R11=3d656c6f736e6f63
R12=0000000000000006 R13=000000003fffb000 R14=ffffffff82a07ed8 R15=000000000140008e
RIP=ffffffff84bb3141 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 0000000000000000 00000000 00000000
CS =0010 0000000000000000 ffffffff 00af9b00 DPL=0 CS64 [-RA]
SS =0000 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0000 0000000000000000 00000000 00000000
FS =0000 0000000000000000 00000000 00000000
GS =0000 ffffffff84b8f000 00000000 00000000
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     ffffffff84ba1000 0000007f
IDT=     ffffffff84d92000 00000fff
CR0=80050033 CR2=ffffffff7ffffff8 CR3=0000000009c58000 CR4=000010a0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000d01

check_exception old: 0x8 new 0xe, cr2: 0xffffffff7ffffff8, rip: 0xffffffff84bb3141
RAX=00000000ffffffff RBX=ffffffff800000d8 RCX=ffffffff84be4021 RDX=dffffc0000000000
RSI=0000000000000006 RDI=ffffffff84c57000 RBP=ffffffff800000c8 RSP=ffffffff80000000
R8 =6d756e2032616476 R9 =2f7665642f3d746f R10=6f72203053797474 R11=3d656c6f736e6f63
R12=0000000000000006 R13=000000003fffb000 R14=ffffffff82a07ed8 R15=000000000140008e
RIP=ffffffff84bb3141 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 0000000000000000 00000000 00000000
CS =0010 0000000000000000 ffffffff 00af9b00 DPL=0 CS64 [-RA]
SS =0000 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0000 0000000000000000 00000000 00000000
FS =0000 0000000000000000 00000000 00000000
GS =0000 ffffffff84b8f000 00000000 00000000
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     ffffffff84ba1000 0000007f
IDT=     ffffffff84d92000 00000fff
CR0=80050033 CR2=ffffffff7ffffff8 CR3=0000000009c58000 CR4=000010a0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000d01
Triple fault

Dump of assembler code for function early_idt_handler_array:
   0xffffffff84bb3000 <+0>:     pushq  $0x0
   0xffffffff84bb3002 <+2>:     pushq  $0x0
   0xffffffff84bb3004 <+4>:     jmpq   0xffffffff84bb3120 <early_idt_handler_common>
   0xffffffff84bb3009 <+9>:     pushq  $0x0
   0xffffffff84bb300b <+11>:    pushq  $0x1
   0xffffffff84bb300d <+13>:    jmpq   0xffffffff84bb3120 <early_idt_handler_common>
   0xffffffff84bb3012 <+18>:    pushq  $0x0
   0xffffffff84bb3014 <+20>:    pushq  $0x2
   0xffffffff84bb3016 <+22>:    jmpq   0xffffffff84bb3120 <early_idt_handler_common>
   0xffffffff84bb301b <+27>:    pushq  $0x0
   0xffffffff84bb301d <+29>:    pushq  $0x3
   0xffffffff84bb301f <+31>:    jmpq   0xffffffff84bb3120 <early_idt_handler_common>
   0xffffffff84bb3024 <+36>:    pushq  $0x0
   0xffffffff84bb3026 <+38>:    pushq  $0x4
   0xffffffff84bb3028 <+40>:    jmpq   0xffffffff84bb3120 <early_idt_handler_common>
   0xffffffff84bb302d <+45>:    pushq  $0x0
   0xffffffff84bb302f <+47>:    pushq  $0x5
   0xffffffff84bb3031 <+49>:    jmpq   0xffffffff84bb3120 <early_idt_handler_common>
=> 0xffffffff84bb3036 <+54>:    pushq  $0x0
   0xffffffff84bb3038 <+56>:    pushq  $0x6
   0xffffffff84bb303a <+58>:    jmpq   0xffffffff84bb3120 <early_idt_handler_common>
   0xffffffff84bb303f <+63>:    pushq  $0x0
   0xffffffff84bb3041 <+65>:    pushq  $0x7
   0xffffffff84bb3043 <+67>:    jmpq   0xffffffff84bb3120 <early_idt_handler_common>
   0xffffffff84bb3048 <+72>:    pushq  $0x8
   0xffffffff84bb304a <+74>:    jmpq   0xffffffff84bb3120 <early_idt_handler_common>
   0xffffffff84bb304f <+79>:    int3
   0xffffffff84bb3050 <+80>:    int3
...

-- 
 Kirill A. Shutemov

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

#1685119

FromAndy Lutomirski <luto@kernel.org>
Date2017-07-11 17:10 +0200
Message-ID<u24Xw-3TD-25@gated-at.bofh.it>
In reply to#1684947
On Tue, Jul 11, 2017 at 3:35 AM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Mon, Jul 10, 2017 at 05:30:38PM -0700, Andy Lutomirski wrote:
>> On Mon, Jul 10, 2017 at 2:24 PM, Kirill A. Shutemov
>> <kirill@shutemov.name> wrote:
>> > On Mon, Jul 10, 2017 at 01:07:13PM -0700, Andy Lutomirski wrote:
>> >> Can you give the disassembly of the backtrace lines?  Blaming the
>> >> .endr doesn't make much sense to me.
>> >
>> > I don't have backtrace. It's before printk() is functional. I only see
>> > triple fault and reboot.
>> >
>> > I had to rely on qemu tracing and gdb.
>>
>> Can you ask GDB or objtool to disassemble around those addresses?  Can
>> you also attach the big dump that QEMU throws out that shows register
>> state?  In particular, CR2, CR3, and CR4 could be useful.
>
> The last three execptions:
>
> check_exception old: 0xffffffff new 0xe, cr2: 0xffffffff7ffffff8, rip: 0xffffffff84bb3036
> RAX=00000000ffffffff RBX=ffffffff800000d8 RCX=ffffffff84be4021 RDX=dffffc0000000000
> RSI=0000000000000006 RDI=ffffffff84c57000 RBP=ffffffff800000c8 RSP=ffffffff80000000

So RSP was 0xffffffff80000000, a push happened, and we tried to write
to 0xffffffff7ffffff8, which failed.

> check_exception old: 0xe new 0xe, cr2: 0xffffffff7ffffff8, rip: 0xffffffff84bb3141
> RAX=00000000ffffffff RBX=ffffffff800000d8 RCX=ffffffff84be4021 RDX=dffffc0000000000
> RSI=0000000000000006 RDI=ffffffff84c57000 RBP=ffffffff800000c8 RSP=ffffffff80000000

And #PF doesn't use IST, so it double-faulted.

Either the stack isn't mapped in the page tables, RSP is corrupt, or
there's a genuine stack overflow here.

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

#1685218

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2017-07-11 19:10 +0200
Message-ID<u26PE-56j-27@gated-at.bofh.it>
In reply to#1685119
On Tue, Jul 11, 2017 at 07:45:48PM +0300, Andrey Ryabinin wrote:
> On 07/11/2017 06:15 PM, Andrey Ryabinin wrote:
> > 
> > I reproduced this, and this is kasan bug:
> > 
> >    │0xffffffff84864897 <x86_early_init_platform_quirks+5>   mov    $0xffffffff83f1d0b8,%rdi 
> >    │0xffffffff8486489e <x86_early_init_platform_quirks+12>  movabs $0xdffffc0000000000,%rax 
> >    │0xffffffff848648a8 <x86_early_init_platform_quirks+22>  push   %rbp
> >    │0xffffffff848648a9 <x86_early_init_platform_quirks+23>  mov    %rdi,%rdx  
> >    │0xffffffff848648ac <x86_early_init_platform_quirks+26>  shr    $0x3,%rdx
> >    │0xffffffff848648b0 <x86_early_init_platform_quirks+30>  mov    %rsp,%rbp
> >   >│0xffffffff848648b3 <x86_early_init_platform_quirks+33>  mov    (%rdx,%rax,1),%al
> > 
> > we crash on the last move which is a read from shadow
> 
> 
> Ughh, I forgot about phys_base.

Thanks! Works for me.

Can use your Signed-off-by for a [cleaned up version of your] patch?


-- 
 Kirill A. Shutemov

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

#1685300

From"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Date2017-07-11 21:10 +0200
Message-ID<u28HM-6hz-15@gated-at.bofh.it>
In reply to#1685218
> > Can use your Signed-off-by for a [cleaned up version of your] patch?
> 
> Sure.

Another KASAN-releated issue: dumping page tables for KASAN shadow memory
region takes unreasonable time due to kasan_zero_p?? mapped there.

The patch below helps. Any objections?

diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index b371ab68f2d4..8601153c34e7 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -17,8 +17,8 @@
 #include <linux/init.h>
 #include <linux/sched.h>
 #include <linux/seq_file.h>
+#include <linux/kasan.h>
 
-#include <asm/kasan.h>
 #include <asm/pgtable.h>
 
 /*
@@ -291,10 +291,15 @@ static void note_page(struct seq_file *m, struct pg_state *st,
 static void walk_pte_level(struct seq_file *m, struct pg_state *st, pmd_t addr, unsigned long P)
 {
 	int i;
+	unsigned long pte_addr;
 	pte_t *start;
 	pgprotval_t prot;
 
-	start = (pte_t *)pmd_page_vaddr(addr);
+	pte_addr = pmd_page_vaddr(addr);
+	if (__pa(pte_addr) == __pa(kasan_zero_pte))
+		return;
+
+	start = (pte_t *)pte_addr;
 	for (i = 0; i < PTRS_PER_PTE; i++) {
 		prot = pte_flags(*start);
 		st->current_address = normalize_addr(P + i * PTE_LEVEL_MULT);
@@ -308,10 +313,15 @@ static void walk_pte_level(struct seq_file *m, struct pg_state *st, pmd_t addr,
 static void walk_pmd_level(struct seq_file *m, struct pg_state *st, pud_t addr, unsigned long P)
 {
 	int i;
+	unsigned long pmd_addr;
 	pmd_t *start;
 	pgprotval_t prot;
 
-	start = (pmd_t *)pud_page_vaddr(addr);
+	pmd_addr = pud_page_vaddr(addr);
+	if (__pa(pmd_addr) == __pa(kasan_zero_pmd))
+		return;
+
+	start = (pmd_t *)pmd_addr;
 	for (i = 0; i < PTRS_PER_PMD; i++) {
 		st->current_address = normalize_addr(P + i * PMD_LEVEL_MULT);
 		if (!pmd_none(*start)) {
@@ -350,12 +360,16 @@ static bool pud_already_checked(pud_t *prev_pud, pud_t *pud, bool checkwx)
 static void walk_pud_level(struct seq_file *m, struct pg_state *st, p4d_t addr, unsigned long P)
 {
 	int i;
+	unsigned long pud_addr;
 	pud_t *start;
 	pgprotval_t prot;
 	pud_t *prev_pud = NULL;
 
-	start = (pud_t *)p4d_page_vaddr(addr);
+	pud_addr = p4d_page_vaddr(addr);
+	if (__pa(pud_addr) == __pa(kasan_zero_pud))
+		return;
 
+	start = (pud_t *)pud_addr;
 	for (i = 0; i < PTRS_PER_PUD; i++) {
 		st->current_address = normalize_addr(P + i * PUD_LEVEL_MULT);
 		if (!pud_none(*start) &&
@@ -386,11 +400,15 @@ static void walk_pud_level(struct seq_file *m, struct pg_state *st, p4d_t addr,
 static void walk_p4d_level(struct seq_file *m, struct pg_state *st, pgd_t addr, unsigned long P)
 {
 	int i;
+	unsigned long p4d_addr;
 	p4d_t *start;
 	pgprotval_t prot;
 
-	start = (p4d_t *)pgd_page_vaddr(addr);
+	p4d_addr = pgd_page_vaddr(addr);
+	if (__pa(p4d_addr) == __pa(kasan_zero_p4d))
+		return;
 
+	start = (p4d_t *)p4d_addr;
 	for (i = 0; i < PTRS_PER_P4D; i++) {
 		st->current_address = normalize_addr(P + i * P4D_LEVEL_MULT);
 		if (!p4d_none(*start)) {
-- 
 Kirill A. Shutemov

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

#1686541

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2017-07-13 16:00 +0200
Message-ID<u2MOR-6jw-5@gated-at.bofh.it>
In reply to#1685300
On Thu, Jul 13, 2017 at 03:58:29PM +0300, Andrey Ryabinin wrote:
> On 07/11/2017 10:05 PM, Kirill A. Shutemov wrote:
> >>> Can use your Signed-off-by for a [cleaned up version of your] patch?
> >>
> >> Sure.
> > 
> > Another KASAN-releated issue: dumping page tables for KASAN shadow memory
> > region takes unreasonable time due to kasan_zero_p?? mapped there.
> > 
> > The patch below helps. Any objections?
> > 
> 
> Well, page tables dump doesn't work at all on 5-level paging.
> E.g. I've got this nonsense: 
> 
> ....
> ---[ Kernel Space ]---
> 0xffff800000000000-0xffff808000000000         512G                               pud
> ---[ Low Kernel Mapping ]---
> 0xffff808000000000-0xffff810000000000         512G                               pud
> ---[ vmalloc() Area ]---
> 0xffff810000000000-0xffff818000000000         512G                               pud
> ---[ Vmemmap ]---
> 0xffff818000000000-0xffffff0000000000      128512G                               pud
> ---[ ESPfix Area ]---
> 0xffffff0000000000-0x0000000000000000           1T                               pud
> 0x0000000000000000-0x0000000000000000           0E                               pgd
> 0x0000000000000000-0x0000000000001000           4K     RW     PCD         GLB NX pte
> 0x0000000000001000-0x0000000000002000           4K                               pte
> 0x0000000000002000-0x0000000000003000           4K     ro                 GLB NX pte
> 0x0000000000003000-0x0000000000004000           4K                               pte
> 0x0000000000004000-0x0000000000007000          12K     RW                 GLB NX pte
> 0x0000000000007000-0x0000000000008000           4K                               pte
> 0x0000000000008000-0x0000000000108000           1M     RW                 GLB NX pte
> 0x0000000000108000-0x0000000000109000           4K                               pte
> 0x0000000000109000-0x0000000000189000         512K     RW                 GLB NX pte
> 0x0000000000189000-0x000000000018a000           4K                               pte
> 0x000000000018a000-0x000000000018e000          16K     RW                 GLB NX pte
> 0x000000000018e000-0x000000000018f000           4K                               pte
> 0x000000000018f000-0x0000000000193000          16K     RW                 GLB NX pte
> 0x0000000000193000-0x0000000000194000           4K                               pte
> ... 304 entries skipped ... 
> ---[ EFI Runtime Services ]---
> 0xffffffef00000000-0xffffffff80000000          66G                               pud
> ---[ High Kernel Mapping ]---
> 0xffffffff80000000-0xffffffffc0000000           1G                               pud
> ...

Hm. I don't see this:

...
[    0.247532] 0xff9e938000000000-0xff9f000000000000      111104G                               p4d
[    0.247733] 0xff9f000000000000-0xffff000000000000          24P                               pgd
[    0.248066] 0xffff000000000000-0xffffff0000000000         255T                               p4d
[    0.248290] ---[ ESPfix Area ]---
[    0.248393] 0xffffff0000000000-0xffffff8000000000         512G                               p4d
[    0.248663] 0xffffff8000000000-0xffffffef00000000         444G                               pud
[    0.248892] ---[ EFI Runtime Services ]---
[    0.248996] 0xffffffef00000000-0xfffffffec0000000          63G                               pud
[    0.249308] 0xfffffffec0000000-0xfffffffefe400000         996M                               pmd
...

Do you have commit "x86/dump_pagetables: Generalize address normalization"
in your tree?

https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/commit/?h=la57/boot-switching/v2&id=13327fec85ffe95d9c8a3f57ba174bf5d5c1fb01

> As for KASAN, I think it would be better just to make it work faster,
> the patch below demonstrates the idea.

Okay, let me test this.

> ---
>  arch/x86/mm/dump_pagetables.c | 22 ++++++++++++++++------
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
> index 0470826d2bdc..36515fba86b0 100644
> --- a/arch/x86/mm/dump_pagetables.c
> +++ b/arch/x86/mm/dump_pagetables.c
> @@ -13,6 +13,7 @@
>   */
>  
>  #include <linux/debugfs.h>
> +#include <linux/kasan.h>
>  #include <linux/mm.h>
>  #include <linux/init.h>
>  #include <linux/sched.h>

<asm/kasan.h> can be dropped. And I don't think it compiles with KASAN
disabled.

For reference, the patch I use now:

https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/commit/?h=la57/boot-switching/v2&id=c4b1439f719b1689a1cfca9c0df17b9f8b8462b9

-- 
 Kirill A. Shutemov

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

#1686568

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2017-07-13 16:20 +0200
Message-ID<u2N8f-6Ff-37@gated-at.bofh.it>
In reply to#1686541
On Thu, Jul 13, 2017 at 04:52:28PM +0300, Kirill A. Shutemov wrote:
> On Thu, Jul 13, 2017 at 03:58:29PM +0300, Andrey Ryabinin wrote:
> > On 07/11/2017 10:05 PM, Kirill A. Shutemov wrote:
> > >>> Can use your Signed-off-by for a [cleaned up version of your] patch?
> > >>
> > >> Sure.
> > > 
> > > Another KASAN-releated issue: dumping page tables for KASAN shadow memory
> > > region takes unreasonable time due to kasan_zero_p?? mapped there.
> > > 
> > > The patch below helps. Any objections?
> > > 
> > 
> > Well, page tables dump doesn't work at all on 5-level paging.
> > E.g. I've got this nonsense: 
> > 
> > ....
> > ---[ Kernel Space ]---
> > 0xffff800000000000-0xffff808000000000         512G                               pud
> > ---[ Low Kernel Mapping ]---
> > 0xffff808000000000-0xffff810000000000         512G                               pud
> > ---[ vmalloc() Area ]---
> > 0xffff810000000000-0xffff818000000000         512G                               pud
> > ---[ Vmemmap ]---
> > 0xffff818000000000-0xffffff0000000000      128512G                               pud
> > ---[ ESPfix Area ]---
> > 0xffffff0000000000-0x0000000000000000           1T                               pud
> > 0x0000000000000000-0x0000000000000000           0E                               pgd
> > 0x0000000000000000-0x0000000000001000           4K     RW     PCD         GLB NX pte
> > 0x0000000000001000-0x0000000000002000           4K                               pte
> > 0x0000000000002000-0x0000000000003000           4K     ro                 GLB NX pte
> > 0x0000000000003000-0x0000000000004000           4K                               pte
> > 0x0000000000004000-0x0000000000007000          12K     RW                 GLB NX pte
> > 0x0000000000007000-0x0000000000008000           4K                               pte
> > 0x0000000000008000-0x0000000000108000           1M     RW                 GLB NX pte
> > 0x0000000000108000-0x0000000000109000           4K                               pte
> > 0x0000000000109000-0x0000000000189000         512K     RW                 GLB NX pte
> > 0x0000000000189000-0x000000000018a000           4K                               pte
> > 0x000000000018a000-0x000000000018e000          16K     RW                 GLB NX pte
> > 0x000000000018e000-0x000000000018f000           4K                               pte
> > 0x000000000018f000-0x0000000000193000          16K     RW                 GLB NX pte
> > 0x0000000000193000-0x0000000000194000           4K                               pte
> > ... 304 entries skipped ... 
> > ---[ EFI Runtime Services ]---
> > 0xffffffef00000000-0xffffffff80000000          66G                               pud
> > ---[ High Kernel Mapping ]---
> > 0xffffffff80000000-0xffffffffc0000000           1G                               pud
> > ...
> 
> Hm. I don't see this:
> 
> ...
> [    0.247532] 0xff9e938000000000-0xff9f000000000000      111104G                               p4d
> [    0.247733] 0xff9f000000000000-0xffff000000000000          24P                               pgd
> [    0.248066] 0xffff000000000000-0xffffff0000000000         255T                               p4d
> [    0.248290] ---[ ESPfix Area ]---
> [    0.248393] 0xffffff0000000000-0xffffff8000000000         512G                               p4d
> [    0.248663] 0xffffff8000000000-0xffffffef00000000         444G                               pud
> [    0.248892] ---[ EFI Runtime Services ]---
> [    0.248996] 0xffffffef00000000-0xfffffffec0000000          63G                               pud
> [    0.249308] 0xfffffffec0000000-0xfffffffefe400000         996M                               pmd
> ...
> 
> Do you have commit "x86/dump_pagetables: Generalize address normalization"
> in your tree?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/commit/?h=la57/boot-switching/v2&id=13327fec85ffe95d9c8a3f57ba174bf5d5c1fb01
> 
> > As for KASAN, I think it would be better just to make it work faster,
> > the patch below demonstrates the idea.
> 
> Okay, let me test this.

The patch works for me.

The problem is not exclusive to 5-level paging, so could you prepare and
push proper patch upstream?

-- 
 Kirill A. Shutemov

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web