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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 03 Sep 2018 12:25:10 +1000
From:   Benjamin Herrenschmidt <>
To:     Linus Torvalds <>
Cc:     Jiri Kosina <>,
        Jürgen Groß <>,
        Linux Kernel Mailing List <>,
        Michal Hocko <>,
        Naoya Horiguchi <>,
        Michael Ellerman <>,
        Will Deacon <>
Subject: Re: Access to non-RAM pages

On Sun, 2018-09-02 at 19:10 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
> <> 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).

Ah, my bad reading, I was looking at read_word_at_a_time() instead of
load_unaligned_zeropad(). I'm not familiar enough with the dentry qstr
stuff, I assume this is safe ?

> 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.

Powered by blists - more mailing lists