linux-kernel - Re: Access to non-RAM 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]

Message-ID: <CA+55aFyhq23ce94Vq_XdCJSOKvo8oYnb2UOdjf-KVaaOFngr+g@mail.gmail.com>
Date:   Sun, 2 Sep 2018 19:10:46 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Jürgen Groß <jgross@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michal Hocko <mhocko@...e.com>,
        Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Will Deacon <will.deacon@....com>
Subject: Re: Access to non-RAM pages

On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
<benh@...nel.crashing.org> wrote:
>
> Still, I can potentially see an issue with DEBUG_PAGEALLOC

An unmapped page isn't a problem. That's what the whole
load_unaligned_zeropad() is about: it's ok to take a fault on the part
that crosses a page, and we'll just fill the value with zeroes (that's
the "zeropad" part).

So as long as it's rare (and it is), it's all fine.

That said, I think we turn off for DEBUG_PAGEALLOC simply because it's
not rare _enough_.

And vmalloc() should actually be safe too, simply because I think we
strive for a guard page between vmalloc areas.

So only a *mapped* page after the page that matters, and only if it's
something you can't read without side effects.

Which basically doesn't happen on x86 in reality. BIOSes just don't
put MMIO right after the last page of RAM. I think this is why it only
triggered on Xen, due to some crazy "Xen reacts badly" case where we
do the speculation into a balloon address.

So _practically_ this is just a Xen bug, nothing more.

But since in _theory_ you could have MMIO abut regular RAM directly,
it's worth maybe making sure it's purely theory.

            Linus