linux-ext4 - Re: [PATCH v3] Fix ext4 fault handling when mounted with -o dax,ro

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, 24 Aug 2017 09:01:44 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     rdodgen@...il.com
Cc:     tytso@....edu, linux-ext4@...r.kernel.org,
        ross.zwisler@...ux.intel.com, Randy Dodgen <dodgen@...gle.com>,
        linux-nvdimm@...ts.01.org
Subject: Re: [PATCH v3] Fix ext4 fault handling when mounted with -o dax,ro

On Wed, Aug 23, 2017 at 02:26:52PM -0700, rdodgen@...il.com wrote:
> From: Randy Dodgen <dodgen@...gle.com>
> 
> If an ext4 filesystem is mounted with both the DAX and read-only
> options, executables on that filesystem will fail to start (claiming
> 'Segmentation fault') due to the fault handler returning
> VM_FAULT_SIGBUS.
> 
> This is due to the DAX fault handler (see ext4_dax_huge_fault)
> attempting to write to the journal when FAULT_FLAG_WRITE is set. This is
> the wrong behavior for write faults which will lead to a COW page; in
> particular, this fails for readonly mounts.
> 
> This change avoids journal writes for faults that are expected to COW.
> 
> It might be the case that this could be better handled in
> ext4_iomap_begin / ext4_iomap_end (called via iomap_ops inside
> dax_iomap_fault). These is some overlap already (e.g. grabbing journal
> handles).
> 
> Signed-off-by: Randy Dodgen <dodgen@...gle.com>
> ---
> 
> This version is simplified as suggested by Ross; all fault sizes and fallbacks
> are handled by dax_iomap_fault.

We really need to do the same for ext2 and xfs.  And we really should
be doing that in common VM code instead of the file system.  See
my recent xfs synchronous page fault series on the mess the inconsistent
handling of the FAULT_FLAG_WRITE causes.  I think we just need a new
FAULT_FLAG_ALLOC or similar for those page faults that needs to
allocate space instead of piling hacks over hacks, and make sure
it's only set over the method that will actually do the allocation,
as the DAX and non-DAX path are not consistent on that.

Also any chance you could write an xfstest for this?