linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Jann Horn <jannh@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	David Hildenbrand <david@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>, Arnd Bergmann <arnd@arndb.de>,
	Christian Brauner <brauner@kernel.org>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org, SeongJae Park <sj@kernel.org>,
	Usama Arif <usamaarif642@gmail.com>
Subject: Re: [RFC PATCH 0/5] add process_madvise() flags to modify behaviour
Date: Tue, 20 May 2025 17:14:16 +0100	[thread overview]
Message-ID: <4c1e185b-1a23-4f25-92e4-1e11a1f67642@lucifer.local> (raw)
In-Reply-To: <CAG48ez0RKgQwpE07tZ8WcfH5XCeZ26wVOZa26HdYjADzVbHbgw@mail.gmail.com>

On Tue, May 20, 2025 at 06:04:47PM +0200, Jann Horn wrote:
> On Tue, May 20, 2025 at 7:36 AM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> > On Mon, May 19, 2025 at 11:53:43PM +0200, Jann Horn wrote:
> > > For comparison, personality flags are explicitly supposed to persist
> > > across execve, but they can be dangerous (stuff like READ_IMPLIES_EXEC
> > > and ADDR_NO_RANDOMIZE), so we have PER_CLEAR_ON_SETID which gets
> > > cleared only if the execution is privileged. (Annoyingly, the
> > > PER_CLEAR_ON_SETID handling is currently implemented separately for
> > > each type of privileged execution we can have
> > > [setuid/setgid/fscaps/selinux transition/apparmor transition/smack
> > > transition], but I guess you could probably gate it on
> > > bprm->secureexec instead...).
> > >
> > > It would be nice if you could either make this a property of the
> > > mm_struct that does not persist across exec, or if that would break
> > > your intended usecase, alternatively wipe it on privileged execution.
> >
> > The use case specifically requires persistence, unfortunately (we are still
> > determining whether this makes sense however - it is by no means a 'done
> > deal' that we're accepting this as a thing).
> >
> > I suppose wiping on privileged execution could be achieved by storing a
> > mask of these permitted flags and clearing that mask in mm->def_flags at
> > this point?
>
> Oh, I see, we're already inheriting VM_NOHUGEPAGE on execve through
> mm->def_flags, with the bitmask VM_INIT_DEF_MASK controlling what is
> inheritable? Hmmmm... I guess turning hugepages _off_ should be
> fine...
>
> Yeah I guess I'd do this by adding another bitmask
> VM_INIT_DEF_MASK_SECUREEXEC or something like that, and then applying
> that bitmask on setuid execution.

I guess we could do it this way, as it would only otherwise limit a non-sys
admin user, and we should try to keep things as flexible as possible.

Let me do this for v2 and see how it works.

As it seems there's some general traction here I can also write some
tests...


  reply	other threads:[~2025-05-20 16:14 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-19 20:52 Lorenzo Stoakes
2025-05-19 20:52 ` [RFC PATCH 1/5] mm: madvise: refactor madvise_populate() Lorenzo Stoakes
2025-05-20 10:30   ` David Hildenbrand
2025-05-20 10:36     ` Lorenzo Stoakes
2025-05-20 10:42       ` David Hildenbrand
2025-05-22 12:32         ` Mike Rapoport
2025-05-19 20:52 ` [RFC PATCH 2/5] mm/madvise: add PMADV_SKIP_ERRORS process_madvise() flag Lorenzo Stoakes
2025-05-19 20:52 ` [RFC PATCH 3/5] mm/madvise: add PMADV_NO_ERROR_ON_UNMAPPED " Lorenzo Stoakes
2025-05-19 20:52 ` [RFC PATCH 4/5] mm/madvise: add PMADV_SET_FORK_EXEC_DEFAULT " Lorenzo Stoakes
2025-05-20  8:38   ` Pedro Falcato
2025-05-20 10:21     ` Lorenzo Stoakes
2025-05-20 11:41       ` Pedro Falcato
2025-05-20 13:39         ` Lorenzo Stoakes
2025-05-20 16:11     ` Jann Horn
2025-05-20 16:19       ` Lorenzo Stoakes
2025-05-20 16:35         ` David Hildenbrand
2025-05-20 22:26   ` Johannes Weiner
2025-05-29 14:46     ` Lorenzo Stoakes
2025-05-19 20:52 ` [RFC PATCH 5/5] mm/madvise: add PMADV_ENTIRE_ADDRESS_SPACE " Lorenzo Stoakes
2025-05-19 21:53 ` [RFC PATCH 0/5] add process_madvise() flags to modify behaviour Jann Horn
2025-05-20  5:35   ` Lorenzo Stoakes
2025-05-20 16:04     ` Jann Horn
2025-05-20 16:14       ` Lorenzo Stoakes [this message]
2025-05-20 15:28 ` David Hildenbrand
2025-05-20 17:47   ` Lorenzo Stoakes
2025-05-20 18:24     ` Usama Arif
2025-05-20 19:21       ` Lorenzo Stoakes
2025-05-20 19:42         ` Usama Arif
2025-05-20 20:15           ` Lorenzo Stoakes
2025-05-20 18:25     ` Lorenzo Stoakes
2025-05-20 18:39       ` David Hildenbrand
2025-05-20 18:25 ` Shakeel Butt
2025-05-20 18:45   ` Lorenzo Stoakes
2025-05-20 19:49     ` Shakeel Butt
2025-05-20 20:39       ` Lorenzo Stoakes
2025-05-20 22:02         ` Shakeel Butt
2025-05-21  4:21           ` Lorenzo Stoakes
2025-05-21 16:28             ` Shakeel Butt
2025-05-21 16:49               ` Lorenzo Stoakes
2025-05-21 17:39                 ` Shakeel Butt
2025-05-22 13:05                   ` David Hildenbrand
2025-05-22 13:21                     ` Lorenzo Stoakes
2025-05-22 20:53                     ` Shakeel Butt
2025-05-26 12:57                       ` David Hildenbrand
2025-05-21 16:57               ` Usama Arif
2025-05-21 17:39                 ` Lorenzo Stoakes
2025-05-21 18:25                   ` Usama Arif
2025-05-21 18:40                     ` Lorenzo Stoakes
2025-05-21 18:45                       ` Usama Arif
2025-05-21 17:32             ` Johannes Weiner
2025-05-21 18:11               ` Lorenzo Stoakes
2025-05-22 12:45               ` David Hildenbrand
2025-05-22 13:49                 ` Lorenzo Stoakes
2025-05-22 15:32               ` Mike Rapoport
2025-05-22 15:47                 ` Lorenzo Stoakes
2025-05-21  2:16       ` Liam R. Howlett
2025-05-22 12:12 ` Mike Rapoport

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=4c1e185b-1a23-4f25-92e4-1e11a1f67642@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=brauner@kernel.org \
    --cc=david@redhat.com \
    --cc=jannh@google.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sj@kernel.org \
    --cc=usamaarif642@gmail.com \
    --cc=vbabka@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox