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]

Message-ID: <20170424161959.c5ba2nhnxyy57wxe@node.shutemov.name>
Date:   Mon, 24 Apr 2017 19:19:59 +0300
From:   "Kirill A. Shutemov" <kirill@...temov.name>
To:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Andy Lutomirski <luto@...capital.net>,
        Michal Hocko <mhocko@...e.com>, linux-arch@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: Question on the five-level page table support patches

On Sun, Apr 23, 2017 at 12:53:46PM +0200, John Paul Adrian Glaubitz 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.

In proposed implementation, we also use hint address, but in different
way: by default, if hint address is NULL, kernel would not create mappings
above 47-bits, preserving compatibility.

If an application wants to have access to larger address space, it has to
specify hint addess above 47-bits.

See details here:

http://lkml.kernel.org/r/20170420162147.86517-10-kirill.shutemov@linux.intel.com

-- 
 Kirill A. Shutemov