Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries
On Wed, Jan 17, 2024 at 9:40 AM Kees Cook wrote:
>
> On Tue, Jan 16, 2024 at 02:30:36PM -0800, Suren Baghdasaryan wrote:
> > On Tue, Jan 16, 2024 at 2:25 PM Yang Shi wrote:
> > >
> > > On Tue, Jan 16, 2024 at 1:58 PM Suren Baghdasaryan
> > > wrote:
> > > >
> > > > On Tue, Jan 16, 2024 at 12:56 PM Yang Shi wrote:
> > > > >
> > > > > On Tue, Jan 16, 2024 at 11:16 AM Suren Baghdasaryan
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Jan 16, 2024 at 4:09 AM Jiri Slaby
> > > > > > wrote:
> > > > > > >
> > > > > > > On 16. 01. 24, 12:53, Jiri Slaby wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On 09. 08. 22, 20:24, Rik van Riel wrote:
> > > > > > > >> Align larger anonymous memory mappings on THP boundaries by
> > > > > > > >> going through thp_get_unmapped_area if THPs are enabled for
> > > > > > > >> the current process.
> > > > > > > >>
> > > > > > > >> With this patch, larger anonymous mappings are now THP aligned.
> > > > > > > >> When a malloc library allocates a 2MB or larger arena, that
> > > > > > > >> arena can now be mapped with THPs right from the start, which
> > > > > > > >> can result in better TLB hit rates and execution time.
> > > > > > > >
> > > > > > > > This appears to break 32bit processes on x86_64 (at least). In
> > > > > > > > particular, 32bit kernel or firefox builds in our build system.
> > > > > > > >
> > > > > > > > Reverting this on top of 6.7 makes it work again.
> > > > > > > >
> > > > > > > > Downstream report:
> > > > > > > > https://bugzilla.suse.com/show_bug.cgi?id=1218841
> > > > > > > >
> > > > > > > > So running:
> > > > > > > > pahole -J --btf_gen_floats -j --lang_exclude=rust
> > > > > > > > --skip_encoding_btf_inconsistent_proto --btf_gen_optimized
> > > > > > > > .tmp_vmlinux.btf
> > > > > > > >
> > > > > > > > crashes or errors out with some random errors:
> > > > > > > > [182671] STRUCT idr's field 'idr_next' offset=128 bit_size=0
> > > > > > > > type=181346
> > > > > > > > Error emitting field
> > > > > > > >
> > > > > > > > strace shows mmap() fails with ENOMEM right before the errors:
> > > > > > > > 1223 mmap2(NULL, 5783552, PROT_READ|PROT_WRITE,
> > > > > > > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0
> > > > > > > > ...
> > > > > > > > 1223 <... mmap2 resumed>) = -1 ENOMEM (Cannot
> > > > > > > > allocate
> > > > > > > > memory)
> > > > > > > >
> > > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary, but likely
> > > > > > > > large
> > > > > > > > enough. For reference, one is available at:
> > > > > > > > https://decibel.fi.muni.cz/~xslaby/n/btf
> > > > > > > >
> > > > > > > > Any ideas?
> > > > > > >
> > > > > > > This works around the problem, of course (but is a band-aid, not
> > > > > > > a fix):
> > > > > > >
> > > > > > > --- a/mm/mmap.c
> > > > > > > +++ b/mm/mmap.c
> > > > > > > @@ -1829,7 +1829,7 @@ get_unmapped_area(struct file *file,
> > > > > > > unsigned long
> > > > > > > addr, unsigned long len,
> > > > > > > */
> > > > > > > pgoff = 0;
> > > > > > > get_area = shmem_get_unmapped_area;
> > > > > > > - } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
> > > > > > > + } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) &&
> > > > > > > !in_32bit_syscall()) {
> > > > > > > /* Ensures that larger an
Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries
On Wed, Jan 17, 2024 at 4:02 PM Suren Baghdasaryan wrote: > > On Wed, Jan 17, 2024 at 3:32 PM Yang Shi wrote: > > > > On Wed, Jan 17, 2024 at 9:40 AM Kees Cook wrote: > > > > > > On Tue, Jan 16, 2024 at 02:30:36PM -0800, Suren Baghdasaryan wrote: > > > > On Tue, Jan 16, 2024 at 2:25 PM Yang Shi wrote: > > > > > > > > > > On Tue, Jan 16, 2024 at 1:58 PM Suren Baghdasaryan > > > > > wrote: > > > > > > > > > > > > On Tue, Jan 16, 2024 at 12:56 PM Yang Shi > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Jan 16, 2024 at 11:16 AM Suren Baghdasaryan > > > > > > > wrote: > > > > > > > > > > > > > > > > On Tue, Jan 16, 2024 at 4:09 AM Jiri Slaby > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On 16. 01. 24, 12:53, Jiri Slaby wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > On 09. 08. 22, 20:24, Rik van Riel wrote: > > > > > > > > > >> Align larger anonymous memory mappings on THP boundaries by > > > > > > > > > >> going through thp_get_unmapped_area if THPs are enabled for > > > > > > > > > >> the current process. > > > > > > > > > >> > > > > > > > > > >> With this patch, larger anonymous mappings are now THP > > > > > > > > > >> aligned. > > > > > > > > > >> When a malloc library allocates a 2MB or larger arena, that > > > > > > > > > >> arena can now be mapped with THPs right from the start, > > > > > > > > > >> which > > > > > > > > > >> can result in better TLB hit rates and execution time. > > > > > > > > > > > > > > > > > > > > This appears to break 32bit processes on x86_64 (at least). > > > > > > > > > > In > > > > > > > > > > particular, 32bit kernel or firefox builds in our build > > > > > > > > > > system. > > > > > > > > > > > > > > > > > > > > Reverting this on top of 6.7 makes it work again. > > > > > > > > > > > > > > > > > > > > Downstream report: > > > > > > > > > > https://bugzilla.suse.com/show_bug.cgi?id=1218841 > > > > > > > > > > > > > > > > > > > > So running: > > > > > > > > > > pahole -J --btf_gen_floats -j --lang_exclude=rust > > > > > > > > > > --skip_encoding_btf_inconsistent_proto --btf_gen_optimized > > > > > > > > > > .tmp_vmlinux.btf > > > > > > > > > > > > > > > > > > > > crashes or errors out with some random errors: > > > > > > > > > > [182671] STRUCT idr's field 'idr_next' offset=128 > > > > > > > > > > bit_size=0 type=181346 > > > > > > > > > > Error emitting field > > > > > > > > > > > > > > > > > > > > strace shows mmap() fails with ENOMEM right before the > > > > > > > > > > errors: > > > > > > > > > > 1223 mmap2(NULL, 5783552, PROT_READ|PROT_WRITE, > > > > > > > > > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 > > > > > > > > > > ... > > > > > > > > > > 1223 <... mmap2 resumed>) = -1 ENOMEM (Cannot > > > > > > > > > > allocate > > > > > > > > > > memory) > > > > > > > > > > > > > > > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary, but > > > > > > > > > > likely large > > > > > > > > > > enough. For reference, one is available at: > > > > > > > > > > https://decibel.fi.muni.cz/~xslaby/n/btf > > > > > > > > > > > > > > > > > > > > Any ideas? > >
Re: Limited/Broken functionality of ASLR for Libs >= 2MB
On Tue, Jan 23, 2024 at 2:37 PM Kees Cook wrote: > > On Tue, Jan 16, 2024 at 09:09:45AM +0100, Ard Biesheuvel wrote: > > (cc Kees, LAKML) > > > > https://lkml.kernel.org/r/69fa6015256613ed10aee996e181ebd4%40horotw.com > > > > On Mon, 15 Jan 2024 at 21:46, Matthew Wilcox wrote: > > > > > ... > > > Yeah, I don't know either. Outside my scope of expertise. > > > > > > I received a suggestion off-list that we only do the PMD alignment on > > > 64-bit, which seems quite reasonable to me. After all, I don't care > > > about performance on 32-bit just as much as I don't care about security > > > on 32-bit. > > > > > > > For context, the culprit is > > > > commit 1854bc6e2420472676c5c90d3d6b15f6cd640e40 > > Author: William Kucharski > > Date: Sun Sep 22 08:43:15 2019 -0400 > > > > mm/readahead: Align file mappings for non-DAX > > > > When we have the opportunity to use PMDs to map a file, we want to > > follow > > the same rules as DAX. > > > > Signed-off-by: William Kucharski > > Signed-off-by: Matthew Wilcox (Oracle) > > > > which affects *all* 32-bit architectures not just i686. 32-bit ARM > > user space is still being deployed widely, even on arm64 Chromebooks > > running 64-bit kernels (at least up until recently) so unfortunately, > > we're not quite at the point yet where we can just let it rot. > > Is this related at all to this thread as well? > https://lore.kernel.org/lkml/20220809142457.47512...@imladris.surriel.com/ Yes > > Can we avoid this on 32-bit or at least not mislead userspace about the > available entropy visible in /proc/sys/vm/mmap_rnd*_bits ? https://lore.kernel.org/linux-mm/20240118133504.2910955-1-shy828...@gmail.com/ This patch basically made thp_get_unmapped_area no-op on 32 bit. > > -Kees > > -- > Kees Cook >
