linux-kernel - Re: [PATCH v6 1/5] vfs: add flags parameter to ->mmap() in 'struct file

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 10:42:09 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, Jan Kara <jack@...e.cz>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        David Airlie <airlied@...ux.ie>,
        Linux API <linux-api@...r.kernel.org>,
        Takashi Iwai <tiwai@...e.com>,
        Maling list - DRI developers 
        <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-xfs@...r.kernel.org, Julia Lawall <julia.lawall@...6.fr>,
        Andy Lutomirski <luto@...nel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Linux MM <linux-mm@...ck.org>
Subject: Re: [PATCH v6 1/5] vfs: add flags parameter to ->mmap() in 'struct file_operations'

On Thu, Aug 24, 2017 at 9:58 AM, Christoph Hellwig <hch@...radead.org> wrote:
> On Wed, Aug 23, 2017 at 04:48:40PM -0700, Dan Williams wrote:
>> We are running running short of vma->vm_flags. We can avoid needing a
>> new VM_* flag in some cases if the original @flags submitted to mmap(2)
>> is made available to the ->mmap() 'struct file_operations'
>> implementation. For example, the proposed addition of MAP_DIRECT can be
>> implemented without taking up a new vm_flags bit. Another motivation to
>> avoid vm_flags is that they appear in /proc/$pid/smaps, and we have seen
>> software that tries to dangerously (TOCTOU) read smaps to infer the
>> behavior of a virtual address range.
>>
>> This conversion was performed by the following semantic patch. There
>> were a few manual edits for oddities like proc_reg_mmap.
>>
>> Thanks to Julia for helping me with coccinelle iteration to cover cases
>> where the mmap routine is defined in a separate file from the 'struct
>> file_operations' instance that consumes it.
>
> How are we going to check that an instance actually supports any
> of those flags?

In patch 3 I validate the flags by introducing an
"mmap_supported_mask" field to 'struct file_operations'. It will be
zero by default for almost all implementations and zero means "support
the legacy mmap flags".