[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b2ae41fd9a9f05269c7ffcd10565942acbab2c16.camel@intel.com>
Date: Fri, 27 Oct 2023 15:55:51 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "broonie@...nel.org" <broonie@...nel.org>,
"Szabolcs.Nagy@....com" <Szabolcs.Nagy@....com>,
"debug@...osinc.com" <debug@...osinc.com>
CC: "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>,
"mgorman@...e.de" <mgorman@...e.de>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"fweimer@...hat.com" <fweimer@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"hjl.tools@...il.com" <hjl.tools@...il.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"vschneid@...hat.com" <vschneid@...hat.com>,
"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>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"juri.lelli@...hat.com" <juri.lelli@...hat.com>
Subject: Re: [PATCH RFC RFT 2/5] fork: Add shadow stack support to clone3()
On Fri, 2023-10-27 at 12:49 +0100, Szabolcs.Nagy@....com wrote:
> no. the lifetime is the issue: a stack in principle can outlive
> a thread and resumed even after the original thread exited.
> for that to work the shadow stack has to outlive the thread too.
Hmm, this makes me think about the tracing usages.
>
> (or the other way around: a stack can be freed before the thread
> exits, if the thread pivots away from that stack.)
>
> posix threads etc. don't allow this, but the linux syscall abi
> (clone) does allow it.
>
> i think it is reasonable to tie the shadow stack lifetime to the
> thread lifetime, but this clearly introduces a limitation on how
> the clone api can be used. such constraint on the userspace
> programming model is normally a bad decision, but given that most
> software (including all posix conforming code) is not affected,
> i think it is acceptable for an opt-in feature like shadow stack.
Do you have any updated plans to share around your earlier ideas for
token schemes that try to shoot for more compatibility or security?
Powered by blists - more mailing lists