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 81308CED268 for ; Tue, 8 Oct 2024 05:16:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 011F36B0083; Tue, 8 Oct 2024 01:16:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDDF16B0085; Tue, 8 Oct 2024 01:16:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D567C6B0088; Tue, 8 Oct 2024 01:16:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B39456B0083 for ; Tue, 8 Oct 2024 01:16:32 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 90A881401A1 for ; Tue, 8 Oct 2024 05:16:31 +0000 (UTC) X-FDA: 82649274624.06.80F8637 Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by imf11.hostedemail.com (Postfix) with ESMTP id 43E2F40003 for ; Tue, 8 Oct 2024 05:16:30 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=SR0HP22V; spf=pass (imf11.hostedemail.com: domain of zong.li@sifive.com designates 209.85.166.44 as permitted sender) smtp.mailfrom=zong.li@sifive.com; dmarc=pass (policy=reject) header.from=sifive.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728364455; 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=w4w/TdKOPPfwgKMj85c6/te+TDmMrhbBdxi4k1LLIvc=; b=T8EWUcv4ZBgX0mxHlilgk0IqhDLx1ctPLeeNiym/B87ARV+xnNf4CNdSPXtmb68HinuHhx sMQPa6Mhdt4At62f1yb76xL0wULyhCvhNPc0AD7Ul6wtMupDOvZwXpCPDO8MKiQED0zWEy gy/FLu6+BgzRfx++EnntdHlorlxmH6M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728364455; a=rsa-sha256; cv=none; b=H1ThlzhPX050RJ10AWn0utwUa3wd8DSQ1KOiuwAs5eXRibjEJvF/YLrw4S0skBq6NX0QCB NfzJLmfsXv5AFwqZ+uPG04o8nRcCsUm+Rz/saHiI1Dez6cpuMHmnlHBhgSTvGr5k9ZYc07 tER+rilM1qQ94UUL9VlTxyv9hRoq5qM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=SR0HP22V; spf=pass (imf11.hostedemail.com: domain of zong.li@sifive.com designates 209.85.166.44 as permitted sender) smtp.mailfrom=zong.li@sifive.com; dmarc=pass (policy=reject) header.from=sifive.com Received: by mail-io1-f44.google.com with SMTP id ca18e2360f4ac-82ce603d8b5so241666839f.0 for ; Mon, 07 Oct 2024 22:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1728364589; x=1728969389; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=w4w/TdKOPPfwgKMj85c6/te+TDmMrhbBdxi4k1LLIvc=; b=SR0HP22VUc48YUHoL3rz9/mgRD1dDcVfSW4di9z/pmd7vPxRdscP2c8/nIdVoGyXWT meN2oXUv1WnwwVpxcaDb/dPt94GZqRL8rZNjbzUVxeQbBUZ0NCzJs8txgPdlCjA4Cvno zVw9v/S3i17IRqvadyuXv1XhLNHkTKt0SfB5cfKBYag8OIPULQVPLDZGp8UR7qUC7hvz nBuYMQRXME6PkxFLaBEac0ap8KPtVmG1qrM9T9UkLMyYV7AddfFH93XopPJAszSfc5wa mJ0HCJCAXV3GCwYjCBfa7Ga+vhHIr21fkxILlccUcYHLzuvPsIm8cr2KJaGifgsNF4i1 YHfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728364589; x=1728969389; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=w4w/TdKOPPfwgKMj85c6/te+TDmMrhbBdxi4k1LLIvc=; b=tVoJWCEY593NdpoRF7TVcoijVA0/eILVCgoohlweM+ETeksRseeWiG/gffEnmTWcdS h0ggtqC8Q01+Nbfxqfse+lP6NAhbj4tiVBruiDgwYcGAk9k3xBRCeZNcEF50H/Wf1Fih 6t9glt4F3TAoQK4wJ5r2qoGptPiU1sqR790IMmScCoxFcNNR8j/6v/084a75fBgd+5m0 YegoUM30AQWn0StOFeGQYPvrU5RYfgLVz8Zvr9kADsPsP+2EbGc6JXVg+Fop2c3hWARr eun0FLG6zBuycK3MlRY1VuYCm5mEfMDVTttXFnb6Z9l2Bg2cJWGNODeSD9PbElDKJmXO 6FDw== X-Forwarded-Encrypted: i=1; AJvYcCVeY+XWQ2Y9EFTC8m3os4xJcogt7pmPgIr+VCxogNozuuoqtf/+g0cK+OO4BrfXfq0RjaMHVxr+PA==@kvack.org X-Gm-Message-State: AOJu0Yy5sxuwQRhoUAs+c6dJuzHsZS4YbcvAsANO/g9NOXjXCFbS6Vnj QYrD7FtydGI7Op6M29rH/GGjObtv4v5eOS8jrNCmXcYJAo54Lglhyy+Nh/0aIe8HGBKeMS+shZY tQw1FElluK7gm8pbqVaBi7a5XRiVmQ2//6YlFhA== X-Google-Smtp-Source: AGHT+IHj+3nyjDRUlzo6HU3+Ye4UA98AMbnjv3+zlmAvnKbqvLOrOys0YnN7vCUlZP6Nh+cnnTYFiH4anmDFOKj+zMw= X-Received: by 2002:a05:6602:14c1:b0:82a:2143:8 with SMTP id ca18e2360f4ac-834f7d65974mr1658309439f.10.1728364589159; Mon, 07 Oct 2024 22:16:29 -0700 (PDT) MIME-Version: 1.0 References: <20241001-v5_user_cfi_series-v1-0-3ba65b6e550f@rivosinc.com> <20241001-v5_user_cfi_series-v1-16-3ba65b6e550f@rivosinc.com> In-Reply-To: From: Zong Li Date: Tue, 8 Oct 2024 13:16:17 +0800 Message-ID: Subject: Re: [PATCH 16/33] riscv/shstk: If needed allocate a new shadow stack on clone To: Deepak Gupta Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , Paul Walmsley , Palmer Dabbelt , Albert Ou , Conor Dooley , Rob Herring , Krzysztof Kozlowski , Arnd Bergmann , Christian Brauner , Peter Zijlstra , Oleg Nesterov , Eric Biederman , Kees Cook , Jonathan Corbet , Shuah Khan , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, alistair.francis@wdc.com, richard.henderson@linaro.org, jim.shu@sifive.com, andybnac@gmail.com, kito.cheng@sifive.com, charlie@rivosinc.com, atishp@rivosinc.com, evan@rivosinc.com, cleger@rivosinc.com, alexghiti@rivosinc.com, samitolvanen@google.com, broonie@kernel.org, rick.p.edgecombe@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: n8js4jwcrq5ifstecr1xbgais3qb1q8i X-Rspamd-Queue-Id: 43E2F40003 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1728364590-952627 X-HE-Meta: U2FsdGVkX1/LZqc9l/KeEU2zCtW5PTiPzi2dgbTAx6LwBrw7KxxtKTvgFpMH53dYYE2UAYm8JkP2hhWKKHyWX38nAXdTOMmZfZkx0IYKOkpYvnJxNa79zOfoPr+l2fDr8DZCZNdVaRhazHBusgBadbWhe7eAUpV3VAKmxjZpeEPlkVTus9uDcirPmuRqPuzgwC185T/DDRrtig7HMFqGJJmMfi4/GH3exU3GSlO2Z57qV30BvZZsbc5Y31o5o3t3t+ElYSizeNJ6xkvS3D8Q1SaQh294YGzp56irk8fXjreZx0w7Ekvc4H/+KKKAt7delsons8YEaj0xlNxxyqtTVr1OPP8CJxo4l6a7tkyFz2EeaNTuZvL2Z7jy+lu8NW9TfWGTxSgXMJSS82TMSh/qS3BDKLnDE01YupVKx4gfJynxNlAVqGeuykV7PPrBk8pVWzjCMDy03tA5WADF7Mf+Vh0qWcvrTGyeLkoL5TkROtgWgTrEalLOpfo/uFW68qnbqLRqO57Bkdql3CA9/4ymfiH0bcPpjDqV4KGAkZE91mm3jealQrkGqeKYEI53saQOMGUwkLzrZSh5tDAe6SQpX7FHMmssVyd0JXH54U2MwM2IcTWdFIjWpZZ7lacGQ50qOB0DHL3B47D0dynvgzfy4werA4iUS0xR5pbLFT+IgMDNSQ9c9yKHjr6kC9D2+f1aL8KQFnx0CFok7/E//G8toXOCYqpylVzcMYsnN7sAiLyvP0W2T9XPgCYDdfnJ0SKaedgwc1rQQ1sfhvA7pNU07ydjV9EGh6kWTWgswyAtHVBpWADkoO0BOvqyadTvH59L56k9Lpo2owAzjBpT8XThDzGsXxusZVkBeCqwRaO1iBxjDTWOv3q/HuVfD8ZIBEMDiaRQ1FBbFUg9QMYfTI19Jjd4HPxEiWUyHkMFdzTgiqJ8fbONYaWEhr7ofN5mesPxa8fXkXeyxl/dCsXmTPd qsGxRdpJ KXAqKI4Vl4RRwvnMyTaJ2rkCOfZdG/VYKLuIzbXUz2Mo3VvHMOwmR96NnM16brClU+khQYbCQw6dEWDgQ1C+vSd7jFh4wtOY/HhZl10ME+Jbi00PY75R2XdMO9F4SyIjE9u/QJFiemEEGQbZzV8q6UjhW48OHOr4cSjcHuu3PCh/kPpdDG9dHMGAKWOM2e5YPXkveJGN3WSMKpLtZfv0VWeXNV3APopIRIOb1eOLASfaBdshbtcVhSEb0qsA8kHR1DryCFcANfuw2aw9OURrL6CgM/2JwY8VsKsd14tYLgIcfpUyeQ9PCMOO5hQRKaWuSSl3J9vRk+xKqzek= 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 8, 2024 at 7:30=E2=80=AFAM Deepak Gupta wr= ote: > > On Mon, Oct 07, 2024 at 04:17:47PM +0800, Zong Li wrote: > >On Wed, Oct 2, 2024 at 12:20=E2=80=AFAM Deepak Gupta wrote: > >> > >> Userspace specifies CLONE_VM to share address space and spawn new thre= ad. > >> `clone` allow userspace to specify a new stack for new thread. However > >> there is no way to specify new shadow stack base address without chang= ing > >> API. This patch allocates a new shadow stack whenever CLONE_VM is give= n. > >> > >> In case of CLONE_VFORK, parent is suspended until child finishes and t= hus > >> can child use parent shadow stack. In case of !CLONE_VM, COW kicks in > >> because entire address space is copied from parent to child. > >> > >> `clone3` is extensible and can provide mechanisms using which shadow s= tack > >> as an input parameter can be provided. This is not settled yet and bei= ng > >> extensively discussed on mailing list. Once that's settled, this commi= t > >> will adapt to that. > >> > >> Signed-off-by: Deepak Gupta > >> --- > >> arch/riscv/include/asm/usercfi.h | 25 ++++++++ > > ... snipped... > > >> + > >> +/* > >> + * This gets called during clone/clone3/fork. And is needed to alloca= te a shadow stack for > >> + * cases where CLONE_VM is specified and thus a different stack is sp= ecified by user. We > >> + * thus need a separate shadow stack too. How does separate shadow st= ack is specified by > >> + * user is still being debated. Once that's settled, remove this part= of the comment. > >> + * This function simply returns 0 if shadow stack are not supported o= r if separate shadow > >> + * stack allocation is not needed (like in case of !CLONE_VM) > >> + */ > >> +unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, > >> + const struct kernel_clone_a= rgs *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)) > > > >Hi Deepak, > >Should it be '!' is_shstk_enabled(tsk)? > > Yes it is a bug. It seems like fork without CLONE_VM or with CLONE_VFORK,= it was returning > 0 anyways. And in the case of CLONE_VM (used by pthread), it was not doin= g the right thing. Hi Deepak, I'd like to know if I understand correctly. Could I know whether there might also be a risk when the user program doesn't enable the CFI and the kernel doesn't activate CFI. Because this flow will still try to allocate the shadow stack and execute the ssamowap command. Thanks > Most of the testing has been with busybox build (independent binaries0 dr= iven via buildroot > setup. Wondering why it wasn't caught. > > Anyways, will fix it. Thanks for catching it. > > > > >> + return 0; > >> + > >> + /*