[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eebf054b-7e0e-4732-8d8c-718073ec32ed@sirena.org.uk>
Date: Thu, 16 Nov 2023 18:41:08 +0000
From: Mark Brown <broonie@...nel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "Szabolcs.Nagy@....com" <Szabolcs.Nagy@....com>,
"dietmar.eggemann@....com" <dietmar.eggemann@....com>,
"keescook@...omium.org" <keescook@...omium.org>,
"shuah@...nel.org" <shuah@...nel.org>,
"brauner@...nel.org" <brauner@...nel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"debug@...osinc.com" <debug@...osinc.com>,
"mgorman@...e.de" <mgorman@...e.de>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"fweimer@...hat.com" <fweimer@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"hjl.tools@...il.com" <hjl.tools@...il.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"vschneid@...hat.com" <vschneid@...hat.com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"bristot@...hat.com" <bristot@...hat.com>,
"will@...nel.org" <will@...nel.org>,
"hpa@...or.com" <hpa@...or.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"jannh@...gle.com" <jannh@...gle.com>,
"bp@...en8.de" <bp@...en8.de>,
"bsegall@...gle.com" <bsegall@...gle.com>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"Pandey, Sunil K" <sunil.k.pandey@...el.com>,
"x86@...nel.org" <x86@...nel.org>,
"juri.lelli@...hat.com" <juri.lelli@...hat.com>
Subject: Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()
On Thu, Nov 16, 2023 at 06:11:17PM +0000, Edgecombe, Rick P wrote:
> Now that I've thought about it more, removing the CLONE_VFORK part of
> the logic has several downsides. It is a little extra work to create
> and unmap a shadow stack for an operation that is supposed to be this
> limited fast thing.
It does rather feel like it's defeating the point of the thing.
> It also will change the SSP(let me know if anyone has a general term we
> can use) for the child. So if you have like:
SSP seems fine, we're already using shadow stack here.
> What about a CLONE_NEW_SHSTK for clone3 that forces a new shadow stack?
> So keep the existing logic, but the new flag can override the logic for
> !CLONE_VM and CLONE_VFORK if the caller wants. The behavior of
> shadow_stack_size is then simple. 0 means use default size, !0 means
> use the passed size. No need to overload and tie up args->stack.
That does seem like it cuts through the ambiguous cases. If we go for
that it feels like we should require the flag when specifying a size,
just to be sure that everything is clear. Though having said that we
could just always allocate a shadow stack if a size is specified
regardless of the flags, requiring people who want non-default behaviour
to have some idea what stack size they want. I don't think I have
strong opinons between having the new flag or always allocating a stack
if a size is specified.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists