linux-kernel - Re: remap_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]

Message-ID: <CAAih0Nght-5k6mp-_jc+GipxPfxPYdCEabH_8M2QMkM_B5FPWw@mail.gmail.com>
Date:	Mon, 26 May 2014 08:24:21 -0500
From:	Jeff Smith <jsmith.lkml@...il.com>
To:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Kenny Simpson <theonetruekenny@...il.com>,
	Michal Hocko <mhocko@...e.cz>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Dave Jones <davej@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: remap_file_pages() use

>> Mirrored mapping is absolutely required by several
>> independent proprietary platforms I'm aware of, and remap_file_pages()
>> has historically been the only sane way to accomplish this. (i.e.,
>> shm_open(), mmap(NULL, 2^(n+1) pages), remap_file_pages() on 2nd
>> half).
>
> Em.. What's wrong with shm_open() + two mmap()s to cover both halfs?
>
> fd = shm_open();
> addr1 = mmap(NULL, 2*SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> addr2 = mmap(addr1 + SIZE, PROT_READ|PROT_WRITE, MAP_SHARED | MAP_FIXED, fd, 0);
>
> Is there a reason why it doens't work?

Your addr2 mmap() call is a bit incorrect semantically and
syntactically (you skipped the length arg). The addr2 request will
fail because mmap() does not implicitly munmap() occupied virtual
address space. Even if you did that, the following still has a race
condition between the addr2 request and another thread grabbing the
same virtual space, which nothing short of a lock on all threads'
mmap()-ing logic can protect:

addr1 = mmap(NULL, 2*SIZE, PROT_READ, MAP_SHARED, fd, 0);
munmap(addr1 + SIZE, SIZE);
/* race on virtual address space here, but n/a for remap_file_pages() ... */
addr2 = mmap(addr1, SIZE, PROT_READ, MAP_SHARED | MAP_FIXED, fd, 0);

remap_file_pages() is not subject to this problem and allows the
creation of considerably cleaner code. Protecting the address space
corner cases with locks or arbitrarily bounded munmap()-and-retry
loops is a substantial burden over the historically provided approach.

>> but failing that, a reservation API would need
>> to be created (possibly a MAP_RESERVE flag) that would set aside a
>> region that could only be subsequently mapped via explicit
>> address-requesting mmap() calls.
>
> I don't get this part.

I'm proposing that a call along the lines of mmap(NULL, len, prot,
MAP_RESERVED | ..., fd, offset) could return a virtual address block
that is -not- actually mapped but -is- protected from other mmap()
calls not explicitly requesting the space via their addr parameters.
Unfortunately, you'd also need to define separate semantics to
un-reserving not-mapped space, etc.

The important issue is that users need to be able to trivially protect
themselves from transient virtual address space congestion problems
and only fail early on long-term exhaustion situations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/