[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABRcYmKa1ROu+kM8QMn0iM3JzTmojoOUR0bzRe0sfXukd3cEOg@mail.gmail.com>
Date: Mon, 28 Aug 2023 16:46:31 +0200
From: Florent Revest <revest@...omium.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, akpm@...ux-foundation.org,
anshuman.khandual@....com, joey.gouly@....com, mhocko@...e.com,
david@...hat.com, peterx@...hat.com, izbyshev@...ras.ru,
broonie@...nel.org, szabolcs.nagy@....com, kpsingh@...nel.org,
gthelen@...gle.com, toiwoton@...il.com
Subject: Re: [PATCH v3 4/5] mm: Add a NO_INHERIT flag to the PR_SET_MDWE prctl
On Sun, Aug 27, 2023 at 3:09 PM Catalin Marinas <catalin.marinas@....com> wrote:
>
> On Fri, Aug 25, 2023 at 03:38:36PM -0700, Kees Cook wrote:
> > On Tue, Jul 04, 2023 at 05:36:28PM +0200, Florent Revest wrote:
> > > static inline int prctl_set_mdwe(unsigned long bits, unsigned long arg3,
> > > unsigned long arg4, unsigned long arg5)
> > > {
> > > + unsigned long current_bits;
> > > +
> > > if (arg3 || arg4 || arg5)
> > > return -EINVAL;
> > >
> > > - if (bits & ~(PR_MDWE_REFUSE_EXEC_GAIN))
> > > + if (bits & ~(PR_MDWE_REFUSE_EXEC_GAIN | PR_MDWE_NO_INHERIT))
> > > + return -EINVAL;
> > > +
> > > + /* NO_INHERIT only makes sense with REFUSE_EXEC_GAIN */
> > > + if (bits & PR_MDWE_NO_INHERIT && !(bits & PR_MDWE_REFUSE_EXEC_GAIN))
> > > return -EINVAL;
> > >
> > > + current_bits = get_current_mdwe();
> > > + if (current_bits && current_bits != bits)
> > > + return -EPERM; /* Cannot unset the flags */
> >
> > I was pondering why PR_MDWE_NO_INHERIT can't be unset, but I guess it
> > doesn't matter. Anything forked with have it off, and any process
> > wanting to launch stuff before locking down can just skip running the
> > prctl() until later.
>
> I had a similar doubt initially but then realised that the no-inherit
> mode won't be inherited and concluded it's ok.
Indeed. We previously discussed that in
https://lore.kernel.org/all/CABRcYmLt2KsCoD8WzyCTxuY=6ppuWEqyLSDRXSsmXSxPLHtEzQ@mail.gmail.com/
and I agreed this doesn't matter for our use case and this keeps the
code a lot more maintainable :)
Powered by blists - more mailing lists