linux-kernel - Re: [PATCH v1 1/1] mm: buddy page accessed before initialized

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] [day] [month] [year] [list]

Date:   Fri, 3 Nov 2017 10:17:57 -0400
From:   Pavel Tatashin <pasha.tatashin@...cle.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Steve Sistare <steven.sistare@...cle.com>,
        Daniel Jordan <daniel.m.jordan@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        mgorman@...hsingularity.net,
        Linux Memory Management List <linux-mm@...ck.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/1] mm: buddy page accessed before initialized

> Why cannot we do something similar to the optimized struct page
> initialization and write 8B at the time and fill up the size unaligned
> chunk in 1B?

I do not think this is a good idea: memset() on SPARC is slow for
small sizes, this is why we ended up using stores, but thats not the
case on x86 where memset() is well optimized for small sizes. So, I
believe we will see regressions. But even without the regressions
there are several reasons why I think this is not a good idea:
1. struct page size vary depending on configs. So, in order to create
a pattern that looks like a valid struct page, we would need to figure
out what is our struct page size.
2. memblock allocator is totally independent from struct pages, it is
going to be strange to add this dependency. The allocatoted memory is
also used for page tables, and kasan, so we do not really know where
the pattern should start from the allocator point of view.
3. It is going to be too easy to break that pattern if something
changes or shifts: struct page changes, vmemmap allocations change or
anything else.

Overall, I think now we have a good coverage now: CONFIG_DEBUG_VM
option tests for totally invalid struct pages, and kexec tests for
struct pages that look like valid ones, but they are invalid because
from the previous instance of kernel.

Pasha