From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87659C04FFE for ; Thu, 9 May 2024 00:33:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 049A16B007B; Wed, 8 May 2024 20:33:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F150B6B0085; Wed, 8 May 2024 20:33:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D66F36B0089; Wed, 8 May 2024 20:33:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B57E76B007B for ; Wed, 8 May 2024 20:33:25 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 584EC120EA5 for ; Thu, 9 May 2024 00:33:25 +0000 (UTC) X-FDA: 82096983570.21.29A4300 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by imf17.hostedemail.com (Postfix) with ESMTP id 684D14001A for ; Thu, 9 May 2024 00:33:23 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=CMCeTPeD; spf=pass (imf17.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.215.176 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715214803; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ryuqORYcPz0+pc/IX1bINOqGn4QcbQeAD0aN/YcW+a0=; b=WVJ8HNxIQUbit4skOji2kRrG9Wb3+OwYo67Bqwd3OgKuCn39LbqGO0taaxHpjl0+c6CvS0 DtGQ4xr2Xfn4c+ZctFNuMVE5nmmW/n0sZL0oP0+YNvwYpNY6dmN1NXlbTBompC5Etp9koN 1efeYdcZEtKxcmlqTylwDXwHhG6kRRY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=CMCeTPeD; spf=pass (imf17.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.215.176 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715214803; a=rsa-sha256; cv=none; b=2qHmnDLo3K9Zw+dvb8IaOH++pFHnWi7SMzaKJEJtulB2rMYeQ3i1WnVuy9ZPbKYzLi05oo +mYaDe/Z+5nIlw4LqJq936y1W68XB0BCclwF9tIyIX+9cqv0/YjV24FbLzm99HU8TJEyde y+fOG4wunOu2J8YOJ7NVQGMdeuOi1Kc= Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-6333b2551ebso271034a12.0 for ; Wed, 08 May 2024 17:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1715214802; x=1715819602; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ryuqORYcPz0+pc/IX1bINOqGn4QcbQeAD0aN/YcW+a0=; b=CMCeTPeD9GaWdajdffVr9XbmQ4liNxYl388LVscwY8sh0oB6DYWjPIDAs0GFJEAjEi lB4pME5daBrGF75MbT3g4yYe1FX/wUOA57ZxiICvcOU8HmrCQWkfvEXOc2CR7U7vIlW3 FNV70gQUWdh3DAd8L4TDBElx1KI9BzaJ07mC958LMzakOG8Qe4Rvq0aYucBAlcWM2M67 9RqylEIYpCBe2Hs0IqfpNGrbvEP/SVjXfuUywWO6+KOoB0SXPoNFAUTITKY8ly0aSCB7 zR61KnZdvmKaWChBKEjGoO3j+zTA9SJOcX8YEbOCnRB0O1JIqGzSWDRnpxszC5rS5+P4 knKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715214802; x=1715819602; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ryuqORYcPz0+pc/IX1bINOqGn4QcbQeAD0aN/YcW+a0=; b=DzMn6HFEIfrF5MKfaob5PWVhZS8Hp0+buF8U/iERtipOKILs09CTC5Xw5U1zByl+Cb 8uKV6Pb7mOqhDqBA5AN2Re0sXeJcpn3p6m3rCH1q/+py/Qo3BGEN7DyKBvewxUKC96Rn 5Es3MTgs76j+N+q0/6Ye/ZM1qK20cmyFv282BEwby2GQmaXtia4v2dwPC3tJikcVE+Z+ i/slhBtUiV2FF3zBwyQEH0ce9ml+g+pe0+fK0+SWz4jY+LEXwJu77ESIfyZEtYUzHvFm vum1yeD6IeTYWCWt4AzPPiIGxLf21L2/zKj0fKSZha9Pa4B66GzCdn8vgZogyQ09PDwj 6B9g== X-Forwarded-Encrypted: i=1; AJvYcCUKZgeb57+ehhR0Y+W3I0Dar6ZJV4PWCYrSpyGKl0i0e/qduYOAmBO4X0uDGdoY4DkKSC4bA74PxN2GmpqqwYraOWs= X-Gm-Message-State: AOJu0YwgDfpYe3iKugeFokDrK1k6aI3bUWGJy1GMNln6CYL9imkNoFcL Qibsv9WUrvksq2ylCpMOJum8m+/U8WSvojexLfDOR3iKjmKLPbEKmNLBYxJQPV0= X-Google-Smtp-Source: AGHT+IHdropjLT7GTh0X7WVpcuGcFXvciZz0PPopuVK7WREz89rBGsBlLrTpoRWlSn9JTjqGGz8pew== X-Received: by 2002:a17:90a:d50b:b0:2a5:be1a:6831 with SMTP id 98e67ed59e1d1-2b65fe213cfmr1805609a91.19.1715214801866; Wed, 08 May 2024 17:33:21 -0700 (PDT) Received: from ghost ([2601:647:5700:6860:4144:6911:574f:fec1]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2b67126ac21sm169379a91.30.2024.05.08.17.33.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 May 2024 17:33:21 -0700 (PDT) Date: Wed, 8 May 2024 17:33:15 -0700 From: Charlie Jenkins To: Deepak Gupta Cc: paul.walmsley@sifive.com, rick.p.edgecombe@intel.com, broonie@kernel.org, Szabolcs.Nagy@arm.com, kito.cheng@sifive.com, keescook@chromium.org, ajones@ventanamicro.com, conor.dooley@microchip.com, cleger@rivosinc.com, atishp@atishpatra.org, alex@ghiti.fr, bjorn@rivosinc.com, alexghiti@rivosinc.com, samuel.holland@sifive.com, conor@kernel.org, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org, corbet@lwn.net, palmer@dabbelt.com, aou@eecs.berkeley.edu, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, oleg@redhat.com, akpm@linux-foundation.org, arnd@arndb.de, ebiederm@xmission.com, Liam.Howlett@oracle.com, vbabka@suse.cz, lstoakes@gmail.com, shuah@kernel.org, brauner@kernel.org, andy.chiu@sifive.com, jerry.shih@sifive.com, hankuan.chen@sifive.com, greentime.hu@sifive.com, evan@rivosinc.com, xiao.w.wang@intel.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: Re: [PATCH v3 00/29] riscv control-flow integrity for usermode Message-ID: References: <20240403234054.2020347-1-debug@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240403234054.2020347-1-debug@rivosinc.com> X-Stat-Signature: 9xntaaxciinzdr6rexwqkb5s8d1t6r77 X-Rspam-User: X-Rspamd-Queue-Id: 684D14001A X-Rspamd-Server: rspam05 X-HE-Tag: 1715214803-80070 X-HE-Meta: U2FsdGVkX18PBHOCCXieySDf9xNJNDCiUphvx0n0OumsasOTb8tPhYHYtsSRGnlmxyFL+xL6PG58sXkWB/DYcACgJUkoCVLFoM6Y3K3XTD9UsQW21muOwnudIL33rcqkwSC2jL2MmXRcoVVypC2jKInsggd12RfjYI16rTF8pqoboMHZNe9kuB4+87ao+WBCIrETZrkduChJ9sYPdBJMDE9ybS9+Mc0WQ1ZwHhfnW3HgcKgh0hxjniB/c4/oFXH7kTateF0eiK51BtVsue1mQzC0wAsqJXFinw8TlRF3tSFXYVQIA5bX3P06cuhwQ6+r413jBSqsxrHq0lLfLeMT9dEY2lJGwGFxGU/D87TWq09gfhAyoN0k7WmR9kNPqB5v0Z0tHiyv5dJavuO+C8XjLQRq9tG1jBS7iO9DHdhbgY3rHoHFie9OTL2eLiDk/Rd6j+nTMumwrdgkpDD9r26Ldpq7anZNu2KOuBeWES8F5ZJGDMSuZiWahEGZoP+ueEAhCCspmtGoLz3ZSyPLQFi83Gq6fJj3xhcyofsbrxtBNmAggkGJvi2sfhbx+HIjxJj7cPJaFGU9Mi2bfpU+PxjofoDwhzPP4qEi7prksDVuMEesV6DQLrP7X2xR/cyzV0xvoRdp+pzYu0AiBojkZMXulZdx225V8rrjJFsixWUJug1QPmapsXurxAfW/PBvVIHs37vCw3n0edIsrm4nvoN/3chlxdRfTAUqgVTmh/9yUsMtygO1k7hnaAlppt10joFWqk0nGBaz5kdBFvrgBl+3ZPpR2qvs6Md8nvULSbcXPlnZTZgbcCcVVHuPeqkGhIrqlRKKn+Peh8r3YFVCty5urVQ49om3HRiW++oPwu75iofHODJAAsDuWR8JQoqeyf3a5f0JUjWsiHoc+tWXgHvcT/TO8giccmlsFgqRvdnzh9wKZAstojEqUj4Q2LPdwytL/gxixlwMiWjREMcFDNI 1C4thJ0A TgUlIPlaDpZc8vWbY7syz0O49aAJc90wNYhIhWp9nanndfJiNxLbVGqFN3JrJUZwGC4lRshlmWdu7jEUzl79KF7CTt0sUflTJm5UZpFch3KpLtXMlyIyK/58eUETMNhEJamHZF+0GR1Q2q6Ub65E42wrhpDzvp4bCtDeaVM90C4a0n8+KuZFRhoFFzKTZfw/PW91RNDmYF/Fh9VTcxtrh5XIKczzUi/zaoDvBlapl6R+PX7uVVptlU4ruhjYJFD71vS9zpjqEJjRlMNoOoANqHC86qpkosREIjrgTKiN+Oa8zzqkZrqLcUtbfW0JbjjibknzVJy+p3wk5dfWEf0Hk95/PjupodP1KPLQvEZYco2aslMxDSFX25rznsWm0ODuGV988w1PqTrFh+HxWAMlpA06YmV/MC5gb+Tf/AfFn/ejZlDqZi5kRvTRpEUhoIR83yO5yOGruqTTqJgzLSzdF/pHuS610mQOKnQR7aFXOhRuXVuRCncOilL50gz1A8TB2F7Mhq2zCMDibBF3uOoTkb4qFVxWW347tma3m4P25nLUTNTbkKgRROTosDI7Uab0b7XCZP3wSV4NLE/CCbuV8nYh8L8nQtdq0i9haPItzys7n5YkdrpaN1Vl6cZbl5utYRRgaXyYHYUklIi2LHi+w8N9RGmyORR8vzfE9MwWY5gfnMsd7G70g2QBdoxjEBBltPbzXSOO+JENux736P51s1l3EpS2cyl6Ofqrc3FYkTPc85Rl5UQN9YovSQ0/7XscVVrRFi2ze3z6WqmVApjWZ80MJeg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Apr 03, 2024 at 04:34:48PM -0700, Deepak Gupta wrote: > Sending out v3 for cpu assisted riscv user mode control flow integrity. > > v2 [9] was sent a week ago for this riscv usermode control flow integrity > enabling. RFC patchset was (v1) early this year (January) [7]. > > changes in v3 > -------------- > envcfg: > logic to pick up base envcfg had a bug where `ENVCFG_CBZE` could have been > picked on per task basis, even though CPU didn't implement it. Fixed in > this series. > > dt-bindings: > As suggested, split into separate commit. fixed the messaging that spec is > in public review > > arch_is_shadow_stack change: > arch_is_shadow_stack changed to vma_is_shadow_stack > > hwprobe: > zicfiss / zicfilp if present will get enumerated in hwprobe > > selftests: > As suggested, added object and binary filenames to .gitignore > Selftest binary anyways need to be compiled with cfi enabled compiler which > will make sure that landing pad and shadow stack are enabled. Thus removed > separate enable/disable tests. Cleaned up tests a bit. > > changes in v2 > --------------- > As part of testing effort, compiled a rootfs with shadow stack and landing > pad enabled (libraries and binaries) and booted to shell. As part of long > running tests, I have been able to run some spec 2006 benchmarks [8] (here > link is provided only for list of benchmarks that were tested for long > running tests, excel sheet provided here actually is for some static stats > like code size growth on spec binaries). Thus converting from RFC to > regular patchset. > > Securing control-flow integrity for usermode requires following > > - Securing forward control flow : All callsites must reach > reach a target that they actually intend to reach. > > - Securing backward control flow : All function returns must > return to location where they were called from. > > This patch series use riscv cpu extension `zicfilp` [2] to secure forward > control flow and `zicfiss` [2] to secure backward control flow. `zicfilp` > enforces that all indirect calls or jmps must land on a landing pad instr > and label embedded in landing pad instr must match a value programmed in > `x7` register (at callsite via compiler). `zicfiss` introduces shadow stack > which can only be writeable via shadow stack instructions (sspush and > ssamoswap) and thus can't be tampered with via inadvertent stores. More > details about extension can be read from [2] and there are details in > documentation as well (in this patch series). > > Using config `CONFIG_RISCV_USER_CFI`, kernel support for riscv control flow > integrity for user mode programs can be compiled in the kernel. > > Enabling of control flow integrity for user programs is left to user runtime > (specifically expected from dynamic loader). There has been a lot of earlier > discussion on the enabling topic around x86 shadow stack enabling [3, 4, 5] and > overall consensus had been to let dynamic loader (or usermode) to decide for > enabling the feature. > > This patch series introduces arch agnostic `prctls` to enable shadow stack > and indirect branch tracking. And implements them on riscv. arm64 is expected > to implement shadow stack part of these arch agnostic `prctls` [6] > > Changes since last time > *********************** > > Spec changes > ------------ > - Forward cfi spec has become much simpler. `lpad` instruction is pseudo for > `auipc rd, <20bit_imm>`. `lpad` checks x7 against 20bit embedded in instr. > Thus label width is 20bit. > > - Shadow stack management instructions are reduced to > sspush - to push x1/x5 on shadow stack > sspopchk - pops from shadow stack and comapres with x1/x5. > ssamoswap - atomically swap value on shadow stack. > rdssp - reads current shadow stack pointer > > - Shadow stack accesses on readonly memory always raise AMO/store page fault. > `sspopchk` is load but if underlying page is readonly, it'll raise a store > page fault. It simplifies hardware and kernel for COW handling for shadow > stack pages. > > - riscv defines a new exception type `software check exception` and control flow > violations raise software check exception. > > - enabling controls for shadow stack and landing are in xenvcfg CSR and controls > lower privilege mode enabling. As an example senvcfg controls enabling for U and > menvcfg controls enabling for S mode. > > core mm shadow stack enabling > ----------------------------- > Shadow stack for x86 usermode are now in mainline and thus this patch > series builds on top of that for arch-agnostic mm related changes. Big > thanks and shout out to Rick Edgecombe for that. > > selftests > --------- > Created some minimal selftests to test the patch series. > > > [1] - https://lore.kernel.org/lkml/20230213045351.3945824-1-debug@rivosinc.com/ > [2] - https://github.com/riscv/riscv-cfi > [3] - https://lore.kernel.org/lkml/ZWHcBq0bJ+15eeKs@finisterre.sirena.org.uk/T/#mb121cd8b33d564e64234595a0ec52211479cf474 > [4] - https://lore.kernel.org/all/20220130211838.8382-1-rick.p.edgecombe@intel.com/ > [5] - https://lore.kernel.org/lkml/CAHk-=wgP5mk3poVeejw16Asbid0ghDt4okHnWaWKLBkRhQntRA@mail.gmail.com/ > [6] - https://lore.kernel.org/linux-mm/20231122-arm64-gcs-v7-2-201c483bd775@kernel.org/ > [7] - https://lore.kernel.org/lkml/20240125062739.1339782-1-debug@rivosinc.com/ > [8] - https://docs.google.com/spreadsheets/d/1_cHGH4ctNVvFRiS7hW9dEGKtXLAJ3aX4Z_iTSa3Tw2U/edit#gid=0 > [9] - https://lore.kernel.org/lkml/20240329044459.3990638-1-debug@rivosinc.com/ > This is a note for people wanting to test this series. 1. Need a toolchain that has CFI support $ git clone git@github.com:sifive/riscv-gnu-toolchain.git -b cfi-dev $ riscv-gnu-toolchain/configure --prefix= --with-arch=rv64gc_zicfilp_zicfiss --enable-linux --disable-gdb --with-extra-multilib-test="rv64gc_zicfilp_zicfiss-lp64d:-static" $ make -j$(nproc) 2. QEMU $ git clone git@github.com:deepak0414/qemu.git -b zicfilp_zicfiss_mar24_spec_v8.1.1 $ cd qemu $ mkdir build $ cd build $ ../configure --target-list=riscv64-softmmu $ make -j$(nproc) 3. OpenSBI $ git clone git@github.com:deepak0414/opensbi.git -b cfi_spec_split_opensbi $ make CROSS_COMPILE= -j$(nproc) PLATFORM=generic 4. Linux Running defconfig is fine. CFI is enabled by default if the toolchain supports it. $ make ARCH=riscv CROSS_COMPILE=/build/bin/riscv64-unknown-linux-gnu- -j$(nproc) defconfig $ make ARCH=riscv CROSS_COMPILE=/build/bin/riscv64-unknown-linux-gnu- -j$(nproc) 5. Running Modify your qemu command to have: -bios /build/platform/generic/firmware/fw_dynamic.bin -cpu rv64,zicfilp=true,zicfiss=true - Charlie