netdev - Re: [PATCH 1/2] vmalloc: New flag for flush before releasing pages

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]

Date:   Thu, 6 Dec 2018 11:20:51 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Andrew Lutomirski <luto@...nel.org>,
        Will Deacon <will.deacon@....com>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>,
        Nadav Amit <nadav.amit@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Jessica Yu <jeyu@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Linux-MM <linux-mm@...ck.org>, Jann Horn <jannh@...gle.com>,
        "Dock, Deneen T" <deneen.t.dock@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Kristen Carlson Accardi <kristen@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ingo Molnar <mingo@...hat.com>,
        Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        "Naveen N . Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
        "David S. Miller" <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>,
        Dave Hansen <dave.hansen@...el.com>
Subject: Re: [PATCH 1/2] vmalloc: New flag for flush before releasing pages

On Thu, Dec 6, 2018 at 11:04 AM Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
>
> On Thu, 6 Dec 2018 at 19:54, Andy Lutomirski <luto@...nel.org> wrote:
> >

> > That’s not totally nuts. Do we ever have code that expects __va() to
> > work on module data?  Perhaps crypto code trying to encrypt static
> > data because our APIs don’t understand virtual addresses.  I guess if
> > highmem is ever used for modules, then we should be fine.
> >
>
> The crypto code shouldn't care, but I think it will probably break hibernate :-(

How so?  Hibernate works (or at least should work) on x86 PAE, where
__va doesn't work on module data, and, on x86, the direct map has some
RO parts with where the module is, so hibernate can't be writing to
the memory through the direct map with its final permissions.