linux-kernel - Re: [RFC v8 PATCH 3/5] mm: mmap: zap pages with read mmap

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: <3c62f605-2244-6a05-2dc4-34a3f1c56300@linux.alibaba.com>
Date:   Wed, 22 Aug 2018 13:45:44 -0700
From:   Yang Shi <yang.shi@...ux.alibaba.com>
To:     Vlastimil Babka <vbabka@...e.cz>, mhocko@...nel.org,
        willy@...radead.org, ldufour@...ux.vnet.ibm.com,
        kirill@...temov.name, akpm@...ux-foundation.org,
        peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
        alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
        namhyung@...nel.org
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC v8 PATCH 3/5] mm: mmap: zap pages with read mmap_sem in
 munmap

On 8/22/18 4:19 AM, Vlastimil Babka wrote:
> On 08/15/2018 08:49 PM, Yang Shi wrote:
>> +	downgrade_write(&mm->mmap_sem);
>> +
>> +	/* Zap mappings with read mmap_sem */
>> +	unmap_region(mm, start_vma, prev, start, end);
>> +
>> +	arch_unmap(mm, start_vma, start, end);
> Hmm, did you check that all architectures' arch_unmap() is safe with
> read mmap_sem instead of write mmap_sem? E.g. x86 does
> mpx_notify_unmap() there where I would be far from sure at first glance...

Yes, I'm also not quite sure if it is 100% safe or not. I was trying to 
move this before downgrade_write, however, I'm not sure if it is ok or 
not too, so I keep the calling sequence.

For architectures, just x86 and ppc really do something. PPC just uses 
it for vdso unmap which should just happen during process exit, so it 
sounds safe.

For x86, mpx_notify_unmap() looks finally zap the VM_MPX vmas in bound 
table range with zap_page_range() and doesn't update vm flags, so it 
sounds ok to me since vmas have been detached, nobody can find those 
vmas. But, I'm not familiar with the details of mpx, maybe Kirill could 
help to confirm this?

Thanks,
Yang

>
>> +	remove_vma_list(mm, start_vma);
>> +	up_read(&mm->mmap_sem);