From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0FF4CF042B for ; Tue, 8 Oct 2024 23:17:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D3206B00BA; Tue, 8 Oct 2024 19:17:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 282806B00BC; Tue, 8 Oct 2024 19:17:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D63B6B00BE; Tue, 8 Oct 2024 19:17:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DD6DB6B00BA for ; Tue, 8 Oct 2024 19:17:54 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1AD45140D8F for ; Tue, 8 Oct 2024 23:17:53 +0000 (UTC) X-FDA: 82651999668.05.8E62130 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf07.hostedemail.com (Postfix) with ESMTP id 93B5240004 for ; Tue, 8 Oct 2024 23:17:52 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=wiczHgY9; spf=pass (imf07.hostedemail.com: domain of debug@rivosinc.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728429292; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=84oqUYHHA4jnRjNWhrPRTTubksgbEji8zyCvQWhxvkk=; b=EFd8AKlPLj69gE+Pw0MbVAf6I3WVTfdMDQ63PFmoSSGpe1hFmjvpd2MabNA/i1eKIpXIo3 JDHNhZhJwVde6vv90EaP8KbHOiw3LxIDsGDPvqLggFe5iYsRQg4mT1dbIG/bGhhccpXC3d 9vLVMTrWTc8fB0aRTUcV2j89lPKqWGQ= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=wiczHgY9; spf=pass (imf07.hostedemail.com: domain of debug@rivosinc.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728429292; a=rsa-sha256; cv=none; b=EW7ljT4Rj81bHNl/ltW0Cu4oeXpjFvGcqkMBqbk/S5JvQaMgM+eVWpslY7PU+8vkMkm6Ve j07rkLlIcd4zXFD72mLfJWmY2WHcHhcNcu4/zItD+ELZNDs+fY28PPXECXL8dSroy8V5+n WTL507I/Q1RXzZivSOL/Fz3Snf6UPp4= Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-2e0b93157caso236732a91.0 for ; Tue, 08 Oct 2024 16:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1728429471; x=1729034271; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=84oqUYHHA4jnRjNWhrPRTTubksgbEji8zyCvQWhxvkk=; b=wiczHgY9wUA9Di0ets4cVDDyA92RKMYlnuHhO1gaMguq73MJgjuF8XNz2SIAkT7Ugp ucJ+ID6OnySaAzNgfkB8TZEdmq1tFGsmt8yOzaUfK/an3N0IpZ0EX0qgHQAqRmVkn9If KcrQzzgkU4EJ9oXfHoM0P5DSwrn+IHIYl2wPDseVhgFGAIAIM1QHsV63ODpjNW1IcbM4 TUzEHIjfeND3NGwQkCcwdkfnxU9DjYvvPPvun1XniCiaZzaqV1wOvNSiXaaHTF/wROHm eQQAOtZytcg+efrFyl/HKyuyuzs0PhyIdWATS9Aczkt55ZsqHZvxDFEFPQYCBUmAhRUY WlAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728429471; x=1729034271; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=84oqUYHHA4jnRjNWhrPRTTubksgbEji8zyCvQWhxvkk=; b=u6c2HUlKf3Jxm62TNlFtYoUXlinAcYiRkmPWBt1KK5qSYi4gKAdnn1kfFnhYo1DE8X Qp4AMusNxM/5U3nrcI/Er3AAa3vgc/U+e+BlKjP3jZxk75RBzX00PmYWlzJcs4JrXOIA 0mqkqHuBteykX78DuR81+4skWBKEDw4y+WdaZ8d6WVSJr8vGXvimhqJDEjHnP5hlJx6u 2vKCzWDhuXXe5pyUaZu6/1sNy3TdCSkqpqQ4ATnXUEPDdMqVhd4o7Rs0gFZsFIufuoCL zBYbyZeS+7Sdd0PwMbFmeQEB6UfxKkU5R2x7gNLPh4rOUskBqoZW2a3dfHfO3BfB1JX5 lviw== X-Forwarded-Encrypted: i=1; AJvYcCWV6SbcmeoxriNRVOX3UgcKyjhdOemGZhL7K2pAH0eQir3xlV+M56APx12d0yp019lZEhvkGbXh7w==@kvack.org X-Gm-Message-State: AOJu0YwFHRR2PbQwskRpAD9/3UQEwj3CRPnzfirXyhZOTDu71seka0QL P7ZUiCRCK9g0TCJn5YhktpGmB1deb14XzBigrKJwTr2RVyPRL+KJbPboMRW4lQg= X-Google-Smtp-Source: AGHT+IGxbclCqX1bt/+XMXoEabpsMwXOYl+1J5QNTxY9IdVlmLlwPn5SdI2aGJZaqusXEkmXDVEomQ== X-Received: by 2002:a17:90a:d384:b0:2e2:7f8f:3ad5 with SMTP id 98e67ed59e1d1-2e27f8f3c85mr7490705a91.2.1728429470996; Tue, 08 Oct 2024 16:17:50 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e2a5caa753sm140231a91.54.2024.10.08.16.17.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Oct 2024 16:17:50 -0700 (PDT) Date: Tue, 8 Oct 2024 16:17:47 -0700 From: Deepak Gupta To: "Edgecombe, Rick P" Cc: "corbet@lwn.net" , "robh@kernel.org" , "lorenzo.stoakes@oracle.com" , "dave.hansen@linux.intel.com" , "vbabka@suse.cz" , "brauner@kernel.org" , "akpm@linux-foundation.org" , "palmer@dabbelt.com" , "mingo@redhat.com" , "paul.walmsley@sifive.com" , "Liam.Howlett@oracle.com" , "tglx@linutronix.de" , "aou@eecs.berkeley.edu" , "oleg@redhat.com" , "krzk+dt@kernel.org" , "conor@kernel.org" , "ebiederm@xmission.com" , "hpa@zytor.com" , "peterz@infradead.org" , "arnd@arndb.de" , "bp@alien8.de" , "kees@kernel.org" , "x86@kernel.org" , "shuah@kernel.org" , "broonie@kernel.org" , "jim.shu@sifive.com" , "alistair.francis@wdc.com" , "cleger@rivosinc.com" , "kito.cheng@sifive.com" , "linux-kernel@vger.kernel.org" , "samitolvanen@google.com" , "evan@rivosinc.com" , "linux-mm@kvack.org" , "linux-arch@vger.kernel.org" , "atishp@rivosinc.com" , "andybnac@gmail.com" , "devicetree@vger.kernel.org" , "charlie@rivosinc.com" , "linux-doc@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-kselftest@vger.kernel.org" , "richard.henderson@linaro.org" , "linux-riscv@lists.infradead.org" , "alexghiti@rivosinc.com" Subject: Re: [PATCH v6 16/33] riscv/shstk: If needed allocate a new shadow stack on clone Message-ID: References: <20241008-v5_user_cfi_series-v6-0-60d9fe073f37@rivosinc.com> <20241008-v5_user_cfi_series-v6-16-60d9fe073f37@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 93B5240004 X-Stat-Signature: 5iadywnos9bdf7n9mxwbays37itp6o78 X-Rspam-User: X-HE-Tag: 1728429472-680512 X-HE-Meta: U2FsdGVkX1+PB2eOONDLjVPpmo0BQy12U0ruUfYfEl6MTtT2KTEOz0uFbnjZIBYxTrFqfKIlFoO8sexQ83eRoDm5rHzJP5cR58EjAqRuoiBFF6oRVapxiQFi7weM5IUITUngXcZzT/roRHqRSndhmQeTS0noCIKyadyPoNDcKc185H/gADisAedN8SR2bvADu39SgK3hvnxKCFIKSz4kNlsYR2gr6yptumGF18/USVcJcDlicfwtbONQZVJ4hxvqHDemPU6UcxpJL5q/fnRubQKuuvmW02/+9jIDPMcH9nun0oREYjnEUudLzbqUaRP+26Cx8l8mdOiJNBt54Krc3hNogAthKwM1aanNb/0TFtRfJtw9euM3e8amZZ3Wle4Ue/gcod9CXqwYU+0fJl7h7mCpzW1EUeNIhpeGoMiCq4TiPCf3ny13bvmPfU7FaZzWRo23QLaQh6HG1aKoaJIqnvaeHxjP/z6N3NuHjPmgmgy/6geQe1nSkiLspK1IjRrXqzKduEMFVbCWA8dFAOGm75FlPRizxPN7pc9bNiv4rzmM59uDndV1DDMjRSGN76y/JqQVQO9xWGFycXWnzpwCtMdQkiKh5vel7qEQ9J9sR66i0OD4Y/noyrfVW95Yk4YGdf8DaM0eo+ASDvHDAkI+H8utFozBczBhDVOWsr0RXEhZ2fIKXsMCNPkXikjemUvL5cfobaAnMLqy+4qhQ1fCrNbIgndg7/H55Z4syf0SuFM3CH4iKXhTAUJAhPUPuC1q7q/6h7nGTSC1Z1dsp7l1FjNtaeV58o2uGXzpMSfYlW38g3r6mPwEj1XjBTrvhJM66RaSePndhl+utZhsR2w5Ja9yWDscmlAc5/W3D04+oJLHZ9JCvKVbkP55zBis5SK70Wuhsr9dCP2fMhMR1WoA3o2HiKPt8/BdIiwND10dLZHTmeDLAFn4RzAbZzJNvcglW6b3UXyO50v9Obvlw+Z ie0clEYg dAqDCzeTjQOw9UAvlpctGbcMU8o4qPrMVJe+pks4LV9/A3u87VJEzHJHVIDiZvIc/7GmL1Zil07zl+tXXiFRvd8WuCK67d/WkOp2Ff/x8wF/G+IDEjKBDLcV+f3zVwwOMoSbojBSqyj45VeHiYaUwJqB2WmWsVA1WnGGJgRVqffcCsYKfJGAAeKBdykQ+vCSx2v7MNweXwgRRWd/qJP64+HzvOqNJSvw+7kaGgl6nFrtX1/zdoMh1IjgAIarngrvn8/4QmWrzyGCNyqMLv4l+/11VpnwUXadKlmq9J9QjNgSXhzWgeLPjn/ObaSpaPvKzCZhqv5Ju6yW8+MOodAYMWni1zPGLY91SwKE8YcrXRmx9M/Yq73ZlyCFBFJUlxDSAoN4DoEKPs+6KfFIVLFIe/gI+jLbtlNrKplMj3SpUG28HwMNBESDLa+ETfv4Ea7Q+g2o+NdjXPmRWEu27fYfLicVh5OQbW9g0BdPI11CqUuG8l+MNfrmvyGwXlE/n7aO0ZKT8 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Oct 08, 2024 at 10:55:29PM +0000, Edgecombe, Rick P wrote: >On Tue, 2024-10-08 at 15:36 -0700, Deepak Gupta wrote: >> +unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, >> +    const struct kernel_clone_args *args) >> +{ >> + unsigned long addr, size; >> + >> + /* If shadow stack is not supported, return 0 */ >> + if (!cpu_supports_shadow_stack()) >> + return 0; >> + >> + /* >> + * If shadow stack is not enabled on the new thread, skip any >> + * switch to a new shadow stack. >> + */ >> + if (!is_shstk_enabled(tsk)) >> + return 0; >> + >> + /* >> + * For CLONE_VFORK the child will share the parents shadow stack. >> + * Set base = 0 and size = 0, this is special means to track this state >> + * so the freeing logic run for child knows to leave it alone. >> + */ >> + if (args->flags & CLONE_VFORK) { >> + set_shstk_base(tsk, 0, 0); >> + return 0; >> + } >> + >> + /* >> + * For !CLONE_VM the child will use a copy of the parents shadow >> + * stack. >> + */ >> + if (!(args->flags & CLONE_VM)) >> + return 0; >> + >> + /* >> + * reaching here means, CLONE_VM was specified and thus a separate shadow >> + * stack is needed for new cloned thread. Note: below allocation is happening >> + * using current mm. >> + */ >> + size = calc_shstk_size(args->stack_size); >> + addr = allocate_shadow_stack(0, size, 0, false); >> + if (IS_ERR_VALUE(addr)) >> + return addr; >> + >> + set_shstk_base(tsk, addr, size); >> + >> + return addr + size; >> +} > >A lot of this patch and the previous one is similar to x86's and arm's. It great >that we can have consistency around this behavior. > >There might be enough consistency to refactor some of the arch code into a >kernel/shstk.c. > >Should we try? Yeah you're right. Honestly, I've been shameless in adapting most of the flows from x86 `shstk.c` for risc-v. So thank you for that. Now that we've `ARCH_HAS_USER_SHADOW_STACK` part of multiple patch series (riscv shadowstack, clone3 and I think arm64 gcs series as well). It's probably the appropriate time to find common grounds. This is what I suggest - move most of the common/arch agnostic shadow stack stuff in kernel/shstk.c This gets part of compile if `ARCH_HAS_USER_SHADOW_STACK` is enabled/selected. - allow arch specific branch out guard checks for "if cpu supports", "is shadow stack enabled on the task_struct" (I expect each arch layout of task_struct will be different, no point finding common ground there), etc. I think it's worth a try. If you already don't have patches, I'll spend some time to see what it takes to converge in my next version. If I end up into some roadblock, will use this thread for further discussion.