linux-kernel - Re: linux/master crashes on boot with KASAN=y

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c13159f0-74d0-bab7-43e7-78434ead75c9@virtuozzo.com>
Date:   Tue, 26 Dec 2017 14:47:09 +0300
From:   Andrey Ryabinin <aryabinin@...tuozzo.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Jakub Kicinski <kubakici@...pl>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: linux/master crashes on boot with KASAN=y



On 12/24/2017 04:48 AM, Andy Lutomirski wrote:
> On Sat, Dec 23, 2017 at 4:41 AM, Andrey Ryabinin
> <aryabinin@...tuozzo.com> wrote:
>> On 12/23/2017 11:01 AM, Jakub Kicinski wrote:
>>> Hi!
>>>
>>> I bisected a crash on boot to this:
>>>
>>> commit 21506525fb8ddb0342f2a2370812d47f6a1f3833 (HEAD, refs/bisect/bad)
>>> Author: Andy Lutomirski <luto@...nel.org>
>>> Date:   Mon Dec 4 15:07:16 2017 +0100
>>>
>>>     x86/kasan/64: Teach KASAN about the cpu_entry_area
>>
>>
>> Thanks.
>> There is nothing wrong with this patch, it just uncovered older bug.
>> The actual problem comes from f06bdd4001c2 ("x86/mm: Adapt MODULES_END based on fixmap section size")
>> which is made kasan_mem_to_shadow(MODULES_END) potentially unaligned to page boundary.
>> And when we feed unaligned address to kasan_populate_zero_shadow() it doesn't do the right thing.
>>
>> Could you tell me if the fix bellow works for you?
>>
>> ---
>>  arch/x86/include/asm/kasan.h            | 8 ++++++++
>>  arch/x86/include/asm/pgtable_64_types.h | 4 +++-
>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
>> index b577dd0916aa..0c580e4b2ccc 100644
>> --- a/arch/x86/include/asm/kasan.h
>> +++ b/arch/x86/include/asm/kasan.h
>> @@ -5,6 +5,14 @@
>>  #include <linux/const.h>
>>  #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
>>
>> +#ifndef KASAN_SHADOW_SCALE_SHIFT
>> +# ifdef CONFIG_KASAN
>> +#  define KASAN_SHADOW_SCALE_SHIFT 3
>> +# else
>> +#  define KASAN_SHADOW_SCALE_SHIFT 0
>> +# endif
>> +#endif
>> +
>>  /*
>>   * Compiler uses shadow offset assuming that addresses start
>>   * from 0. Kernel addresses don't start from 0, so shadow
>> diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
>> index 6d5f45dcd4a1..d34a90d6c374 100644
>> --- a/arch/x86/include/asm/pgtable_64_types.h
>> +++ b/arch/x86/include/asm/pgtable_64_types.h
>> @@ -6,6 +6,7 @@
>>
>>  #ifndef __ASSEMBLY__
>>  #include <linux/types.h>
>> +#include <asm/kasan.h>
>>  #include <asm/kaslr.h>
>>
>>  /*
>> @@ -96,7 +97,8 @@ typedef struct { pteval_t pte; } pte_t;
>>  #define VMALLOC_END    (VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
>>  #define MODULES_VADDR    (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
>>  /* The module sections ends with the start of the fixmap */
>> -#define MODULES_END   __fix_to_virt(__end_of_fixed_addresses + 1)
>> +#define MODULES_END   (__fix_to_virt(__end_of_fixed_addresses + 1) & \
>> +                       ~((PAGE_SIZE << KASAN_SHADOW_SCALE_SHIFT) - 1))
> 
> Could this be #define MODULES_END KASAN_ROUND_DOWN(__fix_to_virt(...)) instead?
> 

Actually, we could simply set fixed MODULES_END, as it was before f06bdd4001c2 ("x86/mm: Adapt MODULES_END based on fixmap section size").
AFAICS, the whole point of f06bdd4001c2 was to move MODULES_END down if NR_CPUS is big.
But since 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the fixmap") cpu_entry_area is not in fixmap anymore.
So it should be fine to set fixed MODULES_END.

The only concern I have is 4.14 stable, where 21506525f ("x86/kasan/64: Teach KASAN about the cpu_entry_area") was backported.
Is 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the fixmap") also a candidate for stable?
If so, fixed MODULES_END seems like a better choice.