Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1550082

Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR

From Andy Lutomirski <luto@amacapital.net>
Newsgroups linux.kernel
Subject Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
Date 2017-01-03 19:40 +0100
Message-ID <sVCa7-1SP-63@gated-at.bofh.it> (permalink)
References <sSPdv-45l-3@gated-at.bofh.it> <sV6tz-4f8-9@gated-at.bofh.it> <sVqsh-24D-3@gated-at.bofh.it> <sVxk6-6WU-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

On Tue, Jan 3, 2017 at 5:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, January 2, 2017 10:08:28 PM CET Andy Lutomirski wrote:
>>
>> > This seems to nicely address the same problem on arm64, which has
>> > run into the same issue due to the various page table formats
>> > that can currently be chosen at compile time.
>>
>> On further reflection, I think this has very little to do with paging
>> formats except insofar as paging formats make us notice the problem.
>> The issue is that user code wants to be able to assume an upper limit
>> on an address, and it gets an upper limit right now that depends on
>> architecture due to paging formats.  But someone really might want to
>> write a *portable* 64-bit program that allocates memory with the high
>> 16 bits clear.  So let's add such a mechanism directly.
>>
>> As a thought experiment, what if x86_64 simply never allocated "high"
>> (above 2^47-1) addresses unless a new mmap-with-explicit-limit syscall
>> were used?  Old glibc would continue working.  Old VMs would work.
>> New programs that want to use ginormous mappings would have to use the
>> new syscall.  This would be totally stateless and would have no issues
>> with CRIU.
>
> I can see this working well for the 47-bit addressing default, but
> what about applications that actually rely on 39-bit addressing
> (I'd have to double-check, but I think this was the limit that
> people were most interested in for arm64)?
>
> 39 bits seems a little small to make that the default for everyone
> who doesn't pass the extra flag. Having to pass another flag to
> limit the addresses introduces other problems (e.g. mmap from
> library call that doesn't pass that flag).

That's a fair point.  Maybe my straw man isn't so good.

>
>> If necessary, we could also have a prctl that changes a
>> "personality-like" limit that is in effect when the old mmap was used.
>> I say "personality-like" because it would reset under exactly the same
>> conditions that personality resets itself.
>
> For "personality-like", it would still have to interact
> with the existing PER_LINUX32 and PER_LINUX32_3GB flags that
> do the exact same thing, so actually using personality might
> be better.
>
> We still have a few bits in the personality arguments, and
> we could combine them with the existing ADDR_LIMIT_3GB
> and ADDR_LIMIT_32BIT flags that are mutually exclusive by
> definition, such as
>
>         ADDR_LIMIT_32BIT =      0x0800000, /* existing */
>         ADDR_LIMIT_3GB   =      0x8000000, /* existing */
>         ADDR_LIMIT_39BIT =      0x0010000, /* next free bit */
>         ADDR_LIMIT_42BIT =      0x8010000,
>         ADDR_LIMIT_47BIT =      0x0810000,
>         ADDR_LIMIT_48BIT =      0x8810000,
>
> This would probably take only one or two personality bits for the
> limits that are interesting in practice.

Hmm.  What if we approached this a bit differently?  We could add a
single new personality bit ADDR_LIMIT_EXPLICIT.  Setting this bit
cause PER_LINUX32_3GB etc to be automatically cleared.  When
ADDR_LIMIT_EXPLICIT is in effect, prctl can set a 64-bit numeric
limit.  If ADDR_LIMIT_EXPLICIT is cleared, the prctl value stops being
settable and reading it via prctl returns whatever is implied by the
other personality bits.

--Andy

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCHv2 00/29] 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:00 +0100
  [PATCHv2 17/29] x86/asm: remove __VIRTUAL_MASK_SHIFT==47 assert "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:00 +0100
  [PATCHv2 03/29] asm-generic: introduce __ARCH_USE_5LEVEL_HACK "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:00 +0100
  [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:00 +0100
    Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2016-12-27 03:20 +0100
      Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-12-27 03:40 +0100
        Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2016-12-27 04:30 +0100
          Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-02 10:20 +0100
        Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Carlos O'Donell <carlos@redhat.com> - 2016-12-29 04:00 +0100
          Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2016-12-31 03:10 +0100
            Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-02 09:40 +0100
              Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "H.J. Lu" <hjl.tools@gmail.com> - 2017-01-13 21:20 +0100
    Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Arnd Bergmann <arnd@arndb.de> - 2017-01-02 09:50 +0100
      Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-03 07:10 +0100
        Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Arnd Bergmann <arnd@arndb.de> - 2017-01-03 14:30 +0100
          Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-03 19:40 +0100
            Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-03 23:10 +0100
              Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Arnd Bergmann <arnd@arndb.de> - 2017-01-04 15:00 +0100
            Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Arnd Bergmann <arnd@arndb.de> - 2017-01-03 23:20 +0100
        Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-03 17:10 +0100
          Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-03 19:30 +0100
            Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-04 15:30 +0100
              Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-05 19:20 +0100
    Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-05 20:20 +0100
      Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-01-05 20:40 +0100
        Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-05 20:40 +0100
          Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-05 21:20 +0100
            Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-05 21:50 +0100
              Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-05 22:30 +0100
                Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-06 00:20 +0100
              Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-11 15:30 +0100
                Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-11 19:10 +0100
                Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-11 19:40 +0100
                Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-11 20:00 +0100
                Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-11 20:30 +0100
                Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Linus Torvalds <torvalds@linux-foundation.org> - 2017-01-11 20:40 +0100
                Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andi Kleen <ak@linux.intel.com> - 2017-01-11 22:50 +0100
                Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-11 20:40 +0100
                Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Linus Torvalds <torvalds@linux-foundation.org> - 2017-01-11 20:40 +0100
                Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-11 19:30 +0100
          Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-05 21:20 +0100
  [PATCHv2 19/29] x86/paravirt: make paravirt code support 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:00 +0100
  [PATCHv2 27/29] x86/mm: add support for 5-level paging for KASLR "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:00 +0100
  [PATCHv2 12/29] x86/mm: add support of p4d_t in vmalloc_fault() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:00 +0100
  [PATCHv2 18/29] x86/mm: define virtual memory map for 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:00 +0100
  [PATCHv2 04/29] arch, mm: convert all architectures to use 5level-fixup.h "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:10 +0100
  [PATCHv2 02/29] asm-generic: introduce 5level-fixup.h "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:10 +0100
  [PATCHv2 14/29] x86/kexec: support p4d_t "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:10 +0100
  [PATCHv2 08/29] x86: basic changes into headers for 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:10 +0100
  [PATCHv2 05/29] asm-generic: introduce <asm-generic/pgtable-nop4d.h> "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:10 +0100
  [PATCHv2 15/29] x86: convert the rest of the code to support p4d_t "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-12-27 03:10 +0100
  Re: [PATCHv2 00/29] 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-05 18:00 +0100

csiph-web