| 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
| ||
|
Message-id: <55B66FC5.30406@samsung.com>
Date: Mon, 27 Jul 2015 20:52:05 +0300
From: Andrey Ryabinin <a.ryabinin@...sung.com>
To: Yury <yury.norov@...il.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
linux-arm-kernel@...ts.infradead.org,
Alexey Klimov <klimov.linux@...il.com>,
Arnd Bergmann <arnd@...db.de>, linux-mm@...ck.org,
Linus Walleij <linus.walleij@...aro.org>, x86@...nel.org,
linux-kernel@...r.kernel.org,
David Keitel <dkeitel@...eaurora.org>,
Ingo Molnar <mingo@...hat.com>,
Alexander Potapenko <glider@...gle.com>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [PATCH v4 2/7] mm: kasan: introduce generic
kasan_populate_zero_shadow()
On 07/27/2015 05:23 PM, Yury wrote:
>> +
>> +#if CONFIG_PGTABLE_LEVELS > 3
>> +pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
>> +#endif
>> +#if CONFIG_PGTABLE_LEVELS > 2
>> +pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
>> +#endif
>
> You declare kasan_zero_pud and kasan_zero_pmd conditionally now, but use
> unconditionally, at least in kasan_init in patch #5. If I'm not missing
> something, this is wrong...
>
These are used conditionally. E.g. pgd_populate() is nop if we have 2 or 3-level page tables
kasan_zero_pud will be unused (otherwise this wouldn't compile).
>> +pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
>> +
>> +static __init void *early_alloc(size_t size, int node)
>> +{
>> + return memblock_virt_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
>> + BOOTMEM_ALLOC_ACCESSIBLE, node);
>> +}
>> +
>> +static void __init zero_pte_populate(pmd_t *pmd, unsigned long addr,
>> + unsigned long end)
>> +{
>> + pte_t *pte = pte_offset_kernel(pmd, addr);
>> + pte_t zero_pte;
>> +
>> + zero_pte = pfn_pte(PFN_DOWN(__pa(kasan_zero_page)), PAGE_KERNEL);
>> + zero_pte = pte_wrprotect(zero_pte);
>> +
>> + while (addr + PAGE_SIZE <= end) {
>> + set_pte_at(&init_mm, addr, pte, zero_pte);
>> + addr += PAGE_SIZE;
>> + pte = pte_offset_kernel(pmd, addr);
>> + }
>> +}
>> +
>> +static void __init zero_pmd_populate(pud_t *pud, unsigned long addr,
>> + unsigned long end)
>
> Functions zero_pmd_populate, zero_pud_populate and kasan_populate_zero_shadow
> are suspiciously similar. I think we can isolate common pieces to helpers to
> reduce code duplication and increase readability...
>
I don't see how we could reduce duplication without hurting readability.
>> +{
>> + pmd_t *pmd = pmd_offset(pud, addr);
>> + unsigned long next;
>> +
>> + do {
>> + next = pmd_addr_end(addr, end);
>> +
>> + if (IS_ALIGNED(addr, PMD_SIZE) && end - addr >= PMD_SIZE) {
>
> This line is repeated 3 times. For me, it's more than enough to
> wrap it to helper (if something similar does not exist somewhere):
> static inline is_whole_entry(unsigned long start, unsigned long end, unsigned long size);
>
This is quite trivial one line condition, I don't think we need helper for this.
And is_whole_entry() looks like a bad name for such function.
>> + pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
>> + continue;
>> + }
>> +
>> + if (pmd_none(*pmd)) {
>> + pmd_populate_kernel(&init_mm, pmd,
>> + early_alloc(PAGE_SIZE, NUMA_NO_NODE));
>> + }
>> + zero_pte_populate(pmd, addr, next);
>> + } while (pmd++, addr = next, addr != end);
>> +}
>> +
>> +static void __init zero_pud_populate(pgd_t *pgd, unsigned long addr,
>> + unsigned long end)
>> +{
>> + pud_t *pud = pud_offset(pgd, addr);
>> + unsigned long next;
>> +
>> + do {
>> + next = pud_addr_end(addr, end);
>> + if (IS_ALIGNED(addr, PUD_SIZE) && end - addr >= PUD_SIZE) {
>> + pmd_t *pmd;
>> +
>> + pud_populate(&init_mm, pud, kasan_zero_pmd);
>> + pmd = pmd_offset(pud, addr);
>> + pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
>
> This three lines are repeated in kasan_populate_zero_shadow()
> So, maybe you'd wrap it with some
> 'pud_zero_populate_whole_pmd(pud, addr)'?
>
And I'm also disagree here. This doesn't even save any LOC, and
reviewer will have too look into this "pud_zero_populate_whole_pmd()"
to understand what it does (It's not clear from function's name).
So I think this will be worse than current code.
>> + continue;
>> + }
>> +
>> + if (pud_none(*pud)) {
>> + pud_populate(&init_mm, pud,
>> + early_alloc(PAGE_SIZE, NUMA_NO_NODE));
>> + }
>> + zero_pmd_populate(pud, addr, next);
>> + } while (pud++, addr = next, addr != end);
>> +}
>> +
>> +/**
>> + * kasan_populate_zero_shadow - populate shadow memory region with
>> + * kasan_zero_page
>> + * @from - start of the memory range to populate
>> + * @to - end of the memory range to populate
>
> In description and here in comment you underline that 1st parameter is
> start, and second is end. But you name them finally 'from' and 'to', and
> for me this names are confusing. And for you too, in so far as you add
> comment explaining it.
>
Right, I forgot to update commit description.
> I'm not insisting, but why don't you give parameters
> more straight names? (If you are worrying about internal vars naming conflict,
> just use '_start' and '_end' for them.)
>
Yes, I choose 'from', 'to' to avoid conflict with internal end variable.
But don't like this 'from', 'to', as I'm also don't like underscores, so
I think it would be better to name parameters as 'shadow_start' and 'shadow_end'.
Pretty clear and no conflicts.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists