linux-kernel - Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <282e637f136b80b352e261514c4102266e92c112.camel@intel.com>
Date:   Thu, 16 Nov 2023 18:33:47 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "Szabolcs.Nagy@....com" <Szabolcs.Nagy@....com>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "debug@...osinc.com" <debug@...osinc.com>,
        "mgorman@...e.de" <mgorman@...e.de>,
        "brauner@...nel.org" <brauner@...nel.org>,
        "fweimer@...hat.com" <fweimer@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
        "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>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "bristot@...hat.com" <bristot@...hat.com>,
        "will@...nel.org" <will@...nel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.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, 2023-11-16 at 18:14 +0000, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 12:52:09AM +0000, Edgecombe, Rick P wrote:
> > On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> > > > end marker token (0) needs it i guess.
> 
> > > x86 doesn't currently have end markers.  Actually, that's a point
> > > -
> > > should we add a flag for specifying the use of end markers here?
> > > There's code in my map_shadow_stack() implementation for arm64
> > > which
> > > does that.
> 
> > Hmm, I guess there isn't a way to pass a flag for the initial exec
> > stack? So probably it should just mirror that behavior. Unless you
> > think a lot of people would like to skip the default behavior.
> 
> I don't really know that anyone would particularly want to use a flag
> on
> arm64, I was more thinking for the benefit of x86 where any
> termination
> record would be a change.  It's certainly easier to not have flags so
> I'm more than happy to leave things as they are, there's nothing
> stopping further extensions of the ABI if we decide we want them
> later.

I'm hoping that shifting the shadow stack start by one frame for thread
stacks (where there is no token to find) will not disturb anything. But
for x86, we will need a new elf bit to be fully safe in implementing
alt shadow stack. When we do that we will have a chance to add an end
of stack marker without compatibility issues on x86. So just doing
default behavior seems fine.

For map_shadow_stack, the end of stack marker will shift the token,
which userspace needs to find, so that is why I wanted a flag for that.
Appreciate the consideration.