linux-kernel - Re: Question on the five-level page table support patches

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:   Sun, 23 Apr 2017 22:11:08 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Michal Hocko <mhocko@...e.com>,
        linux-arch <linux-arch@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: Question on the five-level page table support patches

On Sun, Apr 23, 2017 at 3:53 AM, John Paul Adrian Glaubitz
<glaubitz@...sik.fu-berlin.de> wrote:
> Hi Kirill!
>
> I recently read the LWN article on your and your colleagues work to
> add five-level page table support for x86 to the Linux kernel [1]
> and I got your email address from the last patch of the series.
>
> Since this extends the address space beyond 48-bits, as you may know,
> it will cause potential headaches with Javascript engines which use
> tagged pointers. On SPARC, the virtual address space already extends
> to 52 bits and we are running into these very issues with Javascript
> engines on SPARC.
>
> Now, a possible way to mitigate this problem would be to pass the
> "hint" parameter to mmap() in order to tell the kernel not to allocate
> memory beyond the 48 bits address space. Unfortunately, on Linux this
> will only work when the area pointed to by "hint" is unallocated which
> means one cannot simply use a hardcoded "hint" to mitigate this problem.
>
> However, since this trick still works on NetBSD and used to work on
> Linux [3], I was wondering whether there are plans to bring back
> this behavior to mmap() in Linux.
>
> Currently, people are using ugly work-arounds [4] to address this
> problem which involve a manual iteration over memory blocks and
> basically implementing another allocator in the user space
> application.
>
> Thanks,
> Adrian
>
>> [1] https://lwn.net/Articles/717293/
>> [2] https://lwn.net/Articles/717300/
>> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824449#22
>> [4] https://hg.mozilla.org/mozilla-central/rev/dfaafbaaa291
>

Can you explain what the issue is?  What used to work on Linux and
doesn't any more?  The man page is quite clear:

       MAP_FIXED
              Don't  interpret  addr  as  a hint: place the mapping at exactly
              that address.  addr must be a multiple of the page size.  If the
              memory  region  specified  by addr and len overlaps pages of any
              existing mapping(s), then the overlapped part  of  the  existing
              mapping(s)  will  be discarded.  If the specified address cannot
              be used, mmap() will fail.  Because requiring  a  fixed  address
              for  a  mapping is less portable, the use of this option is dis‐
              couraged.

and AFAIK Linux works exactly as documented.

FWIW, a patch to add a new MAP_ mode to tell mmap(2) to use the hinted
address if available and to *fail* if the hinted address is not
available would very likely be accepted and would IMO be much nicer
than the current behavior.

--Andy