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 A9E61C25B74 for ; Fri, 24 May 2024 09:46:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EC606B0085; Fri, 24 May 2024 05:46:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 274F66B0088; Fri, 24 May 2024 05:46:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EFA86B0089; Fri, 24 May 2024 05:46:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E369C6B0085 for ; Fri, 24 May 2024 05:46:30 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 90C79A09BC for ; Fri, 24 May 2024 09:46:30 +0000 (UTC) X-FDA: 82152809340.13.2E0B2B8 Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by imf18.hostedemail.com (Postfix) with ESMTP id 9D7FD1C000A for ; Fri, 24 May 2024 09:46:28 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=TDmgI5dh; dmarc=pass (policy=reject) header.from=sifive.com; spf=pass (imf18.hostedemail.com: domain of andy.chiu@sifive.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=andy.chiu@sifive.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716543988; 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=WjgMHPkdKke/sFW+wP3x/OWfAW3icjljhDceGb+T51c=; b=pMGgx54oSPupbb2Oh1pS/q6EVZBp8CNL2cdf9Wb6uQvGV+fK17U25S0W9Zi7UlS5bcxHB0 WK2ED8Bax+/fM2H/rl2uC799oxelYsKuXy0fTGAAmMP7JdDdLLkMN8r77JawlcLC8/okze gXX0+qTdngaYA8KF1VdbOCkQvadh6kM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716543988; a=rsa-sha256; cv=none; b=AL4VOs9NWPj5CryJoP3R4icN9/5t7YexixWuP2K1+iri0PEs/SoVZvCSmqDfukTNUn3ILT ZQVSkW849fKw7nx8FlSTuZSx0bl4sAxObzBogPDFkq4tk8930vcKpW10LewXYJm/TnZtIu zsTVKoJYMpZkpTdYIQRiJLmOSeYUupo= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=TDmgI5dh; dmarc=pass (policy=reject) header.from=sifive.com; spf=pass (imf18.hostedemail.com: domain of andy.chiu@sifive.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=andy.chiu@sifive.com Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-62a08b1a8e6so6665897b3.3 for ; Fri, 24 May 2024 02:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1716543987; x=1717148787; 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=WjgMHPkdKke/sFW+wP3x/OWfAW3icjljhDceGb+T51c=; b=TDmgI5dh/52hkC2B5xUO2GQ0wj/hohKCBerhBtTK2swGi3RuVKW2I2iKWadVUuyJJA 6nmWHr9XNUyzrvC2yE8BwGKklKnL9s43GNVuM160YyucvOTIHI1RVapcsbV0Kdklt5/M GqLbDi/tw9LZ/GjGmWxPZhwQoIfp7VTSiVQ3EgAoCqzMhvVpRSnv3hq0aWtln0B88MAz utFOOV92DXQywt5TioF9ItkN0z4MFitnxNr/+NAraDrFAJ6nXCgEB2Xb1CAe2bYykKzO ZoDyDdvHGYUcs4TGqb54D1iq8thMQCkavz0AsKHz91rcw2pU3t+fnzPL0bJcqXLb/TDU L1Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716543987; x=1717148787; 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=WjgMHPkdKke/sFW+wP3x/OWfAW3icjljhDceGb+T51c=; b=KIRInF+qRJTJpd47zTIdjy8tJPErZIX3T4+AWzPlK4NBUpJ6qKoiuQMBlXiOakmBAz XzKWoSjD/bTlDkZaV7Qekn1thvMBXjYhbMUW6cAKllspVvRo2hcd0UB4L3vu7JahPoVx Y0Cle0HYrzQCMweoZDUO4tZhACKzig7xmDW0AwBqOHfMDIJrIStIcDsgjqX+kC/pkETD J19yqCngmpiPrEiWhhfou+2mjvpHEZCdzgqfgsj2OAroBs4Pfi2TbfENv5q78hz18Qug z0QFH4CtnmoqDhRYip2Comq1SrEPmb0QZc4Jk5T+tS7HeOkFihll/Ad1peebreroBMFA Da6g== X-Forwarded-Encrypted: i=1; AJvYcCVBVFF9W/Rz0hqQE54dpq3lLiyErOd6zAI8rAjN90Vgp3wJ/30Guj5uBgxr3Z1VdEu2lL8ELoDN07H0Hfkt+TtuVJI= X-Gm-Message-State: AOJu0YwbhRE7Axwy/2l0IoR8xD1rnq4lKVAAoicB4HPwQQlIq4YGFqqD 4EPv1tAt8Ku1145kaX7bqdtqEc3u4Vxk83uE1ANMlMzaem/LbQZWv7FDlbKAo7JPnTISHKtlReK mi1vonRooeiIMhq/fJCajgB7/nu4eIvGTUW89mg== X-Google-Smtp-Source: AGHT+IElLw9ldbzBvHZ3/TQt52rrJpYv9UPwEZAezgFRSlhX7EDpAmWQFaSOD80MnXamfMqxd179zHrTOZ6XZB7bNkc= X-Received: by 2002:a25:ae1e:0:b0:df4:df14:61bc with SMTP id 3f1490d57ef6-df7721b7236mr1844605276.29.1716543987537; Fri, 24 May 2024 02:46:27 -0700 (PDT) MIME-Version: 1.0 References: <20240403234054.2020347-1-debug@rivosinc.com> <20240403234054.2020347-23-debug@rivosinc.com> In-Reply-To: <20240403234054.2020347-23-debug@rivosinc.com> From: Andy Chiu Date: Fri, 24 May 2024 17:46:16 +0800 Message-ID: Subject: Re: [PATCH v3 22/29] riscv sigcontext: adding cfi state field in sigcontext To: Deepak Gupta Cc: paul.walmsley@sifive.com, rick.p.edgecombe@intel.com, broonie@kernel.org, Szabolcs.Nagy@arm.com, kito.cheng@sifive.com, keescook@chromium.org, ajones@ventanamicro.com, conor.dooley@microchip.com, cleger@rivosinc.com, atishp@atishpatra.org, alex@ghiti.fr, bjorn@rivosinc.com, alexghiti@rivosinc.com, samuel.holland@sifive.com, conor@kernel.org, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org, corbet@lwn.net, palmer@dabbelt.com, aou@eecs.berkeley.edu, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, oleg@redhat.com, akpm@linux-foundation.org, arnd@arndb.de, ebiederm@xmission.com, Liam.Howlett@oracle.com, vbabka@suse.cz, lstoakes@gmail.com, shuah@kernel.org, brauner@kernel.org, jerry.shih@sifive.com, hankuan.chen@sifive.com, greentime.hu@sifive.com, evan@rivosinc.com, xiao.w.wang@intel.com, charlie@rivosinc.com, apatel@ventanamicro.com, mchitale@ventanamicro.com, dbarboza@ventanamicro.com, sameo@rivosinc.com, shikemeng@huaweicloud.com, willy@infradead.org, vincent.chen@sifive.com, guoren@kernel.org, samitolvanen@google.com, songshuaishuai@tinylab.org, gerg@kernel.org, heiko@sntech.de, bhe@redhat.com, jeeheng.sia@starfivetech.com, cyy@cyyself.name, maskray@google.com, ancientmodern4@gmail.com, mathis.salmen@matsal.de, cuiyunhui@bytedance.com, bgray@linux.ibm.com, mpe@ellerman.id.au, baruch@tkos.co.il, alx@kernel.org, david@redhat.com, catalin.marinas@arm.com, revest@chromium.org, josh@joshtriplett.org, shr@devkernel.io, deller@gmx.de, omosnace@redhat.com, ojeda@kernel.org, jhubbard@nvidia.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: mix8aza6amuwka9d3fj96d138xtnsnm3 X-Rspamd-Queue-Id: 9D7FD1C000A X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1716543988-789985 X-HE-Meta: U2FsdGVkX19tT/RhdDEJQeI4VBkWbf9qW5JcXCLqmz0v5f297J2xbZ8sAyn+cLr78Wv0b3rY+5iijBB8E98PW5PyKi9E2Vzp8PKzZM5Zs2YhN4cobAsj0dU/REty0XUpKQeWL0bu3P4estzz4949SnPMlilBKDTlK4oV9itVyiC/yVu61u5F2li3Jna94KcyNbAQE0IRt3/tSuaruK8wOr5X8+V1JGHYDU9rZeqyVWBIqQ30QI+dWtHxJgL3fzE1g/wxkZaToTfNKwcR0L82eFUl5HxV/ne4/fnlPbX8n/i5FcO2+0vGdyhxs7nRc0i3zH2pixQfNDl+CUibPGHXLTm1es4fhBeI1ulZX//dBI7M8pYfuteG24juE6TOx7kbUBCsaadzOs5ZtI5bFlHwDcgR8FUKFMFAUz3AWAG1Wiq5i/Lp9xXq/3EGnI294EdGQyqM2+dCo5zfjdpTwgk2EzKFZbDNaGDVQ78pk509HyMxNy5BLA9Pud4hj1oXhBFJbLcJ6JLA7lu80wB7pWS1svwqX2ttcgx7nqmhcq4RGpTdKL3nrnppxJ8mICH/Q4Vzti30wM72eViEhIH++hCO4z8bqYWMCnxQvrB8VxmAKRuJQOsKrkpVcjromI4KeIPc/6HPayrWyq7K4N8kGEfLygJGU0Rc8Yx08nPDJ+HWws6wwkf6l2VIGO6fERheRYMh+Q2iCjbVWRbpgeyjGln5fJg3UfAKytaLHPtN0jn1OoQ55UNBOB/wuJ7Nb48/ln0uPyTjsXM64Q1jpos3zHBJ1nUUmWkEjl3yN1XM/SyUXIgopoE38kFXRUr+a7xXkbP7nZIOij/oUvZX4xJ2Ly0WpACvNEugFTeHWrHBy5RXIbUO8TDpS3C1Bq5zObUYLikg8TacqFYCZcFkoQOYz9+mAp1u0V9y2+8M+jkZunDdLzCfD559bW2MlB50AGQIQSoisfQ1+VBuOVfvFrFxy0C AZrEcrXk zHHFIZTJ7TAYEdUmDSJeDaajs7wQd1WQiyBVLGzYKbTPG0QzGcKYZpFZPnNP+SJdwTjTNjy9peiS5KR1mK8Y9wp3Cs1r5m64WlAlLOZvK/taAugEgxrXWxPICpfEu10EOZEuQN0RzjQvi3xlaraA7ZXC24kvOKYAgcYDItB8vUmkDemhjQVmND7PXZvq+Qb2HWhTpsx2+8PLsWaK7MdgYzy+2gUkfGP5kVZvJ3rtZSQnjt6asJT7J5HhvTS0FxoYYLRuKY1kfnsQj5V6jmH+b86w/hWwQfhywULLTKuNdypztxf1qNHu655BLN4t28QY+3HzsgFMoJTpjPSavLC2jglMjLOuJf8G/lFGN9UvrI7Oo3UA= 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: Hi Deepak, On Thu, Apr 4, 2024 at 7:42=E2=80=AFAM Deepak Gupta wr= ote: > > Shadow stack needs to be saved and restored on signal delivery and signal > return. > > sigcontext embedded in ucontext is extendible. Adding cfi state in there > which can be used to save cfi state before signal delivery and restore > cfi state on sigreturn > > Signed-off-by: Deepak Gupta > --- > arch/riscv/include/uapi/asm/sigcontext.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/riscv/include/uapi/asm/sigcontext.h b/arch/riscv/includ= e/uapi/asm/sigcontext.h > index cd4f175dc837..5ccdd94a0855 100644 > --- a/arch/riscv/include/uapi/asm/sigcontext.h > +++ b/arch/riscv/include/uapi/asm/sigcontext.h > @@ -21,6 +21,10 @@ struct __sc_riscv_v_state { > struct __riscv_v_ext_state v_state; > } __attribute__((aligned(16))); > > +struct __sc_riscv_cfi_state { > + unsigned long ss_ptr; /* shadow stack pointer */ > + unsigned long rsvd; /* keeping another word reserved = in case we need it */ > +}; > /* > * Signal context structure > * > @@ -29,6 +33,7 @@ struct __sc_riscv_v_state { > */ > struct sigcontext { > struct user_regs_struct sc_regs; > + struct __sc_riscv_cfi_state sc_cfi_state; I am concerned about this change as this could potentially break uabi. Let's say there is a pre-CFI program running on this kernel. It receives a signal so the kernel lays out the sig-stack as presented in this structure. If the program accesses sc_fpregs, it would now get sc_cfi_state. As the offset has changed, and the pre-CFI program has not been re-compiled. > union { > union __riscv_fp_state sc_fpregs; > struct __riscv_extra_ext_header sc_extdesc; > -- > 2.43.2 > There may be two ways to deal with this. One is to use a different signal ABI for CFI-enabled programs. This may complicate the user space because new programs will have to determine whether it should use the CFI-ABI at run time. Another way is to follow what Vector does for signal stack. It adds a way to introduce new extensions on signal stack without impacting ABI. Please let me know if I misunderstand anything, thanks. Cheers, Andy