From: Kees Cook <keescook@chromium.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
mail@horotw.com, linux-hardening@vger.kernel.org,
Jakub Wilk <jwilk@jwilk.net>,
Salvatore Bonaccorso <carnil@debian.org>,
Linux Memory Management List <linux-mm@kvack.org>,
William Kucharski <william.kucharski@oracle.com>
Subject: Re: Limited/Broken functionality of ASLR for Libs >= 2MB
Date: Tue, 23 Jan 2024 14:35:14 -0800 [thread overview]
Message-ID: <202401231433.FB2D7FBD@keescook> (raw)
In-Reply-To: <CAMj1kXGMPeFE_JAKBhAkh9eqmvEJjucsXru2bjc6oa35oyK4=A@mail.gmail.com>
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 <willy@infradead.org> 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 <william.kucharski@oracle.com>
> 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 <william.kucharski@oracle.com>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
>
> 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.4751229f@imladris.surriel.com/
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 ?
-Kees
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
mail@horotw.com, linux-hardening@vger.kernel.org,
Jakub Wilk <jwilk@jwilk.net>,
Salvatore Bonaccorso <carnil@debian.org>,
Linux Memory Management List <linux-mm@kvack.org>,
William Kucharski <william.kucharski@oracle.com>
Subject: Re: Limited/Broken functionality of ASLR for Libs >= 2MB
Date: Tue, 23 Jan 2024 14:35:14 -0800 [thread overview]
Message-ID: <202401231433.FB2D7FBD@keescook> (raw)
In-Reply-To: <CAMj1kXGMPeFE_JAKBhAkh9eqmvEJjucsXru2bjc6oa35oyK4=A@mail.gmail.com>
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 <willy@infradead.org> 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 <william.kucharski@oracle.com>
> 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 <william.kucharski@oracle.com>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
>
> 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.4751229f@imladris.surriel.com/
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 ?
-Kees
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-23 22:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 13:25 Limited/Broken functionality of ASLR for Libs >= 2MB mail
2024-01-15 16:40 ` Sam James
2024-01-15 16:52 ` Matthew Wilcox
2024-01-15 18:21 ` mail
2024-01-15 20:46 ` Matthew Wilcox
2024-01-16 8:09 ` Ard Biesheuvel
2024-01-16 8:09 ` Ard Biesheuvel
2024-01-23 22:35 ` Kees Cook [this message]
2024-01-23 22:35 ` Kees Cook
2024-01-24 1:04 ` Yang Shi
2024-01-24 1:04 ` Yang Shi
2024-01-24 16:08 ` Kees Cook
2024-01-24 16:08 ` Kees Cook
2024-01-22 9:48 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202401231433.FB2D7FBD@keescook \
--to=keescook@chromium.org \
--cc=ardb@kernel.org \
--cc=carnil@debian.org \
--cc=jwilk@jwilk.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mail@horotw.com \
--cc=william.kucharski@oracle.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.