linux-kernel - Re: [PATCH v2 0/5] implement lightweight guard pages

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87a5eysmj1.fsf@mid.deneb.enyo.de>
Date: Sun, 20 Oct 2024 19:37:54 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,  Suren Baghdasaryan
 <surenb@...gle.com>,  "Liam R . Howlett" <Liam.Howlett@...cle.com>,
  Matthew Wilcox <willy@...radead.org>,  Vlastimil Babka <vbabka@...e.cz>,
  "Paul E . McKenney" <paulmck@...nel.org>,  Jann Horn <jannh@...gle.com>,
  David Hildenbrand <david@...hat.com>,  linux-mm@...ck.org,
  linux-kernel@...r.kernel.org,  Muchun Song <muchun.song@...ux.dev>,
  Richard Henderson <richard.henderson@...aro.org>,  Ivan Kokshaysky
 <ink@...assic.park.msu.ru>,  Matt Turner <mattst88@...il.com>,  Thomas
 Bogendoerfer <tsbogend@...ha.franken.de>,  "James E . J . Bottomley"
 <James.Bottomley@...senPartnership.com>,  Helge Deller <deller@....de>,
  Chris Zankel <chris@...kel.net>,  Max Filippov <jcmvbkbc@...il.com>,
  Arnd Bergmann <arnd@...db.de>,  linux-alpha@...r.kernel.org,
  linux-mips@...r.kernel.org,  linux-parisc@...r.kernel.org,
  linux-arch@...r.kernel.org,  Shuah Khan <shuah@...nel.org>,  Christian
 Brauner <brauner@...nel.org>,  linux-kselftest@...r.kernel.org,  Sidhartha
 Kumar <sidhartha.kumar@...cle.com>,  Jeff Xu <jeffxu@...omium.org>,
  Christoph Hellwig <hch@...radead.org>,  linux-api@...r.kernel.org,  John
 Hubbard <jhubbard@...dia.com>
Subject: Re: [PATCH v2 0/5] implement lightweight guard pages

* Lorenzo Stoakes:

> Early testing of the prototype version of this code suggests a 5 times
> speed up in memory mapping invocations (in conjunction with use of
> process_madvise()) and a 13% reduction in VMAs on an entirely idle android
> system and unoptimised code.
>
> We expect with optimisation and a loaded system with a larger number of
> guard pages this could significantly increase, but in any case these
> numbers are encouraging.
>
> This way, rather than having separate VMAs specifying which parts of a
> range are guard pages, instead we have a VMA spanning the entire range of
> memory a user is permitted to access and including ranges which are to be
> 'guarded'.
>
> After mapping this, a user can specify which parts of the range should
> result in a fatal signal when accessed.
>
> By restricting the ability to specify guard pages to memory mapped by
> existing VMAs, we can rely on the mappings being torn down when the
> mappings are ultimately unmapped and everything works simply as if the
> memory were not faulted in, from the point of view of the containing VMAs.

We have a glibc (so not Android) dynamic linker bug that asks us to
remove PROT_NONE mappings in mapped shared objects:

  Extra struct vm_area_struct with ---p created when PAGE_SIZE < max-page-size
  <https://sourceware.org/bugzilla/show_bug.cgi?id=31076>

It's slightly different from a guard page because our main goal is to
avoid other mappings to end up in those gaps, which has been shown to
cause odd application behavior in cases where it happens.  If I
understand the series correctly, the kernel would not automatically
attribute those PROT_NONE gaps to the previous or subsequent mapping.
We would have to extend one of the surrounding mapps and apply
MADV_POISON to that over-mapped part.  That doesn't seem too onerous.

Could the ELF loader in the kernel do the same thing for the main
executable and the program loader?