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+55aFyqpg_e8dXZWhdyVLa0xSYcK6iuRTKDXxnFLaFEcqZHkQ@mail.gmail.com>
Date:   Sat, 1 Sep 2018 10:27:39 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     Jürgen Groß <jgross@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michal Hocko <mhocko@...e.com>
Subject: Re: Access to non-RAM pages

On Fri, Aug 31, 2018 at 2:18 PM Jiri Kosina <jikos@...nel.org> wrote:
>
> If noone has any clever idea how to work this around (I don't), I am
> afraid we'd have to ditch the whole DCACHE_WORD_ACCESS optimization, as
> it's silently dangerous.

No way in hell will I apply such a stupid patch.

It is NOT dangerous.

If you have a machine with RAM that touches IO, you need to disable
the last page, exactly the same way we disable and marked reserved the
first page at zero.

I thought we already did that.

I suspect this is a Xen bug, where the fake BIOS sets up a garbage
description of the hardware that is simply not realistic. I don't
think I've ever seen a machine that didn't have some reserved memory
at the top, but hey, if we don't expressly mark the last page reserved
already, doing so should be trivial.

No way do we disable the word accesses just because of some crazy
corner case that doesn't matter and doesn't happen in reality.

               Linus