From patchwork Wed Apr 3 23:34:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785587 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 58F30156C5E for ; Wed, 3 Apr 2024 23:41:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187697; cv=none; b=LFfg0Ijt16i130wXI+imDHXEIPMnh5xilzgUAIidKJSShZHRdtNgUscqk2QXDQOkpkUU8jjWovhu9TNuFuaqB7CHIIhBTVU7QI90+THGgrnGLAIgVskgEeOxvSWhQCj1OUL3OwA4mxfKJKt1RTHT6CHdw79GwWWOmU2fjh48rn0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187697; c=relaxed/simple; bh=VB2jbs+vxtDiHVEwV3s3rhPAS0B1SvKfxXhLcO1CdzI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PT6yqbJdHoHkLVg+iOmbT5N4W3ev3y3dm1sISNEY3g2MGlODqvjWMIT6TYbXmouLFI/nVjNTpq2R8wodVVBV0PjruEe4Qs/IGPP8IDBuVyfrFULBHhoZdze82Qz3J7CoBaC28k2tjY9qrOTJFNcgUZp9nWwm5qUa2SA6pmqMxIw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=gK2BR1d+; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="gK2BR1d+" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1e27c303573so2651095ad.3 for ; Wed, 03 Apr 2024 16:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187696; x=1712792496; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wZyd6VrWHdcQvYv7dwWjrHMr68qSu7kdpqu35DQkCbw=; b=gK2BR1d+gUQUJbiA8W4PnC1mounbh0xMQUgBh4uErfjreVcOuiGUP33GkFVzvNS8r+ GoHmtE59N3UtunnPSnZv+Rc0csLi5GTNSrfA9cF6xirJeZi05R6RFBoq6gttct4d8PvW gqtv/aab8xl837kogFoPGogxsSOYs2yyrC90Vig597+GIF7OiR5++QhQrWOTPpPlEpxK ua/DAfGOyth4DmxBO2UfUhLIRVhN+RVzd5qb7M6KBvanBYiq4K3ZbluO4zqae+dPpM3y 16Py30Ow9jteJl89gS4hWe7QevcS5v9alGxexgXk4+bqbqulsvnrEO2T9Wzs1CuiWtiJ pcrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187696; x=1712792496; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wZyd6VrWHdcQvYv7dwWjrHMr68qSu7kdpqu35DQkCbw=; b=OQXxmPR8ssr5oD/FmapjVzGczStzy0MvTFgajZ2UZDCD7lIfUFvI50ewWDYimyuSbg vZ4o+gPpprGx589HHbY3tIt0dnedKvqgyZrT8CLD0bKDXJ6khZii88Nv50f2fHOjDHYK 5LpoHHcxd85K6U9+kTILeMft6AKBBFOaNF8ROZcMWxLVrQK5Qat/EuFg4FQWGJ7yNZpr iuWeVC1IfuLX2p/K9t5ZxcclHy+O5ANCglV58RUjI7AgLf9UgvKgXn/yf6VwCv7HK9FO lKUNRHXVnBxw1XJG8FDgddpU9Q323AqGX1Io+oI/SByw5ITx0L90ZxiI4TRzMAMUSq7s P7vA== X-Forwarded-Encrypted: i=1; AJvYcCUY7+2ujpM0BDOSqwAs6SrHYp5N/SSdLVoDoQqAJMUMY6+3aUniKYTlDuWNMuDWnaepnvQL9ASjqbhEv+/C3IH6Rf4sKsmKEA1POsnHfTgW X-Gm-Message-State: AOJu0YzyD2pOfS06mHWUubBSWUB0ofN+hAwD55yEgQ7kCQ99uXb+YRkt T5yc3tvjEQMGU7Ggnc2etkeyGKSAKkIRV6/y9Ziv6cGhVSgvwF6oxsn+Ml02C9M= X-Google-Smtp-Source: AGHT+IHZ1DeudjBR3oiYEW2qXm9zKF1SD2kfhoLrPxZT3yYrf04a37H+jHkRe47joBAEcaPm46pZuA== X-Received: by 2002:a17:902:778c:b0:1e2:aa07:37d7 with SMTP id o12-20020a170902778c00b001e2aa0737d7mr551009pll.22.1712187695773; Wed, 03 Apr 2024 16:41:35 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.41.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:41:35 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 02/29] riscv: define default value for envcfg for task Date: Wed, 3 Apr 2024 16:34:50 -0700 Message-ID: <20240403234054.2020347-3-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Defines a base default value for envcfg per task. By default all tasks should have cache zeroing capability. Any future base capabilities that apply to all tasks can be turned on same way. Signed-off-by: Deepak Gupta --- arch/riscv/include/asm/csr.h | 2 ++ arch/riscv/kernel/process.c | 6 ++++++ 2 files changed, 8 insertions(+) diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h index 2468c55933cd..bbd2207adb39 100644 --- a/arch/riscv/include/asm/csr.h +++ b/arch/riscv/include/asm/csr.h @@ -202,6 +202,8 @@ #define ENVCFG_CBIE_FLUSH _AC(0x1, UL) #define ENVCFG_CBIE_INV _AC(0x3, UL) #define ENVCFG_FIOM _AC(0x1, UL) +/* by default all threads should be able to zero cache */ +#define ENVCFG_BASE ENVCFG_CBZE /* Smstateen bits */ #define SMSTATEEN0_AIA_IMSIC_SHIFT 58 diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c index 92922dbd5b5c..d3109557f951 100644 --- a/arch/riscv/kernel/process.c +++ b/arch/riscv/kernel/process.c @@ -152,6 +152,12 @@ void start_thread(struct pt_regs *regs, unsigned long pc, else regs->status |= SR_UXL_64; #endif + /* + * read current envcfg settings, AND it with base settings applicable + * for all the tasks. Base settings should've been set up during CPU + * bring up. + */ + current->thread_info.envcfg = csr_read(CSR_ENVCFG) & ENVCFG_BASE; } void flush_thread(void) From patchwork Wed Apr 3 23:34:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785586 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BBA4A157A6F for ; Wed, 3 Apr 2024 23:41:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187703; cv=none; b=Zp09/wm+8fAFdTiakVrmh6ZL+m9kdV2qRjrht0cw0AkorZNlfsUFDr7eIBR4DPDJ+vQdV+GaXsb7vE7nyAhrv8kbMs6XcjJNY5ypMUgE1ST5IKn1lkwwn8BgSF9IwqkEZOVLuK+E+IHg4x4933U3k7RII86xNd/sj+6CDyU+S9U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187703; c=relaxed/simple; bh=J89q9o6s6HqxbEZ6ljGjC0aJm6z4lMiWud5hMQgiuBw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AZslVpM1f6KNFqPFXTi0fL5fM/fEeolitIZIv75PIiv3GW5ie96x5xVjsF8cNRS6LddzfNOOfPj2YSu2qJCXtjQ2F4+9sLZUvNeK/fSgV8H4tlRVxyV5uB7HM26AEgBkO1HGpkKAfcrvMmPCxgIbUYzBna+Rxb12zpJU/WyNLMI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=mTG+xJHH; arc=none smtp.client-ip=209.85.214.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="mTG+xJHH" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1dff837d674so3263805ad.3 for ; Wed, 03 Apr 2024 16:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187701; x=1712792501; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=orqHimAqeIVvjnhm+Lh8YT/bDSQ5kt/uWL0O/MbcU4M=; b=mTG+xJHHkSNXluhuTNXNcLAt5ecDKHwA0gaXd7JrpPDne5+qSTWIVILo1n0KKQTz68 Q03GKkaE55tLxNhpQtdk2ILD4s931BjN5AewwTG2sqF5y3UYbHzpo2I2Qs9AzCGWG0f3 SJO4aj58OQTcYbny+4vw1CAKrUFKPCRQ738CKXXqdxa+9e8wapDULkVfxLZXjKRcWlzd GPx3TZy6+/0jtuUvedaKNVic8C7AJdU9XS56hU+/xgTIVvu8kiKqZmCkdWnYuCaP5g/7 RY8R5F0X4xjnJrlsEX9hIHyZW3z3Fq+EeXG2x8Bs3usTqY9ym7jRQvILMrjhdiCzMcSX WSZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187701; x=1712792501; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=orqHimAqeIVvjnhm+Lh8YT/bDSQ5kt/uWL0O/MbcU4M=; b=GR32aA7R4DegJEe1MLGtnrxmkoBL+fifv56DpEnRjqMaMulFBZiAU7bcfJLzObltNs ag8dM+p3DvQaYsZbvygq4O9aR4urzDxM2EnvQLUzFwy/sGW6mW+UkoISWOLXVt2Hjw0N 3eP297slZ8lYOMOkJxZIAlsgu9MrKqgrzSzdrzsFJc+cZ6w3d4hFHBkpZny1YvgeNI8A 42Jw3PEbzdAeXx7EjseMvJAlqVRQLuVdDIfPaJJbTla+/WI1Q20V1nLBgT1rfmJZhmL/ UTylhzGF6Rx4RzoxPa9tfu2NgWUt/YKk8/AucKsdTPZaoiVJKhSVF2qjOWNR95ZfWrWr BGYQ== X-Forwarded-Encrypted: i=1; AJvYcCV/s+kK/7+ftfysiOtD+ca2gU9kFsOMuSc6R1MIzIWCen+6Mx9XOHHkykYyuh2EoNoyP2nqWUyoU1Op2PEkMmKI36tpENTB7Yu6Dot937FR X-Gm-Message-State: AOJu0YyLLS+NvMwsbuXgzHhv7a4Cat5s8/22DPO2X3YuRq/kBG0ru9cr 8i8F68nF7nSKKpzkho7VpqxoKKPK0kgKjGX6yPEx9qI3+oQOnro0iUrl0N++mXY= X-Google-Smtp-Source: AGHT+IHS90cA+AgUmlXmCnhm/ecMbFJNWD0dZq3yi8zpTRzaElJ0z3lk+4PPNraXYIXlpU0z512YdA== X-Received: by 2002:a17:902:d4d1:b0:1e2:8bce:b338 with SMTP id o17-20020a170902d4d100b001e28bceb338mr994151plg.5.1712187700925; Wed, 03 Apr 2024 16:41:40 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.41.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:41:40 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 04/29] riscv: zicfilp / zicfiss in dt-bindings (extensions.yaml) Date: Wed, 3 Apr 2024 16:34:52 -0700 Message-ID: <20240403234054.2020347-5-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Make an entry for cfi extensions in extensions.yaml. Signed-off-by: Deepak Gupta --- .../devicetree/bindings/riscv/extensions.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml index 63d81dc895e5..45b87ad6cc1c 100644 --- a/Documentation/devicetree/bindings/riscv/extensions.yaml +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml @@ -317,6 +317,16 @@ properties: The standard Zicboz extension for cache-block zeroing as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. + - const: zicfilp + description: + The standard Zicfilp extension for enforcing forward edge control-flow + integrity in commit 3a20dc9 of riscv-cfi and is in public review. + + - const: zicfiss + description: + The standard Zicfiss extension for enforcing backward edge control-flow + integrity in commit 3a20dc9 of riscv-cfi and is in publc review. + - const: zicntr description: The standard Zicntr extension for base counters and timers, as From patchwork Wed Apr 3 23:34:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785585 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07720157A70 for ; Wed, 3 Apr 2024 23:41:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187708; cv=none; b=QYm6NtaVGjvmwlwQMdRz4N0giozp+vtNrMLodKmMEieJRvswnUsI5raWTD7FA98vk+GFiVJPQcIS8y4sPODjvWKhhp2XC6y9vWTKNfnYvr19SgFvbjuopxpkfdHr7H+e2QVJsGJKGbbaUUGRPRtD8YhwYlKLPflebRxgNa1IAxk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187708; c=relaxed/simple; bh=h/Tre14WJ45U1+YRacIvsssOX4thi3NoAellOamVugo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SqxyW3shuj9LtDU/wGH56tNeqL8LofPCBEFyijQaeAQ9aKdFSMkeoJsWTIsk/Wqtb/6GoyaggFZjP5w8y0j1/4vUrqCobMhYbBOJGAzJLKnZ17d2RJ2v9TAvapoPOOnt+s6nfIDG1ndyIxfdptDXAvb3qanJkXshe5cOQVPC2TU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=CJLVAddb; arc=none smtp.client-ip=209.85.214.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="CJLVAddb" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1e0878b76f3so3541835ad.0 for ; Wed, 03 Apr 2024 16:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187706; x=1712792506; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0eUDSnaDyxqGg81dPEndGGDTB0RLZ2EAet5NZFMb2JI=; b=CJLVAddbOo6EucmFc0Wy1D+VdSoIj1jJBTeQYtkAXSe+1Keu+ciP4agzCAi2pWpUwJ Tr4isHFU14IbjHwS6DFRxJavyi6HeNk6vF3Wj5+OjB/pioZBeIWaFd8AaNsH3ZIBMPEo rPw1TQzPOLn1R6Z/7Q78XsPgQTRcy4DYqX53YSbr6YlDQS4GbkqRtyFLWKrfWMRpOK8P 3Y/MmTH2pRl0o25cwGcC3JPk/zBYQeCfhVIy0eUOnWUom7Cwl9yBApuHxEbYu72Evxxj 2Kbv0lv8XCDfvaYzoPmH+t547guOEUbconTdNv4+M1JrM2VU2MQeUyRyKCAXbEu6i9lA T/jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187706; x=1712792506; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0eUDSnaDyxqGg81dPEndGGDTB0RLZ2EAet5NZFMb2JI=; b=s3o6Ncuo33+QpQzsfQCTx+MPGZkmsUj0VlQBI4hZ0ViHpZ00tsUS7fY1XqkpI9Ffrs VsF/OGlqq6dEA7auz6pI6+eURmw29+K16Ao6W+kQa7KkQMfxPQv2qNi0vQFYcX6od8c5 uTY5hQiSJp8nzLPZzGciNIs+LiaB10w5ormsmNYHYH3lP9QeN1dOsceC6QlDxELQuOzt SySrttwfOZvJjt4KixA1ao5NwzNlNXHLx2hqftGw6TwKUmgcjQ6xbUifg2pwmrlHZLLm AETkacsd/J9yJ0qO/vdqxlEpmPYFGYn7J3pQRS5Jg1GBVUx6y+LM1Z5PcZMWDtOd8IuQ NpXg== X-Forwarded-Encrypted: i=1; AJvYcCUIhJMUVM0ONEfSxK7tpRAgC6gU0bsiwrEeboBimQsv4Q//9X00xEVy+W6ubKjRbSH6Bm7ck+eyW7pf32qL8CRQIevcRdzh/1VITo1ZpXwc X-Gm-Message-State: AOJu0YzvZ89KN5pl8S9uI994Tb9iXnGCGhRmYuFBLaN5cM9vsBdI+tlM bMu9EKnPd+T3078MTKsBnLswAEyKWaphPDu91pMJOT0aKUYMXMX5G60ODrWBWZY= X-Google-Smtp-Source: AGHT+IFyjyOK4imuMufx/V8FtRsE6RLkCpoEsDyebREmag+E/YQOk+Aiq+uxRiaeRtydulTn7Ig+Gg== X-Received: by 2002:a17:902:d2c4:b0:1e2:a61e:47fa with SMTP id n4-20020a170902d2c400b001e2a61e47famr1344360plc.15.1712187706092; Wed, 03 Apr 2024 16:41:46 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.41.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:41:45 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 06/29] riscv: zicfiss / zicfilp extension csr and bit definitions Date: Wed, 3 Apr 2024 16:34:54 -0700 Message-ID: <20240403234054.2020347-7-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 zicfiss and zicfilp extension gets enabled via b3 and b2 in *envcfg CSR. menvcfg controls enabling for S/HS mode. henvcfg control enabling for VS while senvcfg controls enabling for U/VU mode. zicfilp extension extends *status CSR to hold `expected landing pad` bit. A trap or interrupt can occur between an indirect jmp/call and target instr. `expected landing pad` bit from CPU is recorded into xstatus CSR so that when supervisor performs xret, `expected landing pad` state of CPU can be restored. zicfiss adds one new CSR - CSR_SSP: CSR_SSP contains current shadow stack pointer. Signed-off-by: Deepak Gupta Reviewed-by: Charlie Jenkins --- arch/riscv/include/asm/csr.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h index bbd2207adb39..3bb126d1c5ff 100644 --- a/arch/riscv/include/asm/csr.h +++ b/arch/riscv/include/asm/csr.h @@ -18,6 +18,15 @@ #define SR_MPP _AC(0x00001800, UL) /* Previously Machine */ #define SR_SUM _AC(0x00040000, UL) /* Supervisor User Memory Access */ +/* zicfilp landing pad status bit */ +#define SR_SPELP _AC(0x00800000, UL) +#define SR_MPELP _AC(0x020000000000, UL) +#ifdef CONFIG_RISCV_M_MODE +#define SR_ELP SR_MPELP +#else +#define SR_ELP SR_SPELP +#endif + #define SR_FS _AC(0x00006000, UL) /* Floating-point Status */ #define SR_FS_OFF _AC(0x00000000, UL) #define SR_FS_INITIAL _AC(0x00002000, UL) @@ -196,6 +205,8 @@ #define ENVCFG_PBMTE (_AC(1, ULL) << 62) #define ENVCFG_CBZE (_AC(1, UL) << 7) #define ENVCFG_CBCFE (_AC(1, UL) << 6) +#define ENVCFG_LPE (_AC(1, UL) << 2) +#define ENVCFG_SSE (_AC(1, UL) << 3) #define ENVCFG_CBIE_SHIFT 4 #define ENVCFG_CBIE (_AC(0x3, UL) << ENVCFG_CBIE_SHIFT) #define ENVCFG_CBIE_ILL _AC(0x0, UL) @@ -216,6 +227,11 @@ #define SMSTATEEN0_HSENVCFG (_ULL(1) << SMSTATEEN0_HSENVCFG_SHIFT) #define SMSTATEEN0_SSTATEEN0_SHIFT 63 #define SMSTATEEN0_SSTATEEN0 (_ULL(1) << SMSTATEEN0_SSTATEEN0_SHIFT) +/* + * zicfiss user mode csr + * CSR_SSP holds current shadow stack pointer. + */ +#define CSR_SSP 0x011 /* symbolic CSR names: */ #define CSR_CYCLE 0xc00 From patchwork Wed Apr 3 23:34:56 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785584 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D30A158212 for ; Wed, 3 Apr 2024 23:41:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187713; cv=none; b=NKlA628+mi7e7xYlfkSpzcLyfnXGw+pdZRfTBZF6sWCoJgrnGn+kMMzf+mUoF1fM83YdmRMqgXa5eU10JIPNOAr8jvin3i2hJmKMTT2lIOrwgvercyNq0fHxmaj/negWL4ojVXOyxdbvO1ZI5tEDECOWitW+l5jvKpuD5VyUP70= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187713; c=relaxed/simple; bh=ZshD/5wywYZOoD7/u3SYmOTR2SIaMjHKlWumK97il8I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pilfvmXhDtLSUvHc7C//2EncrxIPc+WqcnQUPezq9vKSR0AOSMdoc6h2QeuawiiFP4ourVk5JGZ/WB32iMmnQO18vTFsyU2bRFI+TvS+Ro7KCrVVoU+RZSsD1KLmjA2O2x9I+JZ+RaD1DfssMteSG3CMrR1WJ3EsPVuxqzYVVH8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=WSPS38vq; arc=none smtp.client-ip=209.85.210.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="WSPS38vq" Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-6e74bd85f26so358438b3a.1 for ; Wed, 03 Apr 2024 16:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187711; x=1712792511; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ABpeeFCkULjAH2+wvqdO28185Mvpk++2Yk/j/QF7GJ0=; b=WSPS38vqE0RSmCl5/mHAvxiYjuUqgkGN16SPOi53Pz9owOm/JcFZbEz2PZvKqeI95x 6XnfV7ymNpxe20jOM58dR5YcNBEMy+tPWOyB6tTt+UkxAlesgvrNw3fEa6KjACYnntZf dNC8QEjvD7luxmLJ7Dtf8pZt3/acLsD2iuwUm/3+SW3gz3IY8BF3z6TuISWsn0fTvq63 Eh3IfdEKTFZ87hO9mpy/jdtnbBlyDldcnMK2F6mTh5LYDPztWFahuho+HqvbfOCGyqQu eYW7RP+KOMKHbq9WjsxHwTJ9Xjz63VM8JrVJZGdL5pagF5qxXl3wIRBW47ylxN9kPbVZ g6xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187711; x=1712792511; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ABpeeFCkULjAH2+wvqdO28185Mvpk++2Yk/j/QF7GJ0=; b=MC2WnsIVCtxnkiznWyyXbCDnxz0+wKwZgzNkJRsgRh93rCFlWsBFZx93rvwtbvhuID cgxO9SH4abTJZ41IQIq1G60vWo8hVjmsetnq/E/wfTsvlU2JfGiB1qvr8rtw8lWFlGn4 n33SdF7zJhKtBwXeL84PPdivfMmFeU1vHOuoUbRptnhWWT327vNPXnGPTUIOw9zzGIL/ 4yLraCSBhAhDvf9FjafndvOh7av9bf8LMMobch0tsfwxFCyDwVIokv2C7DUR/3QS1m6z CaFhkmx4mi3Ol1/x4Fl+6gxpGiGgiTtbT8b1FYf39Rm2ELmbFzjVxj4JYFf6ipsEo5Q1 dB2Q== X-Forwarded-Encrypted: i=1; AJvYcCXPSsk+IoIkJYM77zfh+K/YZ7FzEAKXmUK2fFLVPwqjQLVszAo9T5uUq3ozut+dl7w0ldesIxptmBs4XHQugYPE5psjTS1HdVsG0fFX3Kr/ X-Gm-Message-State: AOJu0YyY8Yu5zs06MgxnF/oYgyHZOTFVpmZaqlSQzjcmaEkseO+OnY7j 7ceBTQUPibBUbZ5nvh0ljULE2vyvnWPMPmVBUfqS4VcIpUF0rbaQ+89sG5FmPDs= X-Google-Smtp-Source: AGHT+IEuPdJ9+VZyZuaG1MlOsTEyLTpxiJH28qDOFi58HVozeCfEc+yN58hPfTIqNV3cM5o/KXJ7iw== X-Received: by 2002:a05:6a21:339e:b0:1a6:f8cf:1e23 with SMTP id yy30-20020a056a21339e00b001a6f8cf1e23mr1102834pzb.41.1712187711360; Wed, 03 Apr 2024 16:41:51 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.41.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:41:50 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 08/29] mm: Define VM_SHADOW_STACK for RISC-V Date: Wed, 3 Apr 2024 16:34:56 -0700 Message-ID: <20240403234054.2020347-9-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 VM_SHADOW_STACK is defined by x86 as vm flag to mark a shadow stack vma. x86 uses VM_HIGH_ARCH_5 bit but that limits shadow stack vma to 64bit only. arm64 follows same path (see links) To keep things simple, RISC-V follows the same. This patch adds `ss` for shadow stack in process maps. Links: https://lore.kernel.org/lkml/20231009-arm64-gcs-v6-12-78e55deaa4dd@kernel.org/#r Signed-off-by: Deepak Gupta --- fs/proc/task_mmu.c | 3 +++ include/linux/mm.h | 11 ++++++++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 3f78ebbb795f..d9d63eb74f0d 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -702,6 +702,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */ #ifdef CONFIG_X86_USER_SHADOW_STACK [ilog2(VM_SHADOW_STACK)] = "ss", +#endif +#ifdef CONFIG_RISCV_USER_CFI + [ilog2(VM_SHADOW_STACK)] = "ss", #endif }; size_t i; diff --git a/include/linux/mm.h b/include/linux/mm.h index f5a97dec5169..64109f6c70f5 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -352,7 +352,16 @@ extern unsigned int kobjsize(const void *objp); * for more details on the guard size. */ # define VM_SHADOW_STACK VM_HIGH_ARCH_5 -#else +#endif + +#ifdef CONFIG_RISCV_USER_CFI +/* + * RISC-V is going along with using VM_HIGH_ARCH_5 bit position for shadow stack + */ +#define VM_SHADOW_STACK VM_HIGH_ARCH_5 +#endif + +#ifndef VM_SHADOW_STACK # define VM_SHADOW_STACK VM_NONE #endif From patchwork Wed Apr 3 23:34:58 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785583 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E67A156C4F for ; Wed, 3 Apr 2024 23:41:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187718; cv=none; b=R3OP6Z3I4RF+C1HI0j8ChkgUJlI3bjm5/+6UZ88/tBIcg9PbD9NcyQuatVGtxBMSZUreHEXQVjBkW74IS24By3LY4rfMjTndQeMsmKIfVMX+CJ2bQskSrrH4SrXP8xK/gkjqmBQ9t8q7uAqg9ibE/YQv3tmFRn4hfH4xpSjuh2Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187718; c=relaxed/simple; bh=6VGNDTy28deWBBLZj+Se/ZgPbompO0iK4xDtjnyQ1mc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=m160hAKcGqHtWsc+jyrmGQTIUjiY0mcMAYNe1KHnfmi/MZIjUc/KpnPHLOI8tkcyj54ScI7iyhfKQtQWhgTjj6ew4EyfBjtGIporUumA+sCqiWIzX9/YQu/t2GD8nWFNlI+bc9xZOSCr0juCK2TH7ncF69zf6+YjBv9JvIlKnCo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=S7ognDjN; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="S7ognDjN" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-1def89f0cfdso11753895ad.0 for ; Wed, 03 Apr 2024 16:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187716; x=1712792516; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6lX+9+cMysL2s2bh0/j36OWWXHnHHgmfQfoaQ0p+lk8=; b=S7ognDjNirjLnqJzpHb2VYYdDJpYDVSMk315+66cvJFsNP8obQC5og8fVUR0N+xHoG +hdVXsWsLyKRdMARUdVHnJmIYDNhIDbuoz4jjx7s7aCrCvAngOdymIfyUT9OZWI1vIR6 xrYz9NVbSXzcdAcYRXJAQ9/BwHEi/eNgz9e5RwFfBTIJxT21e3mVXZfjYBD9Ja1ToSPN 3e4xun9mbGGkrv0NwyAvX1e8vyDzF6vUrpQrAKtlJYFRa/zRz+qabSEeTxyj2aM6MHZL Ck+atdQY8PfE+I1KoHFB+QhbnKCka9+s33F0ygcBvWIahbEZ+UTLAuS1WmE9xu9ETK45 Iqvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187716; x=1712792516; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6lX+9+cMysL2s2bh0/j36OWWXHnHHgmfQfoaQ0p+lk8=; b=wbVyChQMo9DIDxDFZ8jCw7dnUCGd3CBu0YhFTnmVDbzajnZHSIwugz9VaTieLAg+nV GN5JP//GfxkIDuhrrZAER+eyD6y6KzBjDc3JaB4tl6HpK2/YY+/ILJyw/AfQffiXmtDL t4Zj008Ej+UcVCwESj4N7sydvEZSHlzctAqJKXYbf/kT+fpUZajI2wfHkr9yOkLhWhe3 QhJjtQKeUoiTIzazDh5wNjmHsyeb0sibt5kE5XWzJjbepeBpA46EYt415C10cmYoIbbM 9PtH//lLM5wqvdcE5009E4SocLMSW1jYrtKh+WfFDRD2kglCyQzM0/2iY9oCt6+X+w+S 1NxQ== X-Forwarded-Encrypted: i=1; AJvYcCVZmq/DN4oRFDa+OqNHvkQEkC34m5/n9HPosik/L5jRomcWvSAuVFtq3f99oYHaXlOSBp4ssCB3+anPYJGDyxw9sQc53Nf1++ezxgTNr2WY X-Gm-Message-State: AOJu0Yz6hXoyE6tMROtvcFnMvQbaYL/5XL0EIemRx6Y+vsiZ6eVyjXNs Mi1O+mG5IBmZXhr4NzzystiYjSAVMv2Mi5Dd7m48ajJ6iiQpy2A9I56N5854d0c= X-Google-Smtp-Source: AGHT+IHn70WZbF+jlCONe2EcRRr6ZCh1IRqHu+QHyp4yjMBW+7E5Ek9bYAqg4ymMIf0JA4HyBbr9VA== X-Received: by 2002:a17:902:e80e:b0:1e0:b677:293b with SMTP id u14-20020a170902e80e00b001e0b677293bmr5847942plg.29.1712187716595; Wed, 03 Apr 2024 16:41:56 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.41.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:41:56 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 10/29] riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE Date: Wed, 3 Apr 2024 16:34:58 -0700 Message-ID: <20240403234054.2020347-11-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 `arch_calc_vm_prot_bits` is implemented on risc-v to return VM_READ | VM_WRITE if PROT_WRITE is specified. Similarly `riscv_sys_mmap` is updated to convert all incoming PROT_WRITE to (PROT_WRITE | PROT_READ). This is to make sure that any existing apps using PROT_WRITE still work. Earlier `protection_map[VM_WRITE]` used to pick read-write PTE encodings. Now `protection_map[VM_WRITE]` will always pick PAGE_SHADOWSTACK PTE encodings for shadow stack. Above changes ensure that existing apps continue to work because underneath kernel will be picking `protection_map[VM_WRITE|VM_READ]` PTE encodings. Signed-off-by: Deepak Gupta --- arch/riscv/include/asm/mman.h | 24 ++++++++++++++++++++++++ arch/riscv/include/asm/pgtable.h | 1 + arch/riscv/kernel/sys_riscv.c | 11 +++++++++++ arch/riscv/mm/init.c | 2 +- mm/mmap.c | 1 + 5 files changed, 38 insertions(+), 1 deletion(-) create mode 100644 arch/riscv/include/asm/mman.h diff --git a/arch/riscv/include/asm/mman.h b/arch/riscv/include/asm/mman.h new file mode 100644 index 000000000000..ef9fedf32546 --- /dev/null +++ b/arch/riscv/include/asm/mman.h @@ -0,0 +1,24 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __ASM_MMAN_H__ +#define __ASM_MMAN_H__ + +#include +#include +#include + +static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot, + unsigned long pkey __always_unused) +{ + unsigned long ret = 0; + + /* + * If PROT_WRITE was specified, force it to VM_READ | VM_WRITE. + * Only VM_WRITE means shadow stack. + */ + if (prot & PROT_WRITE) + ret = (VM_READ | VM_WRITE); + return ret; +} +#define arch_calc_vm_prot_bits(prot, pkey) arch_calc_vm_prot_bits(prot, pkey) + +#endif /* ! __ASM_MMAN_H__ */ diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index 6066822e7396..4d5983bc6766 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -184,6 +184,7 @@ extern struct pt_alloc_ops pt_ops __initdata; #define PAGE_READ_EXEC __pgprot(_PAGE_BASE | _PAGE_READ | _PAGE_EXEC) #define PAGE_WRITE_EXEC __pgprot(_PAGE_BASE | _PAGE_READ | \ _PAGE_EXEC | _PAGE_WRITE) +#define PAGE_SHADOWSTACK __pgprot(_PAGE_BASE | _PAGE_WRITE) #define PAGE_COPY PAGE_READ #define PAGE_COPY_EXEC PAGE_READ_EXEC diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c index f1c1416a9f1e..846c36b1b3d5 100644 --- a/arch/riscv/kernel/sys_riscv.c +++ b/arch/riscv/kernel/sys_riscv.c @@ -8,6 +8,8 @@ #include #include #include +#include +#include static long riscv_sys_mmap(unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, @@ -17,6 +19,15 @@ static long riscv_sys_mmap(unsigned long addr, unsigned long len, if (unlikely(offset & (~PAGE_MASK >> page_shift_offset))) return -EINVAL; + /* + * If only PROT_WRITE is specified then extend that to PROT_READ + * protection_map[VM_WRITE] is now going to select shadow stack encodings. + * So specifying PROT_WRITE actually should select protection_map [VM_WRITE | VM_READ] + * If user wants to create shadow stack then they should use `map_shadow_stack` syscall. + */ + if (unlikely((prot & PROT_WRITE) && !(prot & PROT_READ))) + prot |= PROT_READ; + return ksys_mmap_pgoff(addr, len, prot, flags, fd, offset >> (PAGE_SHIFT - page_shift_offset)); } diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index fa34cf55037b..98e5ece4052a 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -299,7 +299,7 @@ pgd_t early_pg_dir[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE); static const pgprot_t protection_map[16] = { [VM_NONE] = PAGE_NONE, [VM_READ] = PAGE_READ, - [VM_WRITE] = PAGE_COPY, + [VM_WRITE] = PAGE_SHADOWSTACK, [VM_WRITE | VM_READ] = PAGE_COPY, [VM_EXEC] = PAGE_EXEC, [VM_EXEC | VM_READ] = PAGE_READ_EXEC, diff --git a/mm/mmap.c b/mm/mmap.c index d89770eaab6b..57a974f49b00 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -47,6 +47,7 @@ #include #include #include +#include #include #include From patchwork Wed Apr 3 23:35:00 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785582 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FF4B158A01 for ; Wed, 3 Apr 2024 23:42:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187724; cv=none; b=Tf3fJfD6/rqu9BVU7AFPH1VJ5WKVGYQxbgSKVYKqMdVtFujEqbiH6LbePkc/U45t9vNVmp33x0MYvQUYG62DT2Ky6f7HYD27yBO/AwT4Yza7TgtiDPpcFsmJIRBdngm0T0l/uVqmh/FrEMmjdnR+c/AtyzilOis6jph4FUvEwwY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187724; c=relaxed/simple; bh=7m+lwx5hnBcCswvc1cbYpS6vclXxJd4dhK55npT2Syw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VbrLv6mxJNdv9vUVfa5wtcmXuhMe2GL1n1ZPioOPP9CSH2QgirAHro+UQwDxxf1RvsLN3E5dd7hv+WhMl/U/78sLAipjkxYz+Dyc2Ce2S8BHWPZ/s3YNh55BD99VjhZDXXMVRqxDomrqRBNJXlDzy0yO3pQ1qgqszRKxFe63cdU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=HiiVifJV; arc=none smtp.client-ip=209.85.214.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="HiiVifJV" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1e0d82c529fso3642325ad.2 for ; Wed, 03 Apr 2024 16:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187722; x=1712792522; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ir+lgmmL0ZmHswiBuJpYbgwfILZ/3vCYSTqJIvKZkPQ=; b=HiiVifJVjGBaeiNzxhd0SDxfk6KrDmGRvM0Y9Gag3Wb1rsjAgkpV1YUe2lhbFDiACI Z9QXgIzFt54wr68jBtKsVTaZQgEDJAeP45LiAt0KF3BQbRFC0h5a7Gijb0jXtmgvKurb tsQbN+JDMtAXQBuFKQrnCnlI3NV65Gc18HLfhti8eP5YgTts8xglxAelfwAVCGc9Jdjj Gnan69QU6t8XquuMvpfMYLZCYQkpGw4v2pHudiB2TEuoe0Giw8t7+qArJo3niM15Xkot 6Ep9IWkmp21/nTiEnuPZCiZCH0bnYDW4DKanVK3v/zsUkt2IG+RT4uE9kVtWfDevhtwM wxcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187722; x=1712792522; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ir+lgmmL0ZmHswiBuJpYbgwfILZ/3vCYSTqJIvKZkPQ=; b=Ya8a+VUZVCm+LFEH6X11YOANbR+Z/Ge+BmsU6mn7Ps2iUTPC7vGteVzdKMRLLaw2Uf XH+AOr1LPACyiCAGFP1akVBVuC61k4Nb2PaqqDisabWV3GELYrYYyVkki12VeLWrC5qT f3a3dXgTp+njwbQCzu3IORx8ORekkIvKPx5aDlRCOIOrxh7siJawn5SlKFwq49i/cCZ4 OdwiW+zUMM027FYOLAXqXkpFuOIKpf+X5h3fpXAfhdsJBDO/pS3s4NPWUDx/X8qy3TFU r5N85detFAhYHVYyJ9qMOLenWzt3B80BAz1RJp28J4TlEmKF1MqraFi7ZrZ2QEjQrbf1 JIJA== X-Forwarded-Encrypted: i=1; AJvYcCVMptFDe08YILnbHNuqqEz6nhCOz72LAi78KSQuEnng/j/yjrnICYwdhxK0Iug4M1FI1SBHUjj1hI6vheWmnWR3H7hgcXbjSR2GlqcmdmnT X-Gm-Message-State: AOJu0Yw2mJubE3/iNZlo69/cj9JFbyKCSnfNef6xhRUOPia5aOB4VfSm DL6P+sgB1VB4Uf0DYSedjndcyspfmm+Lhba1+bk/lCQL+UD04EKpRTVgGX7QeVA= X-Google-Smtp-Source: AGHT+IE44MbJu6BIDOc3JQGIbnw05ABlT/b1420//7Gxn6oIy2GZnOOaOXzQhU0JUqBs5V+YKteclQ== X-Received: by 2002:a17:903:22ca:b0:1e2:3851:6b6a with SMTP id y10-20020a17090322ca00b001e238516b6amr860088plg.65.1712187721821; Wed, 03 Apr 2024 16:42:01 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.41.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:42:01 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 12/29] riscv mmu: teach pte_mkwrite to manufacture shadow stack PTEs Date: Wed, 3 Apr 2024 16:35:00 -0700 Message-ID: <20240403234054.2020347-13-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 pte_mkwrite creates PTEs with WRITE encodings for underlying arch. Underlying arch can have two types of writeable mappings. One that can be written using regular store instructions. Another one that can only be written using specialized store instructions (like shadow stack stores). pte_mkwrite can select write PTE encoding based on VMA range (i.e. VM_SHADOW_STACK) Signed-off-by: Deepak Gupta Reviewed-by: Alexandre Ghiti --- arch/riscv/include/asm/pgtable.h | 7 +++++++ arch/riscv/mm/pgtable.c | 21 +++++++++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index 6362407f1e83..9b837239d3e8 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -403,6 +403,10 @@ static inline pte_t pte_wrprotect(pte_t pte) /* static inline pte_t pte_mkread(pte_t pte) */ +struct vm_area_struct; +pte_t pte_mkwrite(pte_t pte, struct vm_area_struct *vma); +#define pte_mkwrite pte_mkwrite + static inline pte_t pte_mkwrite_novma(pte_t pte) { return __pte(pte_val(pte) | _PAGE_WRITE); @@ -694,6 +698,9 @@ static inline pmd_t pmd_mkyoung(pmd_t pmd) return pte_pmd(pte_mkyoung(pmd_pte(pmd))); } +pmd_t pmd_mkwrite(pmd_t pmd, struct vm_area_struct *vma); +#define pmd_mkwrite pmd_mkwrite + static inline pmd_t pmd_mkwrite_novma(pmd_t pmd) { return pte_pmd(pte_mkwrite_novma(pmd_pte(pmd))); diff --git a/arch/riscv/mm/pgtable.c b/arch/riscv/mm/pgtable.c index ef887efcb679..c84ae2e0424d 100644 --- a/arch/riscv/mm/pgtable.c +++ b/arch/riscv/mm/pgtable.c @@ -142,3 +142,24 @@ pmd_t pmdp_collapse_flush(struct vm_area_struct *vma, return pmd; } #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +pte_t pte_mkwrite(pte_t pte, struct vm_area_struct *vma) +{ + if (vma_is_shadow_stack(vma->vm_flags)) + return pte_mkwrite_shstk(pte); + + pte = pte_mkwrite_novma(pte); + + return pte; +} + +pmd_t pmd_mkwrite(pmd_t pmd, struct vm_area_struct *vma) +{ + if (vma_is_shadow_stack(vma->vm_flags)) + return pmd_mkwrite_shstk(pmd); + + pmd = pmd_mkwrite_novma(pmd); + + return pmd; +} + From patchwork Wed Apr 3 23:35:02 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785581 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C4B32158D78 for ; Wed, 3 Apr 2024 23:42:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187730; cv=none; b=uhW05IStuEvJipvgTD9KZxAXqkEQSxRXeFb2M1ano5jucOJNNGM7G4JXRajZ3ae62rY74HTcmBtgPB+Y2PbLvvqWBRjBMizEca5DpGcZjtcVB9fUOSpj9mriFk3mTuOhdFE5X1xBx+q+PFhcjJzJtdeHb6iEaA2YaMXpPqdXCNs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187730; c=relaxed/simple; bh=BaRaZdnPEb9EeKAX1C9l9zkaOoV7I9CKui2VkfmXV6w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GNAthvmfdcuFfzpnsb1Lm7TQ+egot+4W2ok3YFIHtTw80v4MFvfqM3EyzpBrAlFyTXM4+023TgvaRI0srTy7fvoLzegEI6WPkddnnRfNHHbuD9en0aLlV/RxpU3jLYbtEuPoK64F2zuMo95UXXCwC1BRlMIv7H2kMAWWfQpXeTg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=hEUZcgiU; arc=none smtp.client-ip=209.85.210.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="hEUZcgiU" Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-6e6ca2ac094so392528b3a.0 for ; Wed, 03 Apr 2024 16:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187727; x=1712792527; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=nZzDaIjjjD8VhJdhh5IUepl1HTzhfTHUUaj9lSQCyR8=; b=hEUZcgiULY2YfYKq5s33mwrlh2EtNSxv36iMScLJJHn6hQRvkF6X5kQ3Sn8aT1G04U IqgnyZTdo5yUiF4e1mPOoRc+gYAYDLcwareJ4s7DaJZgS9W84uszE54X9G0Z2h4aMNxz z3opeVvVCr6xsPInKE+UyOhtRF33bfuDqBHFik4Zt1is6FwIbo28BpflWrx5Vuc9zxw9 qL/3K1ioMYrIHqAD1JwqX3ScQlVUOiLV84FwwMIbZ7mNOqv7/3pQN0G6Crn4s3mZ9f4R l7JKUOpuL1BJR5FuL4EgRQffoQ0PN7qxEDYtqNp8gIJp7j+E6TQj2BTn9I5b3FlV1PEE DudQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187727; x=1712792527; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nZzDaIjjjD8VhJdhh5IUepl1HTzhfTHUUaj9lSQCyR8=; b=FzMYu40daVOzSa5ScUzTh1EqnhvcbpXg2eYrMnpOLmMDHe3P6iT1296gslvfZlqUIC sdSev0BM5Szw7kTnsHDF9k+MiR7u99uZgS7WOM7P9/ztIG8CdaI8I3I2S4VWnec/JAiN YZJnke/34Onvi2G3Q/NGbPPR+uXxUzT894N+Py/yHu1+IloXQbamCpAJENnjkVtv9xxD CjZlEMykZMFIQ6EKjN1Uob1hqXsg7tfqqWCaSyNMuVCIw0SXRnCC6gVMMNc19XMCUBmv XZEvyI2vul0gLa3L0x5V3eVpu/YB7BSK/UP/UdN415jAxjBd8W5Ze4ro4O5//WmU9/MA JrrQ== X-Forwarded-Encrypted: i=1; AJvYcCWsUTYc/sZY3NUxcc5BgTOeuKpaiYcQcmz6gXlyn9jwgxbiNt1y5ivKKZ9cItDTqDVjrs0MRdEZmTAehU/k0q84iW5K+b3Tg5oKHUiBvBy2 X-Gm-Message-State: AOJu0YyusLPho1BmmLznsAC2TJYL6lcDvAdimH0h8Mtg11Vr1OywfuoK xRV6aLnAW2HpPFSzUdrEmsrkIl3DsmjPRG99pxeS1GWfjXUUW365ugJQfXrFwLg= X-Google-Smtp-Source: AGHT+IGK408qRBDCWMc9cgA3P53YsEUkHm94AsTnnAuBMG78k0asshcIWXaS1TByR/Xziq/68i5yvA== X-Received: by 2002:a05:6300:8086:b0:1a3:e4fe:f6f1 with SMTP id ap6-20020a056300808600b001a3e4fef6f1mr1126332pzc.58.1712187727071; Wed, 03 Apr 2024 16:42:07 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.42.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:42:06 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 14/29] riscv/mm: Implement map_shadow_stack() syscall Date: Wed, 3 Apr 2024 16:35:02 -0700 Message-ID: <20240403234054.2020347-15-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 As discussed extensively in the changelog for the addition of this syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the existing mmap() and madvise() syscalls do not map entirely well onto the security requirements for shadow stack memory since they lead to windows where memory is allocated but not yet protected or stacks which are not properly and safely initialised. Instead a new syscall map_shadow_stack() has been defined which allocates and initialises a shadow stack page. This patch implements this syscall for riscv. riscv doesn't require token to be setup by kernel because user mode can do that by itself. However to provide compatibility and portability with other architectues, user mode can specify token set flag. Signed-off-by: Deepak Gupta --- arch/riscv/kernel/Makefile | 2 + arch/riscv/kernel/usercfi.c | 149 ++++++++++++++++++++++++++++++++ include/uapi/asm-generic/mman.h | 1 + 3 files changed, 152 insertions(+) create mode 100644 arch/riscv/kernel/usercfi.c diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile index 604d6bf7e476..3bec82f4e94c 100644 --- a/arch/riscv/kernel/Makefile +++ b/arch/riscv/kernel/Makefile @@ -107,3 +107,5 @@ obj-$(CONFIG_COMPAT) += compat_vdso/ obj-$(CONFIG_64BIT) += pi/ obj-$(CONFIG_ACPI) += acpi.o + +obj-$(CONFIG_RISCV_USER_CFI) += usercfi.o diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c new file mode 100644 index 000000000000..c4ed0d4e33d6 --- /dev/null +++ b/arch/riscv/kernel/usercfi.c @@ -0,0 +1,149 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2024 Rivos, Inc. + * Deepak Gupta + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define SHSTK_ENTRY_SIZE sizeof(void *) + +/* + * Writes on shadow stack can either be `sspush` or `ssamoswap`. `sspush` can happen + * implicitly on current shadow stack pointed to by CSR_SSP. `ssamoswap` takes pointer to + * shadow stack. To keep it simple, we plan to use `ssamoswap` to perform writes on shadow + * stack. + */ +static noinline unsigned long amo_user_shstk(unsigned long *addr, unsigned long val) +{ + /* + * Since shadow stack is supported only in 64bit configuration, + * ssamoswap.d is used below. CONFIG_RISCV_USER_CFI is dependent + * on 64BIT and compile of this file is dependent on CONFIG_RISCV_USER_CFI + * In case ssamoswap faults, return -1. + * Never expect -1 on shadow stack. Expect return addresses and zero + */ + unsigned long swap = -1; + + __enable_user_access(); + asm goto( + ".option push\n" + ".option arch, +zicfiss\n" + "1: ssamoswap.d %[swap], %[val], %[addr]\n" + _ASM_EXTABLE(1b, %l[fault]) + RISCV_ACQUIRE_BARRIER + ".option pop\n" + : [swap] "=r" (swap), [addr] "+A" (*addr) + : [val] "r" (val) + : "memory" + : fault + ); + __disable_user_access(); + return swap; +fault: + __disable_user_access(); + return -1; +} + +/* + * Create a restore token on the shadow stack. A token is always XLEN wide + * and aligned to XLEN. + */ +static int create_rstor_token(unsigned long ssp, unsigned long *token_addr) +{ + unsigned long addr; + + /* Token must be aligned */ + if (!IS_ALIGNED(ssp, SHSTK_ENTRY_SIZE)) + return -EINVAL; + + /* On RISC-V we're constructing token to be function of address itself */ + addr = ssp - SHSTK_ENTRY_SIZE; + + if (amo_user_shstk((unsigned long __user *)addr, (unsigned long) ssp) == -1) + return -EFAULT; + + if (token_addr) + *token_addr = addr; + + return 0; +} + +static unsigned long allocate_shadow_stack(unsigned long addr, unsigned long size, + unsigned long token_offset, + bool set_tok) +{ + int flags = MAP_ANONYMOUS | MAP_PRIVATE; + struct mm_struct *mm = current->mm; + unsigned long populate, tok_loc = 0; + + if (addr) + flags |= MAP_FIXED_NOREPLACE; + + mmap_write_lock(mm); + addr = do_mmap(NULL, addr, size, PROT_READ, flags, + VM_SHADOW_STACK | VM_WRITE, 0, &populate, NULL); + mmap_write_unlock(mm); + + if (!set_tok || IS_ERR_VALUE(addr)) + goto out; + + if (create_rstor_token(addr + token_offset, &tok_loc)) { + vm_munmap(addr, size); + return -EINVAL; + } + + addr = tok_loc; + +out: + return addr; +} + +SYSCALL_DEFINE3(map_shadow_stack, unsigned long, addr, unsigned long, size, unsigned int, flags) +{ + bool set_tok = flags & SHADOW_STACK_SET_TOKEN; + unsigned long aligned_size = 0; + + if (!cpu_supports_shadow_stack()) + return -EOPNOTSUPP; + + /* Anything other than set token should result in invalid param */ + if (flags & ~SHADOW_STACK_SET_TOKEN) + return -EINVAL; + + /* + * Unlike other architectures, on RISC-V, SSP pointer is held in CSR_SSP and is available + * CSR in all modes. CSR accesses are performed using 12bit index programmed in instruction + * itself. This provides static property on register programming and writes to CSR can't + * be unintentional from programmer's perspective. As long as programmer has guarded areas + * which perform writes to CSR_SSP properly, shadow stack pivoting is not possible. Since + * CSR_SSP is writeable by user mode, it itself can setup a shadow stack token subsequent + * to allocation. Although in order to provide portablity with other architecture (because + * `map_shadow_stack` is arch agnostic syscall), RISC-V will follow expectation of a token + * flag in flags and if provided in flags, setup a token at the base. + */ + + /* If there isn't space for a token */ + if (set_tok && size < SHSTK_ENTRY_SIZE) + return -ENOSPC; + + if (addr && (addr % PAGE_SIZE)) + return -EINVAL; + + aligned_size = PAGE_ALIGN(size); + if (aligned_size < size) + return -EOVERFLOW; + + return allocate_shadow_stack(addr, aligned_size, size, set_tok); +} diff --git a/include/uapi/asm-generic/mman.h b/include/uapi/asm-generic/mman.h index 57e8195d0b53..0c0ac6214de6 100644 --- a/include/uapi/asm-generic/mman.h +++ b/include/uapi/asm-generic/mman.h @@ -19,4 +19,5 @@ #define MCL_FUTURE 2 /* lock all future mappings */ #define MCL_ONFAULT 4 /* lock all pages that are faulted in */ +#define SHADOW_STACK_SET_TOKEN (1ULL << 0) /* Set up a restore token in the shadow stack */ #endif /* __ASM_GENERIC_MMAN_H */ From patchwork Wed Apr 3 23:35:04 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785580 Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C0906158DAA for ; Wed, 3 Apr 2024 23:42:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187734; cv=none; b=EVagGElcByrATV3soiFlA4KqHOoUehK1euKmIrDor522MNDCR3364jPQyXkeLu+chVsUFfVT1HrcaM6t0JOzEAs+Fw+VZpZzLYK6rb8rfaJlggZcpX9dCEaZsXdC93j0q7zEYjq5UasNyHfvL5G7w8r8PpzpaKKP0cKzrSEVOTM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187734; c=relaxed/simple; bh=ieGAxIoHQhZwY3VcCNGHe4c+9aNd1lLYYqhAjwk1NeE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p3ICigCG9G3j8zLANSCXXRx1wqpgWVC9mQsajU6X2vOUWkgxEPZTPZUDQXEOyforBthItmPlkRRjSUqCZG+xV4VisKT+6J5tCYm89pKSZ2SzRPekQF2JXLzbnnxJYkP4+jX59S1nJxdD2wcwVT23l7MfLBG4KH+KGf/9q/F5tHA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=nQQ2bTO/; arc=none smtp.client-ip=209.85.215.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="nQQ2bTO/" Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-5dca1efad59so329129a12.2 for ; Wed, 03 Apr 2024 16:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187732; x=1712792532; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oZ8ix94mmk4BD8MMBywPtAuOuTf4nkdzJ2/QigtbDFI=; b=nQQ2bTO/3HIq0/k65+5wkhese5rdalD0SfEiHbgPzu3BHHn6ljTlMmAX/cnupwg2Ut K5OrWA8aYYlRkS65U43BezmmwcyOeztB/S68nfjcGcuKBNdaDKotu5r4NDMLpjQmaLyY VvDBHaUrZIZl4KTsVdfO6STPNKoaeiVX4hss4LLv6fYteUbuXx2fv1IEP6piRg/0eNXP 2HgOt9hlvslvtyAxzsfj+KYccHB4CgaLPARpN1r1/At3K4v4iygq9Up+n70fy3CEC+Wq ONUYnQCV/5MsELKfzrT18BX1jbjhzQTc94pNcL8wrkSJ0VDF1u6Eg19eCypbGTAYNdZH 75+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187732; x=1712792532; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oZ8ix94mmk4BD8MMBywPtAuOuTf4nkdzJ2/QigtbDFI=; b=RF5cWcku2KckhdRiNqK4gsVhNZElxJZlLQaVNFfgwbnBxPITrk2t1h3JwE1mbMLbD7 6IrTycB5wEHc5oryiPev+6cFIMi2e24+/SL463wxuVL4EP3qVo4NEQ+sRxuxMdn94T3e 6wDHq4a/kDGUyRNhogRMKC3hufygf74ZOlnA+Nt7c7Ur/V8Es/G8K0plPJdG7NnRhoiO QTJwd3cCd7nzRTictIKB2Y6DMTniD8R5JpwGMbdK0V/FxKc+38+vU8NZtWVZX2U2Fy19 RUO0IelbwJ2BRlnGELGC5idRu5vCL9nmhE4KgXu2WLIsfO2oMAHuhw1Z5O3S0mCfQHZ/ iTBw== X-Forwarded-Encrypted: i=1; AJvYcCUMfxCzfOoziDRSTwwJM24BAKjXW6msV5nnxBxJcTO7JGmUJ37os/lpp6Z9kkOZi4cYW6WhHrYsYwDAQehs1NuY2e/8GjQdzefaJETqUeMz X-Gm-Message-State: AOJu0YzzcSPTaq4GonY7EM1Q/GWftVNaSxWSzTqARCjQBnf0kcejphoH J4BWulqJLNF512ZkJAY3bR5o/cIDvdlztgubbPl3GG5o572o0jHhiBjf9iqR7+s= X-Google-Smtp-Source: AGHT+IGqMNLnQifKehVyTniVZ6at0ArgKKWUBm835f674K8o1H2lf66wElH3Yt8D0mQ5+pAZCM+6nA== X-Received: by 2002:a17:90a:134c:b0:299:3035:aede with SMTP id y12-20020a17090a134c00b002993035aedemr916968pjf.44.1712187732279; Wed, 03 Apr 2024 16:42:12 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.42.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:42:11 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 16/29] prctl: arch-agnostic prctl for shadow stack Date: Wed, 3 Apr 2024 16:35:04 -0700 Message-ID: <20240403234054.2020347-17-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Mark Brown Three architectures (x86, aarch64, riscv) have announced support for shadow stacks with fairly similar functionality. While x86 is using arch_prctl() to control the functionality neither arm64 nor riscv uses that interface so this patch adds arch-agnostic prctl() support to get and set status of shadow stacks and lock the current configuration to prevent further changes, with support for turning on and off individual subfeatures so applications can limit their exposure to features that they do not need. The features are: - PR_SHADOW_STACK_ENABLE: Tracking and enforcement of shadow stacks, including allocation of a shadow stack if one is not already allocated. - PR_SHADOW_STACK_WRITE: Writes to specific addresses in the shadow stack. - PR_SHADOW_STACK_PUSH: Push additional values onto the shadow stack. - PR_SHADOW_STACK_DISABLE: Allow to disable shadow stack. Note once locked, disable must fail. These features are expected to be inherited by new threads and cleared on exec(), unknown features should be rejected for enable but accepted for locking (in order to allow for future proofing). This is based on a patch originally written by Deepak Gupta but later modified by Mark Brown for arm's GCS patch series. Signed-off-by: Mark Brown Co-developed-by: Deepak Gupta --- include/linux/mm.h | 3 +++ include/uapi/linux/prctl.h | 22 ++++++++++++++++++++++ kernel/sys.c | 30 ++++++++++++++++++++++++++++++ 3 files changed, 55 insertions(+) diff --git a/include/linux/mm.h b/include/linux/mm.h index 9952937be659..1d08e1fd2f6a 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -4201,5 +4201,8 @@ static inline bool pfn_is_unaccepted_memory(unsigned long pfn) return range_contains_unaccepted_memory(paddr, paddr + PAGE_SIZE); } +int arch_get_shadow_stack_status(struct task_struct *t, unsigned long __user *status); +int arch_set_shadow_stack_status(struct task_struct *t, unsigned long status); +int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status); #endif /* _LINUX_MM_H */ diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h index 370ed14b1ae0..3c66ed8f46d8 100644 --- a/include/uapi/linux/prctl.h +++ b/include/uapi/linux/prctl.h @@ -306,4 +306,26 @@ struct prctl_mm_map { # define PR_RISCV_V_VSTATE_CTRL_NEXT_MASK 0xc # define PR_RISCV_V_VSTATE_CTRL_MASK 0x1f +/* + * Get the current shadow stack configuration for the current thread, + * this will be the value configured via PR_SET_SHADOW_STACK_STATUS. + */ +#define PR_GET_SHADOW_STACK_STATUS 71 + +/* + * Set the current shadow stack configuration. Enabling the shadow + * stack will cause a shadow stack to be allocated for the thread. + */ +#define PR_SET_SHADOW_STACK_STATUS 72 +# define PR_SHADOW_STACK_ENABLE (1UL << 0) +# define PR_SHADOW_STACK_WRITE (1UL << 1) +# define PR_SHADOW_STACK_PUSH (1UL << 2) + +/* + * Prevent further changes to the specified shadow stack + * configuration. All bits may be locked via this call, including + * undefined bits. + */ +#define PR_LOCK_SHADOW_STACK_STATUS 73 + #endif /* _LINUX_PRCTL_H */ diff --git a/kernel/sys.c b/kernel/sys.c index f8e543f1e38a..242e9f147791 100644 --- a/kernel/sys.c +++ b/kernel/sys.c @@ -2315,6 +2315,21 @@ int __weak arch_prctl_spec_ctrl_set(struct task_struct *t, unsigned long which, return -EINVAL; } +int __weak arch_get_shadow_stack_status(struct task_struct *t, unsigned long __user *status) +{ + return -EINVAL; +} + +int __weak arch_set_shadow_stack_status(struct task_struct *t, unsigned long status) +{ + return -EINVAL; +} + +int __weak arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status) +{ + return -EINVAL; +} + #define PR_IO_FLUSHER (PF_MEMALLOC_NOIO | PF_LOCAL_THROTTLE) #ifdef CONFIG_ANON_VMA_NAME @@ -2757,6 +2772,21 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, case PR_RISCV_V_GET_CONTROL: error = RISCV_V_GET_CONTROL(); break; + case PR_GET_SHADOW_STACK_STATUS: + if (arg3 || arg4 || arg5) + return -EINVAL; + error = arch_get_shadow_stack_status(me, (unsigned long __user *) arg2); + break; + case PR_SET_SHADOW_STACK_STATUS: + if (arg3 || arg4 || arg5) + return -EINVAL; + error = arch_set_shadow_stack_status(me, arg2); + break; + case PR_LOCK_SHADOW_STACK_STATUS: + if (arg3 || arg4 || arg5) + return -EINVAL; + error = arch_lock_shadow_stack_status(me, arg2); + break; default: error = -EINVAL; break; From patchwork Wed Apr 3 23:35:06 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785579 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D575F156F54 for ; Wed, 3 Apr 2024 23:42:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187748; cv=none; b=nVU6NLy16WgQrNYsFYVx9zawb2xpdAr3GPGBgdSW5iFtC+GRbpIcnSHAcE+0nwne5t522wUvXlVfPmjir1xQe4Yu/kyLF1/twrVwKW+jx7k65Wts6o6XYLTiHWT5cAtLujQkAylqnmfucXdD5pO7lB0T75QTzAqHLucMa8BCAlw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187748; c=relaxed/simple; bh=/UM8sBwS5Fq4+1ALaM23XG6iZwuJZw3OrcJGzFpN/Q8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WOT9rIVS6pegSANKXmLmSmq4txEJ84cpi6sJzR+Ef0o+LUtz4b2o3mchJcbd7JsWvxklcGrriB9wPxIceWXgIMbJ17umja76qMHhiU3ezLGUUYj8VFesX/EVHQBNaGPyZqe+hqXZ0YxJI3LSVUKdnuY+YSrXjYShJjqGT6b+3jw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=w9EXSwux; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="w9EXSwux" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1e0f0398553so3191695ad.3 for ; Wed, 03 Apr 2024 16:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187746; x=1712792546; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=LYjXbKsZWObysa039N5fpdCtqQMANxENOQ8uS4k07nc=; b=w9EXSwux6JYHAv9CW771NZ4igExmqXmbU4L7zYqPOB3u9e+M8EnZ9Hy0SeNnSypcL8 M/4E7nFXCkSbWdYkPwSR9r2yBjkRSZGDakqlzDvfogLSpVYOPLOYOOPhWGzsMvpn3nqg wOb1fiPhtxtM8Y3v3f2g8HfBxdBUMSr+BlZx/ub6MMzuJaGyCfz1ktawGg5iLyU8V6w4 N5Ie0DtsLZ2lXTVmbuUHVapNhCHAPcmO3t/1OrGpE2XjUaTf4W2zegHN0Ze78Hqvat69 0tkydq7IPYbWZlscXbC75FW86E+FOnyDs6VctrRUgrvZSUlx/IyFG5ti3g5wwryDaCWr Dl3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187746; x=1712792546; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LYjXbKsZWObysa039N5fpdCtqQMANxENOQ8uS4k07nc=; b=dtgbsSIV+ZtpYmwF1JVn3g6eHelLwo6TQ2ZjiEuq2KZWBaC3T4SV7zxHIJ3KXCMjqH 3scOdGYHWBW0Pu//RK7n8aFlDJdnKQdj41snNHVsI2PrsnbV0XDGuvy1AFiFqfvVN56H xiDKhWn3Nzt3kAxjKRvfCLPdvFuijKxHQnFOLOid/9G7DJW91RYpuPRff4aP7NioGhYU 3FZFI1UPlJ3tKxCxq/RcUNzzkDSXmrlWBV0jKTLx2Nx65ymnYsnQxHCI+wUrUrTGjFnS VsdWDtWx7MmPn6Bp4CBzOHRmXseol0LRbaNHdTQ5UB0Hi+bsoJik9Y3vkpgdFDOAW+MR pBNA== X-Forwarded-Encrypted: i=1; AJvYcCXa8QfAo9Sgck0HpuemGK9L2s4APGxvY02ZoRn/MzoyZdhsWj4o1PsKQAIF9PDGDxkGhJ9V5dOZ2aQwOmKvZcc933YSuAFKlCVT69osJwMX X-Gm-Message-State: AOJu0YwBTc307qUeEdq1HQcoZkD3NPFI372AB74OmR6J8x1yFRShcp96 2FbsJkKavJg6CbjI4K8dcMLS7xrOFZpfCsCJzcT3ADaFflDBCW6u50GaBzTE2wo= X-Google-Smtp-Source: AGHT+IGqtyBuB5j2we7P/N7XV7ZwjjMEdcimxTlF2S48pW5kJG8K4vLP5TYFGyEOra5BjXZZI2wVPA== X-Received: by 2002:a17:903:244d:b0:1e0:e85b:3389 with SMTP id l13-20020a170903244d00b001e0e85b3389mr1058260pls.3.1712187746310; Wed, 03 Apr 2024 16:42:26 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.42.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:42:17 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 18/29] riscv: Implements arch agnostic shadow stack prctls Date: Wed, 3 Apr 2024 16:35:06 -0700 Message-ID: <20240403234054.2020347-19-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Implement architecture agnostic prctls() interface for setting and getting shadow stack status. prctls implemented are PR_GET_SHADOW_STACK_STATUS, PR_SET_SHADOW_STACK_STATUS and PR_LOCK_SHADOW_STACK_STATUS. As part of PR_SET_SHADOW_STACK_STATUS/PR_GET_SHADOW_STACK_STATUS, only PR_SHADOW_STACK_ENABLE is implemented because RISCV allows each mode to write to their own shadow stack using `sspush` or `ssamoswap`. PR_LOCK_SHADOW_STACK_STATUS locks current configuration of shadow stack enabling. Signed-off-by: Deepak Gupta --- arch/riscv/include/asm/usercfi.h | 18 +++++- arch/riscv/kernel/process.c | 8 +++ arch/riscv/kernel/usercfi.c | 107 +++++++++++++++++++++++++++++++ 3 files changed, 132 insertions(+), 1 deletion(-) diff --git a/arch/riscv/include/asm/usercfi.h b/arch/riscv/include/asm/usercfi.h index b47574a7a8c9..a168ae0fa5d8 100644 --- a/arch/riscv/include/asm/usercfi.h +++ b/arch/riscv/include/asm/usercfi.h @@ -7,6 +7,7 @@ #ifndef __ASSEMBLY__ #include +#include struct task_struct; struct kernel_clone_args; @@ -14,7 +15,8 @@ struct kernel_clone_args; #ifdef CONFIG_RISCV_USER_CFI struct cfi_status { unsigned long ubcfi_en : 1; /* Enable for backward cfi. */ - unsigned long rsvd : ((sizeof(unsigned long)*8) - 1); + unsigned long ubcfi_locked : 1; + unsigned long rsvd : ((sizeof(unsigned long)*8) - 2); unsigned long user_shdw_stk; /* Current user shadow stack pointer */ unsigned long shdw_stk_base; /* Base address of shadow stack */ unsigned long shdw_stk_size; /* size of shadow stack */ @@ -26,6 +28,10 @@ void shstk_release(struct task_struct *tsk); void set_shstk_base(struct task_struct *task, unsigned long shstk_addr, unsigned long size); void set_active_shstk(struct task_struct *task, unsigned long shstk_addr); bool is_shstk_enabled(struct task_struct *task); +bool is_shstk_locked(struct task_struct *task); +void set_shstk_status(struct task_struct *task, bool enable); + +#define PR_SHADOW_STACK_SUPPORTED_STATUS_MASK (PR_SHADOW_STACK_ENABLE) #else @@ -56,6 +62,16 @@ static inline bool is_shstk_enabled(struct task_struct *task) return false; } +static inline bool is_shstk_locked(struct task_struct *task) +{ + return false; +} + +static inline void set_shstk_status(struct task_struct *task, bool enable) +{ + +} + #endif /* CONFIG_RISCV_USER_CFI */ #endif /* __ASSEMBLY__ */ diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c index ef48a25b0eff..3fb8b23f629b 100644 --- a/arch/riscv/kernel/process.c +++ b/arch/riscv/kernel/process.c @@ -145,6 +145,14 @@ void start_thread(struct pt_regs *regs, unsigned long pc, regs->epc = pc; regs->sp = sp; + /* + * clear shadow stack state on exec. + * libc will set it later via prctl. + */ + set_shstk_status(current, false); + set_shstk_base(current, 0, 0); + set_active_shstk(current, 0); + #ifdef CONFIG_64BIT regs->status &= ~SR_UXL; diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c index 11ef7ab925c9..cdedf1f78b3e 100644 --- a/arch/riscv/kernel/usercfi.c +++ b/arch/riscv/kernel/usercfi.c @@ -24,6 +24,16 @@ bool is_shstk_enabled(struct task_struct *task) return task->thread_info.user_cfi_state.ubcfi_en ? true : false; } +bool is_shstk_allocated(struct task_struct *task) +{ + return task->thread_info.user_cfi_state.shdw_stk_base ? true : false; +} + +bool is_shstk_locked(struct task_struct *task) +{ + return task->thread_info.user_cfi_state.ubcfi_locked ? true : false; +} + void set_shstk_base(struct task_struct *task, unsigned long shstk_addr, unsigned long size) { task->thread_info.user_cfi_state.shdw_stk_base = shstk_addr; @@ -42,6 +52,23 @@ void set_active_shstk(struct task_struct *task, unsigned long shstk_addr) task->thread_info.user_cfi_state.user_shdw_stk = shstk_addr; } +void set_shstk_status(struct task_struct *task, bool enable) +{ + task->thread_info.user_cfi_state.ubcfi_en = enable ? 1 : 0; + + if (enable) + task->thread_info.envcfg |= ENVCFG_SSE; + else + task->thread_info.envcfg &= ~ENVCFG_SSE; + + csr_write(CSR_ENVCFG, task->thread_info.envcfg); +} + +void set_shstk_lock(struct task_struct *task) +{ + task->thread_info.user_cfi_state.ubcfi_locked = 1; +} + /* * If size is 0, then to be compatible with regular stack we want it to be as big as * regular stack. Else PAGE_ALIGN it and return back @@ -268,3 +295,83 @@ void shstk_release(struct task_struct *tsk) vm_munmap(base, size); set_shstk_base(tsk, 0, 0); } + +int arch_get_shadow_stack_status(struct task_struct *t, unsigned long __user *status) +{ + unsigned long bcfi_status = 0; + + if (!cpu_supports_shadow_stack()) + return -EINVAL; + + /* this means shadow stack is enabled on the task */ + bcfi_status |= (is_shstk_enabled(t) ? PR_SHADOW_STACK_ENABLE : 0); + + return copy_to_user(status, &bcfi_status, sizeof(bcfi_status)) ? -EFAULT : 0; +} + +int arch_set_shadow_stack_status(struct task_struct *t, unsigned long status) +{ + unsigned long size = 0, addr = 0; + bool enable_shstk = false; + + if (!cpu_supports_shadow_stack()) + return -EINVAL; + + /* Reject unknown flags */ + if (status & ~PR_SHADOW_STACK_SUPPORTED_STATUS_MASK) + return -EINVAL; + + /* bcfi status is locked and further can't be modified by user */ + if (is_shstk_locked(t)) + return -EINVAL; + + enable_shstk = status & PR_SHADOW_STACK_ENABLE; + /* Request is to enable shadow stack and shadow stack is not enabled already */ + if (enable_shstk && !is_shstk_enabled(t)) { + /* shadow stack was allocated and enable request again + * no need to support such usecase and return EINVAL. + */ + if (is_shstk_allocated(t)) + return -EINVAL; + + size = calc_shstk_size(0); + addr = allocate_shadow_stack(0, size, 0, false); + if (IS_ERR_VALUE(addr)) + return -ENOMEM; + set_shstk_base(t, addr, size); + set_active_shstk(t, addr + size); + } + + /* + * If a request to disable shadow stack happens, let's go ahead and release it + * Although, if CLONE_VFORKed child did this, then in that case we will end up + * not releasing the shadow stack (because it might be needed in parent). Although + * we will disable it for VFORKed child. And if VFORKed child tries to enable again + * then in that case, it'll get entirely new shadow stack because following condition + * are true + * - shadow stack was not enabled for vforked child + * - shadow stack base was anyways pointing to 0 + * This shouldn't be a big issue because we want parent to have availability of shadow + * stack whenever VFORKed child releases resources via exit or exec but at the same + * time we want VFORKed child to break away and establish new shadow stack if it desires + * + */ + if (!enable_shstk) + shstk_release(t); + + set_shstk_status(t, enable_shstk); + return 0; +} + +int arch_lock_shadow_stack_status(struct task_struct *task, + unsigned long arg) +{ + /* If shtstk not supported or not enabled on task, nothing to lock here */ + if (!cpu_supports_shadow_stack() || + !is_shstk_enabled(task)) + return -EINVAL; + + set_shstk_lock(task); + + return 0; +} From patchwork Wed Apr 3 23:35:08 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785578 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D3D715991C for ; Wed, 3 Apr 2024 23:42:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187754; cv=none; b=ODWhpOsCtWHF3gyZGxQJlvfpwseVp1IN8nIw+DcQs/u93FFZN29w/QuHVjCYUidBtwJSyQ+OFSDpwHemvGAvQgfmwwKhSL66ZDWJZlG/NX/6PPds5mkOMuji9n6NarVs8xHgSHteYZQG5V+UqxwAnC45doI/ibbe5o7pf3LGnSg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187754; c=relaxed/simple; bh=+UdJVnxzhmL2rdbI+oZOPCA50rkIsX+rxI4MUuund6Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=csGKPvjxrV4xWTTavblcW0skf+z74NKlbd+cDLhd+0Zx8yOIrDFORWJ5fFRs55ky8twvo1MjV6R2aC1htk8EfVNUdGcpdRsLYXlWzfCX1it68z1oCttfdF3IcA/owLY6iqSS0o/CO0hl34MKmvUDtmeJb7LuzAheRz726LNTzDw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=hcRRCZ/o; arc=none smtp.client-ip=209.85.214.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="hcRRCZ/o" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-1dff837d674so3268995ad.3 for ; Wed, 03 Apr 2024 16:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187751; x=1712792551; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=MSiG1xhiflfyI9bPxIgqPsLfJsD+ZxoOiAqpJ0kRoxs=; b=hcRRCZ/o9lYHMulcB9q8PwWpcv9PXJNWRi3viSgowhd9ObyUXJdpqvwbCCa7m2kRi9 2skbIqH52jYKm4bftBNANkcezUv7bfpamfL7bCZZsCDW4/2876HeequmTQXmHrn48uZ5 NLLTcd/zo3JBbBMkKXDbBgHMqsJusiw9I+idCq48BYWbq2s/9+ZCivPUpPJw+8zRujFT E37QRbZAj4A7gG52o0sFHqjPUXD73arbeAOEAcjDd3x7SdACh4gnyKobMP98+Tbj2lEX sBYCcYojfIbeMW1L/RUTtvdb1aa1VtbOLN2C+PlSKwmARrHFxzP9HcIwK5wAvkvrD710 K4IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187751; x=1712792551; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MSiG1xhiflfyI9bPxIgqPsLfJsD+ZxoOiAqpJ0kRoxs=; b=Xt16AuIaw0b3xRg2F9bIsia4YsesIbzQdLZf+8aFTjDuTloUxD1RM4zgIf7tq3sEGP xps65hsV5vlpndlTiwRk3kYUAYSN9yCyftYoFWTLFqWupjKQ5Cu3p3V/1jxSugEIbU73 ZaHjSzdF2g5ic4/Vf3pkVxZ82Jtl+3syRRKZGBEEqbCjtbmqG+g1YzrQfahtGrIrw/YI DpoGcFsa1ps44dQEqfc6QEbeQNZX5dEx0oXj+wXEOtThrQPxnzEDIOooHV2U34VkT2KG JkszX3nqvFklcaQZuTJ+jfJYm3ZJRJC9A21h/7BSNZqai+ZcYqiQrxhIDWgaN0XMi1f3 MmVg== X-Forwarded-Encrypted: i=1; AJvYcCWASDDZmTebs09TRC4MK2p5CfBsDuhdxHwnrayQgGsGTuYp96GgOG9KINKkIwVYYEk82WVxgAAWUhkDnlsk62Yw2wFzfp9lY+mpIFNrfCth X-Gm-Message-State: AOJu0YzIqWEYhlgobNg7o2NfC7WHuhj8Cq9Ul+qVACc9/vDG84QHzrPt t5TuFXRgchzFmdo7DKeMsR0KnFJuTzu/1dm1qpuXWkKiDnyf34UZBdPod4WrYM8= X-Google-Smtp-Source: AGHT+IFMW5tbyyAjWJEE1nX9dbuRREm7VgmFXgOohN5Mrb4B/RniQlSV9gFzsZCwXmsG8xWhwnLhWw== X-Received: by 2002:a17:903:487:b0:1df:f6ce:c9b3 with SMTP id jj7-20020a170903048700b001dff6cec9b3mr824638plb.43.1712187751469; Wed, 03 Apr 2024 16:42:31 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.42.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:42:31 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 20/29] riscv/kernel: update __show_regs to print shadow stack register Date: Wed, 3 Apr 2024 16:35:08 -0700 Message-ID: <20240403234054.2020347-21-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Updating __show_regs to print captured shadow stack pointer as well. On tasks where shadow stack is disabled, it'll simply print 0. Signed-off-by: Deepak Gupta Reviewed-by: Alexandre Ghiti --- arch/riscv/kernel/process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c index ebed7589c51a..079fd6cd6446 100644 --- a/arch/riscv/kernel/process.c +++ b/arch/riscv/kernel/process.c @@ -89,8 +89,8 @@ void __show_regs(struct pt_regs *regs) regs->s8, regs->s9, regs->s10); pr_cont(" s11: " REG_FMT " t3 : " REG_FMT " t4 : " REG_FMT "\n", regs->s11, regs->t3, regs->t4); - pr_cont(" t5 : " REG_FMT " t6 : " REG_FMT "\n", - regs->t5, regs->t6); + pr_cont(" t5 : " REG_FMT " t6 : " REG_FMT " ssp : " REG_FMT "\n", + regs->t5, regs->t6, get_active_shstk(current)); pr_cont("status: " REG_FMT " badaddr: " REG_FMT " cause: " REG_FMT "\n", regs->status, regs->badaddr, regs->cause); From patchwork Wed Apr 3 23:35:10 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785577 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 470EB15B0E0 for ; Wed, 3 Apr 2024 23:42:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187758; cv=none; b=esHcvTqSV8r4LttNmJvzSKdexB6pJwvUTrMuPfPa2yTO0R1M2WjckuZASmo5CR+qG/AENiHsx8grBP8yU8/fIPuIBFu8TnKhAB06xaijSBcDhl8LhmwRnCGUyHAkjMSiHPu73IwI2w2qtDl+GyGre+LbUQVUTIduqMxWkZI8yeE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187758; c=relaxed/simple; bh=pKLFkKzJOJ8TVEvV0fhdtvjJa4v5yVb6+o0QMASZ3Hg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FAhax5EqvkxHeShndSznmjp0uH1GqeWGDtUKak+1XwLyLfwyneom9m30BtZy0F/oHDrOJqwiwH8vO4Uxwpk5BjM0LL4AADEzLDfk1q77ig34o17V9JUfeVHoH0kly13QpHgVK0mEcL8So9RUqtXE+mVkUCQWh2nn5LDHg6NiSbw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=zeonD28X; arc=none smtp.client-ip=209.85.214.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="zeonD28X" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1e2a2d5f0b7so2878535ad.1 for ; Wed, 03 Apr 2024 16:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187757; x=1712792557; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Qc6tDQVZMFWZI8yrez6t0wejTQ8xJVxgJAnHf9JsPCA=; b=zeonD28X8y+FbBr/1sLhYcVnrAHddElHMKnmeCwKi4dbok67AVeZwn0LlwQwqiXPiU PGEr6z1DIE7hog6DHEU8Qnh9cBt0/tuhYK9yky9U0GVHKAJhg/i2Zt+CRKAYf1aS9EZd r4aAqk3N9y64MDJ+l6pIrLb1Os+E6HWCyQXc0+aTvtjva+sT2wRfbQTWqCk7mMVoCy0S PsIeUS8+gi3CBkFAd4NDBSsT1DHzoZaeCulmT5NVlQg2NASCnQD1FOgi41lSfhWogFj3 lcxS2z/D7X1rxtQpaz1RgzV096xVoLLocVfyJK+xLrcfil6+MuSH6f6aQ2z1G3gmeuzz jUOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187757; x=1712792557; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Qc6tDQVZMFWZI8yrez6t0wejTQ8xJVxgJAnHf9JsPCA=; b=k9DOVkOdcoK06z/MxZJDa7iOSHNXj3I6N/eY4CxXahmzQoxvt5LtQP3X2WqoBMv1Yo +44Cg2pFEzJOvwBLArj+u1H1eFOyUXWFr7o27lpBbWpgHL+ztGJhzO0tafpZbhOMw4xX xquV5/7izbW+eKU+k+7pzX8sTNJ5qJeBztsZXvQV2VAj9Y8BL3G3t2GOATKaZ29uSGNh QuHA/2I/bKlOxe/BOhHHREsnca4sqE7H4WeUksLyxkaJ7m7D86rAZSLYvm10URYb1ouh EVAeT2LKqYmR0CGY7Ssn/ymKYvjB/4nWCq+AuaFa7aqjvxPyO587c7OYut1SD+cDdhWM DOgA== X-Forwarded-Encrypted: i=1; AJvYcCWQLVMBGTjQgbGUYbrcLP5YsF+JvNlv7YNSdb1PCEKsIVJ+QxgcRREeOQ/mowTe2OMZMCimSWcLsWIB08UJ5bynosjfz/q4Bj2xgC47T34M X-Gm-Message-State: AOJu0Yx9y/2Ry3Py7pOLvLBO4DwxURZdxZvbQ1UaY2eH+4oiAtAPubWg GxnUOaoIhZzv09GLBF/c7YtRFfPiCvOfeeZ7jb3WreeCwAwXTHLWE/fK5+6ybDI= X-Google-Smtp-Source: AGHT+IEuhCBj/2TDLKKsCyPyIBeMUKZ3rkD1bUlrx/H25eFGajkGFoQcn3/TeMJd7JPKfofV2mRlIQ== X-Received: by 2002:a17:902:d506:b0:1e0:cdbf:24c2 with SMTP id b6-20020a170902d50600b001e0cdbf24c2mr951254plg.29.1712187756641; Wed, 03 Apr 2024 16:42:36 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.42.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:42:36 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 22/29] riscv sigcontext: adding cfi state field in sigcontext Date: Wed, 3 Apr 2024 16:35:10 -0700 Message-ID: <20240403234054.2020347-23-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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/include/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; union { union __riscv_fp_state sc_fpregs; struct __riscv_extra_ext_header sc_extdesc; From patchwork Wed Apr 3 23:35:12 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785576 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E705615B541 for ; Wed, 3 Apr 2024 23:42:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.175 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187764; cv=none; b=GkGMyGYVHF/Lr5AyO9hQflaxTOpZL0/kKZPLts7PDzNajSJgVaWROWjL/IvfYvJ3QQ6iZkDoO54JPjFI0KmRxr40W0vTsi0zFesSCQeZ4EVJjdP8Sn1Rzv7SXncI+wgtFrhARNZ4+dEEHWP/DV5816NrBslmVVOlUAfPCkwci/Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187764; c=relaxed/simple; bh=l/nyvaOgUV9mE95wDYkfkeHkD4SONVQazcZc1dFrpBI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hMLIu7UhFaH8QaSpUbmutjfSgCNruWd+p0hbyB7VSTOwusyGX/gGGtxbpquc/tSvZAWPECDogvI6dtcSYJY+zlesAC3+BKb8lL9+2YxGzbzCzXtbhvYcEyr8ZRxlMyt3z7oyp7+nb8j8pcRB3sY5e4iwYMfT05fZjsmfY85+usI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=dTuQKAgV; arc=none smtp.client-ip=209.85.210.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="dTuQKAgV" Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-6e74bd85f26so359001b3a.1 for ; Wed, 03 Apr 2024 16:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187762; x=1712792562; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=J4h29gLixoMV8jqguvN/5Pzgz4C0EFoOwStmiEzJSk4=; b=dTuQKAgVUJ0XzCVllrEPLQ1FPbO6krXIxuVMEnAP2FCj73uhgAW87nUT8GKAjim7I3 laklmnMWQ/oLU2nqUbpzPMYoG9ixc31NSYwgOaUFe15dB0nmSvjwEfSkf/XW2oQEQiHZ zeCF4vIBjX5cOPhyqAYkeQBhBqMgj51F2Txq5vPFK813Stc+aRIdYTLYjdQtFdcMyVkN DoIUVsS/iS6CIs/+sXJfqdOjDWfK0pGqBYSpjKufMJnRigcC7fF/NCn91z3/hkA4SZRy XHSQ+tpt5KDbFknjyJKvHzMDpuChgtzMrczDfROrE8Lu34Kh9/zisky/seydFDt3Ctwf /fLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187762; x=1712792562; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=J4h29gLixoMV8jqguvN/5Pzgz4C0EFoOwStmiEzJSk4=; b=KyQ2kzMJ9FJeNvrIvlxtIHrEgB3PNt8Bhpy7pROvrGS4wEvI3UBpKEsoSOP0zzJkon oC3vNV46mtr98iJPGmho66jSiZE2hss0R2PaS7vYurb+GTos8MVPSgTF6VeWBqOzysxX roB5zyNXJn04BKvPrZdGat5MW8Xv4S/lhx+w9+/G6ADBBVFZJuyzVWiPA3mqsOJA+dFh Liuc1TxTS+M5Qza1PoJ35i62Jctczyr1kXwiUIHg+w1prGLbZ2beMVoXqy+OVCTj0Lw9 Hve+373JWQfo9PGbY5AzCyvHNBk0q0L2bpbBGR/VSR6gVDSl3mNm0G5mtAB2s6bCHOzt LH7Q== X-Forwarded-Encrypted: i=1; AJvYcCWXrcfzenq9Ru8fB58ChxNl48wn6UJYZLQ6h+EODS+o87OHMA9CGhEZkhXySFMXJosCsAvewjeh/H89LY+YBdGsYxVvuF10GfE7iwe/eldQ X-Gm-Message-State: AOJu0YyUhAKAHLLkmElub8kgqIAB9Gytre5Quwzvadf7xQlFIYetCeTb Jb5za1AQtVeKEVGxpVm6WB22ixx6Y6ESbOu4Bh5XTnpOVNIx9KTYrIPgfa+22Zo= X-Google-Smtp-Source: AGHT+IG6JjvBwkxgqryw6XYXQuT6s6l7JFwHNmCUllxfSiPnkNHrCcfUHOA44/lFJ8XzXC2yFAlGAA== X-Received: by 2002:a05:6a20:6a0b:b0:1a7:ea4:e13a with SMTP id p11-20020a056a206a0b00b001a70ea4e13amr1275128pzk.54.1712187761904; Wed, 03 Apr 2024 16:42:41 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.42.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:42:41 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 24/29] riscv/ptrace: riscv cfi status and state via ptrace and in core files Date: Wed, 3 Apr 2024 16:35:12 -0700 Message-ID: <20240403234054.2020347-25-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Expose a new register type NT_RISCV_USER_CFI for risc-v cfi status and state. Intentionally both landing pad and shadow stack status and state are rolled into cfi state. Creating two different NT_RISCV_USER_XXX would not be useful and wastage of a note type. Enabling or disabling of feature is not allowed via ptrace set interface. However setting `elp` state or setting shadow stack pointer are allowed via ptrace set interface. It is expected `gdb` might have use to fixup `elp` state or `shadow stack` pointer. Signed-off-by: Deepak Gupta --- arch/riscv/include/uapi/asm/ptrace.h | 18 ++++++ arch/riscv/kernel/ptrace.c | 83 ++++++++++++++++++++++++++++ include/uapi/linux/elf.h | 1 + 3 files changed, 102 insertions(+) diff --git a/arch/riscv/include/uapi/asm/ptrace.h b/arch/riscv/include/uapi/asm/ptrace.h index a38268b19c3d..512be06a8661 100644 --- a/arch/riscv/include/uapi/asm/ptrace.h +++ b/arch/riscv/include/uapi/asm/ptrace.h @@ -127,6 +127,24 @@ struct __riscv_v_regset_state { */ #define RISCV_MAX_VLENB (8192) +struct __cfi_status { + /* indirect branch tracking state */ + __u64 lp_en : 1; + __u64 lp_lock : 1; + __u64 elp_state : 1; + + /* shadow stack status */ + __u64 shstk_en : 1; + __u64 shstk_lock : 1; + + __u64 rsvd : sizeof(__u64) - 5; +}; + +struct user_cfi_state { + struct __cfi_status cfi_status; + __u64 shstk_ptr; +}; + #endif /* __ASSEMBLY__ */ #endif /* _UAPI_ASM_RISCV_PTRACE_H */ diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c index e8515aa9d80b..33d4b32cc6a7 100644 --- a/arch/riscv/kernel/ptrace.c +++ b/arch/riscv/kernel/ptrace.c @@ -19,6 +19,7 @@ #include #include #include +#include enum riscv_regset { REGSET_X, @@ -28,6 +29,9 @@ enum riscv_regset { #ifdef CONFIG_RISCV_ISA_V REGSET_V, #endif +#ifdef CONFIG_RISCV_USER_CFI + REGSET_CFI, +#endif }; static int riscv_gpr_get(struct task_struct *target, @@ -152,6 +156,75 @@ static int riscv_vr_set(struct task_struct *target, } #endif +#ifdef CONFIG_RISCV_USER_CFI +static int riscv_cfi_get(struct task_struct *target, + const struct user_regset *regset, + struct membuf to) +{ + struct user_cfi_state user_cfi; + struct pt_regs *regs; + + regs = task_pt_regs(target); + + user_cfi.cfi_status.lp_en = is_indir_lp_enabled(target); + user_cfi.cfi_status.lp_lock = is_indir_lp_locked(target); + user_cfi.cfi_status.elp_state = (regs->status & SR_ELP); + + user_cfi.cfi_status.shstk_en = is_shstk_enabled(target); + user_cfi.cfi_status.shstk_lock = is_shstk_locked(target); + user_cfi.shstk_ptr = get_active_shstk(target); + + return membuf_write(&to, &user_cfi, sizeof(user_cfi)); +} + +/* + * Does it make sense to allowing enable / disable of cfi via ptrace? + * Not allowing enable / disable / locking control via ptrace for now. + * Setting shadow stack pointer is allowed. GDB might use it to unwind or + * some other fixup. Similarly gdb might want to suppress elp and may want + * to reset elp state. + */ +static int riscv_cfi_set(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + const void *kbuf, const void __user *ubuf) +{ + int ret; + struct user_cfi_state user_cfi; + struct pt_regs *regs; + + regs = task_pt_regs(target); + + ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &user_cfi, 0, -1); + if (ret) + return ret; + + /* + * Not allowing enabling or locking shadow stack or landing pad + * There is no disabling of shadow stack or landing pad via ptrace + * rsvd field should be set to zero so that if those fields are needed in future + */ + if (user_cfi.cfi_status.lp_en || user_cfi.cfi_status.lp_lock || + user_cfi.cfi_status.shstk_en || user_cfi.cfi_status.shstk_lock || + !user_cfi.cfi_status.rsvd) + return -EINVAL; + + /* If lpad is enabled on target and ptrace requests to set / clear elp, do that */ + if (is_indir_lp_enabled(target)) { + if (user_cfi.cfi_status.elp_state) /* set elp state */ + regs->status |= SR_ELP; + else + regs->status &= ~SR_ELP; /* clear elp state */ + } + + /* If shadow stack enabled on target, set new shadow stack pointer */ + if (is_shstk_enabled(target)) + set_active_shstk(target, user_cfi.shstk_ptr); + + return 0; +} +#endif + static const struct user_regset riscv_user_regset[] = { [REGSET_X] = { .core_note_type = NT_PRSTATUS, @@ -182,6 +255,16 @@ static const struct user_regset riscv_user_regset[] = { .set = riscv_vr_set, }, #endif +#ifdef CONFIG_RISCV_USER_CFI + [REGSET_CFI] = { + .core_note_type = NT_RISCV_USER_CFI, + .align = sizeof(__u64), + .n = sizeof(struct user_cfi_state) / sizeof(__u64), + .size = sizeof(__u64), + .regset_get = riscv_cfi_get, + .set = riscv_cfi_set, + } +#endif }; static const struct user_regset_view riscv_user_native_view = { diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h index 9417309b7230..f60b2de66b1c 100644 --- a/include/uapi/linux/elf.h +++ b/include/uapi/linux/elf.h @@ -447,6 +447,7 @@ typedef struct elf64_shdr { #define NT_MIPS_MSA 0x802 /* MIPS SIMD registers */ #define NT_RISCV_CSR 0x900 /* RISC-V Control and Status Registers */ #define NT_RISCV_VECTOR 0x901 /* RISC-V vector registers */ +#define NT_RISCV_USER_CFI 0x902 /* RISC-V shadow stack state */ #define NT_LOONGARCH_CPUCFG 0xa00 /* LoongArch CPU config registers */ #define NT_LOONGARCH_CSR 0xa01 /* LoongArch control and status registers */ #define NT_LOONGARCH_LSX 0xa02 /* LoongArch Loongson SIMD Extension registers */ From patchwork Wed Apr 3 23:35:14 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785575 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D70415D5DA for ; Wed, 3 Apr 2024 23:42:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187769; cv=none; b=WTXaDvxhTSR9Hs4hIJI4Ce+HDTufdYu0dhJros9AWX6aQXuKvGM7gw5IBoXAnQAdRwOQ1OOBVMoxaOCk5ng3nKzOhHUadNVCPayTQ9x7DPmRGFAGDNDwnAyf7yGfWoSOZIqUKJLtxaplZyOwocGqy/9YKrH4aDOBRzKWyvn3q0c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187769; c=relaxed/simple; bh=gRUEuRotPJjUi2hlrSXSLGRWOK9UqoUEje/IwX9OQE8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JdImd1FUk/uLRR4AYFVeEnxdf6wD6F0zNtLSjNYZxB5ZIJfnB9mmnr87ByN2DV5F9KyjpPS0uFq4VY43sCksXiyoQbiOz78RyLU4G5H9e6qyX6qpuYZqTgMApqU4s+epJHKmVym7Dt6RNnHlaFTiwxQ7k8VeqJfLCt7j1AbEaaU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=YwMx341w; arc=none smtp.client-ip=209.85.210.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="YwMx341w" Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-6eac64f2205so302177b3a.2 for ; Wed, 03 Apr 2024 16:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187767; x=1712792567; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9DtlDgd/GAT0EKcB2AjZTXvg/KwB3A8UKH6yER0NyfA=; b=YwMx341wx/Wa3bsWUkv9/0EdOfHv8Zq9ZoouLn4DtRxapcnfryBzyRZhRVoBURgbWS XdAshDMADFJ7tkrqy1N8EtdmuEX29biH/cLgfTucRcQhBz9waC5NrkvyVyrzaPh7H2D8 ByrFBZQNk5w6tb1vI/Qw+BGzOrsF78WB0TzEfxO5IGKCzZrab7nPj9pRwBpMAqjeeeRT c4TYMLHVGPQKu0ZC+lO3XzbSVWAJPSshnE0J1yXcFtO5FdtVkGvlpuYGOIIAKJsQOzRP fRrGblFel1Cb2FBLr7xCOCUPXlMUGd0NaN1ribZ2jbmjzfiQJuWzX3g3qVcmaBZISzk1 8f1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187767; x=1712792567; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9DtlDgd/GAT0EKcB2AjZTXvg/KwB3A8UKH6yER0NyfA=; b=vx0lzHusKCsWlH7WXY87JcTrPKri7aAeGPibBnb5ilHf8MORD74KKZzNFtUsUukjxp +io3RlJ7Ygr/xuNwCq3ZXcmoM1AaM1GXeR3imjsSMERBtLZD2GL5jmPQM6AWX6XAN8hq qudV4yj/wQCoFdXAB0HVKdh0LiJN1nN9FUw6Wo8bHgN4QXFs5BzgGYva5/mr7dfdl2zW k4abgHx1+2felNXu159roMRlO7uswv4BovYLMr7Uc1oFfLpuCCHZ6Sca7SHb17IrgIp2 4NMN15t1Oekdd8ZHS/DUKbB3EkbajradwCBkLH+y9Twfs0hZG+G0n0+n6Os4BLnehg+q +ioQ== X-Forwarded-Encrypted: i=1; AJvYcCV9hRw6fIP/N+JgZA0RlAvnfVQqo1vhu30jNvoYPRy3360ly8DXaYX5igJZx0OjfeAeEC8JSExvSZ0iOYZE+aiDoWbPOMw3Kr0J4O8vFFUU X-Gm-Message-State: AOJu0Yzb0cejXGxMOQMt8c+epiQe98E0yFD5QgvgFDLKLOq7g9+ZvxOp /pOF9vR4LU4Khf/oTyN+2OXRPjnzZGscmu3DHBJmt4KLmljXmfIuN/zTlerJrbg= X-Google-Smtp-Source: AGHT+IGTlfFxuJFVldaZ8jYPJUINkZRKqV1i5a/wExLO9N1TqU40XTAEu7HYkbstJURl0N5AQEsIcg== X-Received: by 2002:a05:6a20:7285:b0:1a7:2437:3d58 with SMTP id o5-20020a056a20728500b001a724373d58mr1369671pzk.13.1712187767375; Wed, 03 Apr 2024 16:42:47 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.42.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:42:47 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 26/29] riscv: create a config for shadow stack and landing pad instr support Date: Wed, 3 Apr 2024 16:35:14 -0700 Message-ID: <20240403234054.2020347-27-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 This patch creates a config for shadow stack support and landing pad instr support. Shadow stack support and landing instr support can be enabled by selecting `CONFIG_RISCV_USER_CFI`. Selecting `CONFIG_RISCV_USER_CFI` wires up path to enumerate CPU support and if cpu support exists, kernel will support cpu assisted user mode cfi. Signed-off-by: Deepak Gupta --- arch/riscv/Kconfig | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 7e0b2bcc388f..d6f1303ef660 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -203,6 +203,24 @@ config ARCH_HAS_BROKEN_DWARF5 # https://github.com/llvm/llvm-project/commit/7ffabb61a5569444b5ac9322e22e5471cc5e4a77 depends on LD_IS_LLD && LLD_VERSION < 180000 +config RISCV_USER_CFI + def_bool y + bool "riscv userspace control flow integrity" + depends on 64BIT && $(cc-option,-mabi=lp64 -march=rv64ima_zicfiss) + depends on RISCV_ALTERNATIVE + select ARCH_USES_HIGH_VMA_FLAGS + help + Provides CPU assisted control flow integrity to userspace tasks. + Control flow integrity is provided by implementing shadow stack for + backward edge and indirect branch tracking for forward edge in program. + Shadow stack protection is a hardware feature that detects function + return address corruption. This helps mitigate ROP attacks. + Indirect branch tracking enforces that all indirect branches must land + on a landing pad instruction else CPU will fault. This mitigates against + JOP / COP attacks. Applications must be enabled to use it, and old user- + space does not get protection "for free". + default y + config ARCH_MMAP_RND_BITS_MIN default 18 if 64BIT default 8 From patchwork Wed Apr 3 23:35:16 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepak Gupta X-Patchwork-Id: 785574 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 997FF15E81E for ; Wed, 3 Apr 2024 23:42:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187775; cv=none; b=at8jhEKfcFRchb1FRkREsl2MlICF/8LzTmeEGpyA079sckF9VeMUJsVcOh8D0+Cf+0nayuXiYuKW5qEGOYzovKVflCFavW8SOHHqU+TcQEsFZcMloGLSuFUxb9zd4SF+i8WM4wULxzKyqqOpmXCXm2FEiRivvkSs3MEHclFv8P8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712187775; c=relaxed/simple; bh=ytxuax6WdZEec5SRof9IV0f225/VdU90/4UIn8N4SQc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BmaCOUDYSSTKk8KtEIVXtjmN8+lR2vnjjwlbMLKkLQpzw5uoELeuVGIvLjnZZhYig3DX4ElN0jn5WDVF+QMJ2DNu2CkRwtK9e3OSJhnxpifOjaFzsRhYOA79k5q7DNGL2vDSF3Z0+LZIvtxzwm0W5UAA0mvsDqJJsszgM4UAU0Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=mxkll87D; arc=none smtp.client-ip=209.85.214.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="mxkll87D" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1e0bfc42783so3409115ad.0 for ; Wed, 03 Apr 2024 16:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1712187773; x=1712792573; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9MOz30J7VxjH8ZagxzRr7bVMOq1rQVKKUTnSRMNh/j0=; b=mxkll87DV0ATLZ9zTYdIoZuOT8Phohg1edhTLd/+gHwH1rXuZRuvnLwDSIc4z0O9Ik oGLgvjX8NR6QuHH3/Ytp54RHRXpH7XwPgxhy19d6GJk4GcBf4mhwIUVYdtKI5eLetPAD e1jh3Wtu0/v18nYA6UIWg3aO3cZLLfQBVZFCLDWAQWJMxapBiYYH/Zlz0hTHBBhNdhPA 4mblBg7uZf4FL8x2kFwnWQzvHan57XHyoFyZP5jjLP2zboCoQIDCNOUhsTk6cnkuLcvd OBJ6Ua0tmBcDd5spagfNI6QLgjB4dD+UVw9JCsgQN62F+LNoY6b/rFyxLcxW36izr57Y ujqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712187773; x=1712792573; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9MOz30J7VxjH8ZagxzRr7bVMOq1rQVKKUTnSRMNh/j0=; b=JZ07J9GmJmx1hW4irA6qkdGfHl0ospC4KwqTAjL4cZnFW2wLeigsEMY0LT0YxoqcAv pTgScCV+uYD++iqEpw5ZVOKPZXnYgx2BxbKS8huSyJzliMnPn6XEUt0GgHh1Xhf2wudH kEEKN3VYJtGm4q1Ji6XL0D06fj7tRlAeQ6LNWCnvqVjXmBJISEjRRVJYWAqc/9WCRF8P GM+x3K+cKSDxQ2M435QfcOsmQtAN55qOwNNNHlUEY2XH3+4QJQyDmwrdIi0cOYLGHZuF wOShcpgd5wSu9TAL2Md8FJQakjffx4ayfBgpTCBmFilpVM1sbo2Os98zyWsqeOoGIq0K LLxA== X-Forwarded-Encrypted: i=1; AJvYcCUYX8HDGV8F0xoNBpBsAC8iihDk/oIehBr0F97aXo+8zzMtZwGbLLVbCw6Bt2R0me3LCk5aLM4lAp3H9Fu+70n6yknAtdcwXcBZotEVt4ih X-Gm-Message-State: AOJu0YzNYCskPd1Ku4gBJP3I7nqI+ZudI06TchqZNvtJNtBud0yEKgpI hM0pu81wLBrAL8GGkV3VvGgsnjQ8wtZeZq/rQVK0Qdc1w6yVmV77tbI4Q9fXviQ= X-Google-Smtp-Source: AGHT+IGyHrC5sNUT9pcK2iklG5WODUuUgmhPv4JAEYAUc1x1R1udLgCfkk9z11+70BxIHUT0LuGezw== X-Received: by 2002:a17:902:b788:b0:1e0:4dfd:c121 with SMTP id e8-20020a170902b78800b001e04dfdc121mr665961pls.68.1712187772970; Wed, 03 Apr 2024 16:42:52 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id b18-20020a170902d51200b001deeac592absm13899117plg.180.2024.04.03.16.42.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 16:42:52 -0700 (PDT) From: Deepak Gupta To: 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 Cc: 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, debug@rivosinc.com, andy.chiu@sifive.com, 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 Subject: [PATCH v3 28/29] riscv: Documentation for shadow stack on riscv Date: Wed, 3 Apr 2024 16:35:16 -0700 Message-ID: <20240403234054.2020347-29-debug@rivosinc.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> References: <20240403234054.2020347-1-debug@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Adding documentation on shadow stack for user mode on riscv and kernel interfaces exposed so that user tasks can enable it. Signed-off-by: Deepak Gupta --- Documentation/arch/riscv/zicfiss.rst | 169 +++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 Documentation/arch/riscv/zicfiss.rst diff --git a/Documentation/arch/riscv/zicfiss.rst b/Documentation/arch/riscv/zicfiss.rst new file mode 100644 index 000000000000..f133b6af9c15 --- /dev/null +++ b/Documentation/arch/riscv/zicfiss.rst @@ -0,0 +1,169 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Author: Deepak Gupta +:Date: 12 January 2024 + +========================================================= +Shadow stack to protect function returns on RISC-V Linux +========================================================= + +This document briefly describes the interface provided to userspace by Linux +to enable shadow stack for user mode applications on RISV-V + +1. Feature Overview +-------------------- + +Memory corruption issues usually result in to crashes, however when in hands of +an adversary and if used creatively can result into variety security issues. + +One of those security issues can be code re-use attacks on program where adversary +can use corrupt return addresses present on stack and chain them together to perform +return oriented programming (ROP) and thus compromising control flow integrity (CFI) +of the program. + +Return addresses live on stack and thus in read-write memory and thus are +susceptible to corruption and allows an adversary to reach any program counter +(PC) in address space. On RISC-V `zicfiss` extension provides an alternate stack +`shadow stack` on which return addresses can be safely placed in prolog of the +function and retrieved in epilog. `zicfiss` extension makes following changes + + - PTE encodings for shadow stack virtual memory + An earlier reserved encoding in first stage translation i.e. + PTE.R=0, PTE.W=1, PTE.X=0 becomes PTE encoding for shadow stack pages. + + - `sspush x1/x5` instruction pushes (stores) `x1/x5` to shadow stack. + + - `sspopchk x1/x5` instruction pops (loads) from shadow stack and compares + with `x1/x5` and if un-equal, CPU raises `software check exception` with + `*tval = 3` + +Compiler toolchain makes sure that function prologs have `sspush x1/x5` to save return +address on shadow stack in addition to regular stack. Similarly function epilogs have +`ld x5, offset(x2)`; `sspopchk x5` to ensure that popped value from regular stack +matches with popped value from shadow stack. + +2. Shadow stack protections and linux memory manager +----------------------------------------------------- + +As mentioned earlier, shadow stack get new page table encodings and thus have some +special properties assigned to them and instructions that operate on them as below + + - Regular stores to shadow stack memory raises access store faults. + This way shadow stack memory is protected from stray inadvertant + writes + + - Regular loads to shadow stack memory are allowed. + This allows stack trace utilities or backtrace functions to read + true callstack (not tampered) + + - Only shadow stack instructions can generate shadow stack load or + shadow stack store. + + - Shadow stack load / shadow stack store on read-only memory raises + AMO/store page fault. Thus both `sspush x1/x5` and `sspopchk x1/x5` + will raise AMO/store page fault. This simplies COW handling in kernel + During fork, kernel can convert shadow stack pages into read-only + memory (as it does for regular read-write memory) and as soon as + subsequent `sspush` or `sspopchk` in userspace is encountered, then + kernel can perform COW. + + - Shadow stack load / shadow stack store on read-write, read-write- + execute memory raises an access fault. This is a fatal condition + because shadow stack should never be operating on read-write, read- + write-execute memory. + +3. ELF and psABI +----------------- + +Toolchain sets up `GNU_PROPERTY_RISCV_FEATURE_1_BCFI` for property +`GNU_PROPERTY_RISCV_FEATURE_1_AND` in notes section of the object file. + +4. Linux enabling +------------------ + +User space programs can have multiple shared objects loaded in its address space +and it's a difficult task to make sure all the dependencies have been compiled +with support of shadow stack. Thus it's left to dynamic loader to enable +shadow stack for the program. + +5. prctl() enabling +-------------------- + +`PR_SET_SHADOW_STACK_STATUS` / `PR_GET_SHADOW_STACK_STATUS` / +`PR_LOCK_SHADOW_STACK_STATUS` are three prctls added to manage shadow stack +enabling for tasks. prctls are arch agnostic and returns -EINVAL on other arches. + +`PR_SET_SHADOW_STACK_STATUS`: If arg1 `PR_SHADOW_STACK_ENABLE` and if CPU supports +`zicfiss` then kernel will enable shadow stack for the task. Dynamic loader can +issue this `prctl` once it has determined that all the objects loaded in address +space have support for shadow stack. Additionally if there is a `dlopen` to an +object which wasn't compiled with `zicfiss`, dynamic loader can issue this prctl +with arg1 set to 0 (i.e. `PR_SHADOW_STACK_ENABLE` being clear) + +`PR_GET_SHADOW_STACK_STATUS`: Returns current status of indirect branch tracking. +If enabled it'll return `PR_SHADOW_STACK_ENABLE` + +`PR_LOCK_SHADOW_STACK_STATUS`: Locks current status of shadow stack enabling on the +task. User space may want to run with strict security posture and wouldn't want +loading of objects without `zicfiss` support in it and thus would want to disallow +disabling of shadow stack on current task. In that case user space can use this prctl +to lock current settings. + +5. violations related to returns with shadow stack enabled +----------------------------------------------------------- + +Pertaining to shadow stack, CPU raises software check exception in following +condition + + - On execution of `sspopchk x1/x5`, x1/x5 didn't match top of shadow stack. + If mismatch happens then cpu does `*tval = 3` and raise software check + exception + +Linux kernel will treat this as `SIGSEV`` with code = `SEGV_CPERR` and follow +normal course of signal delivery. + +6. Shadow stack tokens +----------------------- +Regular stores on shadow stacks are not allowed and thus can't be tampered with via +arbitrary stray writes due to bugs. Method of pivoting / switching to shadow stack +is simply writing to csr `CSR_SSP` changes active shadow stack. This can be problematic +because usually value to be written to `CSR_SSP` will be loaded somewhere in writeable +memory and thus allows an adversary to corruption bug in software to pivot to an any +address in shadow stack range. Shadow stack tokens can help mitigate this problem by +making sure that: + + - When software is switching away from a shadow stack, shadow stack pointer should be + saved on shadow stack itself and call it `shadow stack token` + + - When software is switching to a shadow stack, it should read the `shadow stack token` + from shadow stack pointer and verify that `shadow stack token` itself is pointer to + shadow stack itself. + + - Once the token verification is done, software can perform the write to `CSR_SSP` to + switch shadow stack. + +Here software can be user mode task runtime itself which is managing various contexts +as part of single thread. Software can be kernel as well when kernel has to deliver a +signal to user task and must save shadow stack pointer. Kernel can perform similar +procedure by saving a token on user shadow stack itself. This way whenever sigreturn +happens, kernel can read the token and verify the token and then switch to shadow stack. +Using this mechanism, kernel helps user task so that any corruption issue in user task +is not exploited by adversary by arbitrarily using `sigreturn`. Adversary will have to +make sure that there is a `shadow stack token` in addition to invoking `sigreturn` + +7. Signal shadow stack +----------------------- +Following structure has been added to sigcontext for RISC-V. `rsvd` field has been kept +in case we need some extra information in future for landing pads / indirect branch +tracking. It has been kept today in order to allow backward compatibility in future. + +struct __sc_riscv_cfi_state { + unsigned long ss_ptr; + unsigned long rsvd; +}; + +As part of signal delivery, shadow stack token is saved on current shadow stack itself and +updated pointer is saved away in `ss_ptr` field in `__sc_riscv_cfi_state` under `sigcontext` +Existing shadow stack allocation is used for signal delivery. During `sigreturn`, kernel will +obtain `ss_ptr` from `sigcontext` and verify the saved token on shadow stack itself and switch +shadow stack.