linux-kernel - Re: [PATCH v2] mm: access to uninitialized struct page

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]

Message-ID: <CAGM2reauOET_PUPA94WXhjKgL1cUHcKyY+R+auxvTfd4srhaFw@mail.gmail.com>
Date:   Tue, 08 May 2018 14:44:51 +0000
From:   Pavel Tatashin <pasha.tatashin@...cle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Steven Sistare <steven.sistare@...cle.com>,
        Daniel Jordan <daniel.m.jordan@...cle.com>,
        LKML <linux-kernel@...r.kernel.org>, tglx@...utronix.de,
        Michal Hocko <mhocko@...e.com>,
        Linux Memory Management List <linux-mm@...ck.org>,
        mgorman@...hsingularity.net, mingo@...nel.org,
        peterz@...radead.org, Steven Rostedt <rostedt@...dmis.org>,
        Fengguang Wu <fengguang.wu@...el.com>,
        Dennis Zhou <dennisszhou@...il.com>
Subject: Re: [PATCH v2] mm: access to uninitialized struct page

> Gulp.  Let's hope that nothing in mm_init() requires that trap_init()
> has been run.  What happens if something goes wrong during mm_init()
> and the architecture attempts to raise a software exception, hits a bus
> error, div-by-zero, etc, etc?  Might there be hard-to-discover
> dependencies in such a case?

Hi Andrew,

Unfortunately, mm_init() requires trap_init(). And, because trap_init() is
arch specific, I do not see a way to simply fix  trap_init(). So, we need
to find a different fix for the above problem. And, the current fix needs
to be removed from mm.

BTW, the bug was not introduced by:
c9e97a1997fb ("mm: initialize pages on demand during boot")

Fengguang Wu, reproduced this bug with builds prior to when this patch was
added. So, I think that while my patch may make this problem happen more
frequently, the problem itself is older. Basically, it depends on value of
KASLR.

One way to quickly fix this issue is to disable deferred struct pages when
the following combination is true:
CONFIG_RANDOMIZE_BASE && CONFIG_SPARSEMEM && !CONFIG_SPARSEMEM_VMEMMAP

RANDOMIZE_BASE means we do not know from what PFN struct pages are going to
be required before mm_init().
CONFIG_SPARSEMEM && !CONFIG_SPARSEMEM_VMEMMAP means that page_to_pfn() will
use information from page->flags to get section number, and thus require
accessing "struct pages"

Pavel