Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
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 13:12:16 +0000
From:   "Szabolcs.Nagy@arm.com" <Szabolcs.Nagy@arm.com>
To:     Mark Brown <broonie@kernel.org>
Cc:     "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
        "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: <ZVYVMFnMnxhhwyiL@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>
 <ZVXvptSmmJ6MQ0dY@arm.com>
 <1bd189e0-a7dd-422c-9766-ef1c9b0d3df8@sirena.org.uk>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1bd189e0-a7dd-422c-9766-ef1c9b0d3df8@sirena.org.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
NoDisclaimer: true
X-Microsoft-Antispam-Message-Info-Original: 2uUUGBjMe2VQO51XbDtRxlgXLFqX++MoYQxdvc/RAztOlQfg4exuCf3y4hNF3bgfvlTh3MGTnDvWKNFVp9P2R8WcEy+wis+BYh+EPxrMqiqxVsqWFfXWsDSMyZQ6DxeXyaNt5Um3kxlQxc9PMnZJWskpRWeIs7Z5+/qQUGx5hnS5OvzBHJtX8FjB+XIFmuHyL8b/wYkDF/odgUvqpvU/big4gE9CpgQNxJFatla1i1wNgeoUH7KzeZ+tYnrvyUharcahFsySnOqGxNeGZrNwx8yGEVAVJZ/bvoM9v6dLHnqdiyDX0DWk0+nJ2okcHPnjb77Wbw2gsmOb3HXoR6pER56WMcAhWllefDObcvqP/Hh5ySeGLWrr7BY/jUxHjxdgcHLnisiYsHqPCTYS0W5xfL2T/NR8R9A3cgBIrv9zoB30Sg5EEAbB5iJqRyQ34ThCbhNHJA5POT0PKI6y+UmvcelcUhDmJUvtsZ9h593dT3JfIe0173tNvawbgqMKT3YkopXjeqNaDKffu86koQ0jtP9HPv4kKEeX7GyXGkaVbJc/86UOHYTZ4O7iqnDpW49M
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)(396003)(376002)(136003)(346002)(366004)(39860400002)(230922051799003)(186009)(451199024)(1800799009)(64100799003)(4001150100001)(5660300002)(83380400001)(7416002)(2906002)(41300700001)(38100700002)(54906003)(6916009)(316002)(66946007)(66556008)(66476007)(6666004)(6512007)(6506007)(86362001)(6486002)(36756003)(478600001)(2616005)(26005)(8936002)(8676002)(4326008);DIR:OUT;SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR08MB5580
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: AMS1EPF00000043.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs: 5e1173fd-8086-4f62-f3f6-08dbe6a5b033
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: WS8iciBD36CrFi+hS7hpj9HPLFISBXL1wEuY4JkTFTSFHZf5Jvlm9G/UazcJzDyZTsd+C9Jo4aRc/mejD2LllJexmVk27+5asYdaJo0vk/k7AP7/4GNShXoRhn2mvDdwJqBK6ZNCqEbiGna8ghOULWfbboWaX/7HLmyicJgCF+nG387mdNBTNgC1831EW279/KpplUGCGE7e1XdQm5qcM8cWXPjno4Ae/wAybdDKRodUKz9wja3aaz9lR2DDDuk6F+Tj0xqUybJQfN7ymKjX3pIuH6+sbr+HZeZ+zzZz+0Z0GRnaqnl0jK7Xk9tHsgxUTerxpDkBz/N9kEVSkDuTiVtsCL/+2qv011T1mNuufYdJuq4WWkOB7y1XPUxjcxRsmbs6PqC0s9H3tsQKVfenH5How0msRsw4TvLZV5UwaG3yTv+ugdeeQ6zuoe0VjbF2y5OOWuTPVRxGnClujSO+lE1CxEDLQaf+rqJcRPDBOVvegPBjx8vBFe9F1wTzd8+nKegNCYYhBwgFbZVxY9xZL+gYH7YSqzzDYZfwT84/v2nem5zJMfwIylsL1dwl6hU9VzDLLCXRWEue/NbO775Y7+BDy9wVgL++pnGI0sPCw9jZCfLWRKepzSNUH+HgH1pbjBrHLGzVY5LwUMknf8OKwgMDPITeOQGwbpf+z/P75gx1Yit3N/2KzWvQtc5ucRrpV4LIawOXAXXpmd66HAhkpQTa7wNkKWDC9qKt5zu/ISn9N+4z79ZL3PLiZ4FqzRIe
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)(39860400002)(396003)(346002)(376002)(136003)(230922051799003)(64100799003)(82310400011)(451199024)(186009)(1800799009)(40470700004)(46966006)(36840700001)(70206006)(70586007)(54906003)(316002)(336012)(2906002)(83380400001)(478600001)(5660300002)(8936002)(2616005)(4326008)(450100002)(6862004)(6512007)(8676002)(107886003)(26005)(4001150100001)(6666004)(6506007)(41300700001)(40480700001)(81166007)(47076005)(356005)(36860700001)(6486002)(82740400003)(86362001)(40460700003)(36756003);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2023 13:12:44.5179
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 49f3abb3-5f4c-43ae-66ef-08dbe6a5b8ba
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: AMS1EPF00000043.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB7543
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 fry.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 (fry.vger.email [0.0.0.0]); Thu, 16 Nov 2023 05:13:09 -0800 (PST)

The 11/16/2023 12:33, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 10:32:06AM +0000, Szabolcs.Nagy@arm.com wrote:
> > The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> > > On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
>
> > 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.
>
> If shadow_stack_size is 0 then we're into clone() behaviour and doing
> the default/implicit handling which is to do exactly what the above
> describes.

sounds good.

> > > 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.
>
> The manual page explicitly says that not specifying a stack means to use
> the same stack area as the parent.

not for clone. clone3 yes.

> > this likely does not apply to clone3 where the size has to be
> > specified so maybe stack=3D=3Dsp does not need special treatment.
>
> You'd have to be jumping through hoops to manage to get the same stack
> pointer while explicitly specifying a stack with clone3() on
> architectures where the stack grows down.  I'm not sure there's a
> reasonable use case.

ok makes sense.
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.