Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Date:   Thu, 16 Nov 2023 10:32:06 +0000
From:   "Szabolcs.Nagy@arm.com" <Szabolcs.Nagy@arm.com>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
        "broonie@kernel.org" <broonie@kernel.org>
Cc:     "dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>,
        "keescook@chromium.org" <keescook@chromium.org>,
        "shuah@kernel.org" <shuah@kernel.org>,
        "brauner@kernel.org" <brauner@kernel.org>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "debug@rivosinc.com" <debug@rivosinc.com>,
        "mgorman@suse.de" <mgorman@suse.de>,
        "vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
        "fweimer@redhat.com" <fweimer@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "hjl.tools@gmail.com" <hjl.tools@gmail.com>,
        "rostedt@goodmis.org" <rostedt@goodmis.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
        "vschneid@redhat.com" <vschneid@redhat.com>,
        "catalin.marinas@arm.com" <catalin.marinas@arm.com>,
        "bristot@redhat.com" <bristot@redhat.com>,
        "will@kernel.org" <will@kernel.org>,
        "hpa@zytor.com" <hpa@zytor.com>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "jannh@google.com" <jannh@google.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "bsegall@google.com" <bsegall@google.com>,
        "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        "Pandey, Sunil K" <sunil.k.pandey@intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "juri.lelli@redhat.com" <juri.lelli@redhat.com>
Subject: Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()
Message-ID: <ZVXvptSmmJ6MQ0dY@arm.com>
References: <20231114-clone3-shadow-stack-v2-0-b613f8681155@kernel.org>
 <20231114-clone3-shadow-stack-v2-2-b613f8681155@kernel.org>
 <c9434fa9d864612ed9082197a601c5002ed86a38.camel@intel.com>
 <d873072c-e1f4-4e1f-9efc-dfbd53054766@sirena.org.uk>
 <ZVTvvJTOV777UGsP@arm.com>
 <d90884a0-c4d3-41e9-8f23-68aa87bbe269@sirena.org.uk>
 <d05d23d56bd2c7de30e7732e6bd3d313d8385c47.camel@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <d05d23d56bd2c7de30e7732e6bd3d313d8385c47.camel@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
NoDisclaimer: true
X-Microsoft-Antispam-Message-Info-Original: NDwxSKiXam/ENoKdpLBraEFsydZwJnXWfzBqsNM91LuDs9Aw5ScJI6C/lAZtEUzLKDKIPoNGQD6WuFZWQxS3CnR3gTmLR/XjJMQanO6Ogc759HhejOjPFT2ea8hjN4vt4+bJ8XmuJxyOmMd0XUiT/UtK9QXHa8ZEppVGEdQvfo2NeUsY+nThaP2J1+Gh2a0dXPysZdt0ZRTM5oZAikgTnugab38nf1uLvbCXVi7xH8+B/zluDwNJDhWrcxyi53cBzW1V8PuQUxC8c8cjSaYS/o8GyZD4ss54Mj7cT9ewORB1jl+et0dP1V2RdUn4U89pGkFzoMMQTr+UFe3WTOJCn5g6oox1Dv0AZWeMACV01Rbx4oIZHcOLHApkcD5pN0FOL/UIgLnFti2FrcSO0s55B3bpM71J8uSwE5Ge1gGxRN6XaaILBnmk+RwpnegpAwmhDB69TeeIbNQUTPg/GB9I47XVqFGNaC9NNhFgo29azMdjOmDFta5+CbzTlup4yrHKFnT6gzjNZdTprSESomE0S/rFRDSlGejdnsWuSwBkCf7cgNCTnv+g0ivbI101lih0
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB7179.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(346002)(39850400004)(366004)(376002)(396003)(230922051799003)(1800799009)(64100799003)(186009)(451199024)(2906002)(41300700001)(4001150100001)(316002)(66556008)(54906003)(66476007)(36756003)(8936002)(8676002)(110136005)(66946007)(4326008)(38100700002)(478600001)(5660300002)(86362001)(7416002)(6486002)(83380400001)(26005)(6512007)(2616005)(6666004)(6506007);DIR:OUT;SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB10218
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM4PEPF00025F99.EURPRD83.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs: b3c7e473-4b26-4ffc-ca98-08dbe68f5136
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: sSsaZE2P2xPSuEGKfmGqGuYs5EDeQwWZrb7VYRGAS5XEvcyBfsPsavQ0hSDIj5dZb7M+rpYJQT3Q8dk9b0q9nP5jS0o1iK2EcePRU4S0umeQFb2UQEtQLD2EPNp/HJVvcaehEa3GlEIGBj2R/U82efEJ/1C7X307w9rcbFumHXrdmEICWC4J1lYH7y6E4NSC7DoQIiWOnLOhYq46KiApkzd5hfELeImDhdFywPQk5f7ATE28IqH70DLXBDZ4187q6A033Izvw3TfGEEv3jwDMZAPY6gK569bYDS5iCtGpaYioN4xiWVOc8vA8pmlumAx6A170Wt3rA0ebGi4lgSslEWwBBDA7H7LMrfK0PLE9EYeO8L8KtLlWdFrD/FAgg5B2p4ZXuNBSjIvuyfYIyQsKogVhlq3S7JLtgSCT2htiLCdsjBaYnotypGAkoFria+g50f4Frdrn1WhRlLVHR9zXMxSxzD2trM1F7l7uwDfK+uNGlMomcd8eu9jIVapeKZLtYbSAZ5ngmUWsAm7QbKQL3Ccq5k5u0n6PAK6avuEpWgYqD8X6ET1LEpo5rkZw2cZU5b/q74dwo/dcia6rvxDVNjHmV3W9WYjp/+OVo3FA8ZMvu8vU7xxdsFYs8mcEp9Ww9AosBgD+o5HncHYc2g7/tytt4DM5jQcbtrw7abDCQHj1Nwbz1uEqyGAXWCG6JCfuTQGbYIfylpxl574ZFGtpfF9ufZOIBlPu9DLBcFUDaCqqLJcX9cKaOuxLosm+c09
X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(4636009)(396003)(39860400002)(376002)(346002)(136003)(230922051799003)(1800799009)(82310400011)(186009)(451199024)(64100799003)(36840700001)(46966006)(40470700004)(82740400003)(4001150100001)(2906002)(81166007)(356005)(86362001)(36860700001)(47076005)(5660300002)(40480700001)(4326008)(8676002)(8936002)(83380400001)(450100002)(41300700001)(2616005)(336012)(316002)(36756003)(110136005)(70206006)(54906003)(6512007)(70586007)(26005)(107886003)(40460700003)(6506007)(6666004)(6486002)(478600001);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2023 10:32:39.1738
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ee7682a7-25ba-4e27-3383-08dbe68f5b7f
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource: AM4PEPF00025F99.EURPRD83.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6339
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 16 Nov 2023 02:33:29 -0800 (PST)

The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> >
> > > otherwise 0 size would be fine: the child may not execute
> > > a call instruction at all.
>
> It seems like a special case. Where should the SSP be for the new
> thread?

yes it is likely not an interesting case in practice so < 8
can be an error i think.

> > > > > I think for CLONE_VM we should not require a non-zero size.
> > > > > Speaking of
> > > > > CLONE_VM we should probably be clear on what the expected
> > > > > behavior is
> > > > > for situations when a new shadow stack is not usually
> > > > > allocated.
> > > > > !CLONE_VM || CLONE_VFORK will use the existing shadow stack.
> > > > > Should we
> > > > > require shadow_stack_size be zero in this case, or just ignore
> > > > > it? I'd
> > > > > lean towards requiring it to be zero so userspace doesn't pass
> > > > > garbage
> > > > > in that we have to accommodate later. What we could possibly
> > > > > need to do
> > > > > around that though, I'm not sure. What do you think?
> >
> > > > Yes, requiring it to be zero in that case makes sense I think.
> >
> > > i think the condition is "no specified separate stack for
> > > the child (stack=3D=3D0 || stack=3D=3Dsp)".
> >
> > > CLONE_VFORK does not imply that the existing stack will be
> > > used (a stack for the child can be specified, i think both
> > > glibc and musl do this in posix_spawn).
> >
> > That also works as a check I think, though it requires the arch to
> > check
> > for the stack=3D=3Dsp case - I hadn't been aware of the posix_spawn()
> > usage,
> > the above checks Rick suggested just follow the handling for implicit
> > allocation we have currently.
>
> I didn't realize it was passing its own stack either. I guess the
> reason is to avoid stack overflows. But none of the specific reasons
> listed in the comments seem to applicable to shadow stacks.

while CLONE_VFORK allows the child to use the parent shadow
stack (parent and child cannot execute at the same time and
the child wont return to frames created by the parent), we
want to enable precise size accounting of the shadow stack
so requesting a new shadow stack should work if new stack
is specified.

but stack=3D=3D0 can force shadow_stack_size=3D=3D0.

i guess the tricky case is stack!=3D0 && shadow_stack_size=3D=3D0:
the user may want a new shadow stack with default size logic,
or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
shadow stack from the parent.

>
> What is the case for stack=3Dsp bit of the logic?

iirc it is not documented in the clone man page what stack=3D0
means and of course you don't want sp=3D=3D0 in the vfork child
so some targets sets stack to sp in vfork, others set it 0
and expect the kernel to do the right thing.

this likely does not apply to clone3 where the size has to be
specified so maybe stack=3D=3Dsp does not need special treatment.

> I need to look into this more. My first thought is, passing in a stack
> doesn't absolutely mean they want a new shadow stack allocated either.
> We are changing one heuristic, for another.

yes.

> The other thought is, the new behavior in the !CLONE_VM case doesn't
> seem optimal. fork has ->stack=3D=3D0. Then we would be allocating a stac=
k
> in only the child's MM and changing the SSP there, and for what reason?
> So I don't think we should fully move away from taking hints from the
> CLONE flags.

only stack!=3D0 case is tricky. stack=3D=3D0 means existing shadow stack.

>
> Maybe an alternate could just be to lose the CLONE_VFORK specific stack
> sharing logic. CLONE_VM always gets a new shadow stack. I don't think
> it would disturb userspace functionally, but just involves more
> mapping/unmapping.
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.