linux-kernel - Re: [PATCH 0/1] x86: restore the write back cache of reserved RAM in iounmap()

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, 19 Nov 2020 14:03:58 -0500
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Rafael Aquini <aquini@...hat.com>,
        Waiman Long <longman@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/1] x86: restore the write back cache of reserved RAM in
 iounmap()

Hello Christoph,

On Thu, Nov 19, 2020 at 06:02:06PM +0000, Christoph Hellwig wrote:
> What is the callers?  The whole SetPageReservered + ioremap* thing
> you mention in the actual patch is completely bogus.  I think we'll
> need to reject that as well and fix the caller.

The actual caller is not so much the focus here: the point here is to
be able to either handle the caller gracefully or to get a synchronous
kernel crash in __free_pages.

Otherwise the problem induced by such a caller (no matter if right or
wrong) becomes hardly debuggable.

The caller in question was the EFI_BOOT_SERVICE_DATA that is aliased
on non RAM but then freed later by swapping RAM under it.

Of course the caller has already been changed to stick to write back
and that specific caller is not a concern anymore. My concern is if we
leave the callee (iounmap) as it is, what does guarantee us that we
won't hit again in production a few years down the road?

When I first read the caller it felt nothing should have gone wrong,
it looked ok even the version that would leave PCD leftovers bits in
the direct map. So I didn't get why switching to write back would
prevent the PCD leftovers until I looked at the callee (iounmap).

Thanks,
Andrea