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 81FFEC25B10 for ; Mon, 13 May 2024 17:32:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 055426B012D; Mon, 13 May 2024 13:32:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 006236B0130; Mon, 13 May 2024 13:32:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D99D06B012E; Mon, 13 May 2024 13:32:43 -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 BCE226B02B5 for ; Mon, 13 May 2024 13:32:43 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4AE7C16056A for ; Mon, 13 May 2024 17:32:43 +0000 (UTC) X-FDA: 82114067406.04.CC4FBB0 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf21.hostedemail.com (Postfix) with ESMTP id 5E2391C0006 for ; Mon, 13 May 2024 17:32:41 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=lH7PnQlB; spf=pass (imf21.hostedemail.com: domain of debug@rivosinc.com designates 209.85.216.49 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715621561; 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=kFXpqZ06tDuL/9cR0jtY4Xzt7LWkOIEFJ/Br1ZOH9fM=; b=sDx7wVHWpUD/n5eVtjU7oKOeLJdMygorfQAosza5pIiXSM50hSLQ/WgykaZvEdE14XpJWO cmeyIv1wiCroMHU62pR6PcnKnMOKpVrWlOULIwUw5Gzsg72b66tfBDxKOyicgztLfSH5Bi ZDjAZdqwItGmpuBZA8kp3kQGcyVgrE8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=lH7PnQlB; spf=pass (imf21.hostedemail.com: domain of debug@rivosinc.com designates 209.85.216.49 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715621561; a=rsa-sha256; cv=none; b=bbtmi4Vzt2Db/3puAqE5qR1lhNbKLRbdUvqMF7j0iUIdzcUmLgLRk8mOfR6yaV8fNIAEsT fJEg6pTK5nK0Cw42qxv87ZFpijObM3kLCyGr7idnuuhnePHwCwplskB4MwfvOof02RxmdU y2F3e7NfjRKPKj9HkGPziTt59AUyPzA= Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-2b6208c88dcso3651509a91.3 for ; Mon, 13 May 2024 10:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1715621560; x=1716226360; 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=kFXpqZ06tDuL/9cR0jtY4Xzt7LWkOIEFJ/Br1ZOH9fM=; b=lH7PnQlB1kUzTUz1yw/FHoFPwCE4JOYstkCgYqSf2XEfR0FM60lFEEtzhtu5tS7Hwo x/qPTrwHtHdyt3IXhlHwCCmRp027zMsjnowD8fpjHlHrxX4voHBw9rbc6ft4DQTderMY /n4vDMpHcdJrp9shn88pfrNDQzLLBLmKtpFvjx8e4e2bD+6zG/ywDRVaVGDfIc7hNyNN yw/GEzERICjTIWwXAYhahr+EUJ6YCA2qXHWDxV6fBir+YRem7d7PJA2S3XTevZEVeCOF 0bGVeYnnuLvl6F1ZTUHInuRI7ZHXWs6FF0SctJ4kfBt2ZGG2Mhoaf5cWYhn3Y5OcktC4 v9HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715621560; x=1716226360; 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=kFXpqZ06tDuL/9cR0jtY4Xzt7LWkOIEFJ/Br1ZOH9fM=; b=DnsTH7EMtuQj1tEm6idpWvMDN7vfkv2o5hBb+V8NOIc0v5+ghtNzn/r/AT557Aje8n pW9oTOrEOkHuvCEfWeC/1FvUAaDZDVq1gW/MHhPGpxhEV28/+U/s2W7ErSAw0rNX2Eby mnOLgF6Wjbnbm3alAhe+D7IMR3VeQoXByzdl2iIWYzu5Ucz74CTY/eAfT47f3P+KSKVi N7V5Aq+B0Sz7xOiucmw6gBBryJfDhYeWbCpS/rR60GGcLvDkp5e7iZixU1O1Ccn/Jiai NIs6AaF5uc/MBqfUq6PSj9gFMjaTZfbzJNeBZeIrNwUR5C14WGDCcrgGWreHY/XANnc/ ahSw== X-Forwarded-Encrypted: i=1; AJvYcCUpDONb0Zr0W0G4h99hPdOzkqPOdEiGuZn7cjdkUZl6/VgkxaecujLwkyr1jwlDWeCqPqk0+pDNO/WjSxYtLUW7Y6w= X-Gm-Message-State: AOJu0YxihnREsQgx1+1dRoN4g3mBu9eP48EFc4LMXhYlad08KO0b+OCU jDTGlPL97p0hb/YlbD9IbMAcSfWUjetRvVq+pdbfBQsoAyF5Zcs6MG6+5MH0HSg= X-Google-Smtp-Source: AGHT+IHKmfimNpAoB9AkagGSZYSsR4bthh7r8LX1Nfh54P1zDj04Ez6BdQHy8JDipeCpvu8vEpu4Yw== X-Received: by 2002:a17:90b:46c3:b0:2a4:b831:5017 with SMTP id 98e67ed59e1d1-2b6ccef66cemr8063931a91.48.1715621560155; Mon, 13 May 2024 10:32:40 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2b628ca51e0sm10048832a91.35.2024.05.13.10.32.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 May 2024 10:32:39 -0700 (PDT) Date: Mon, 13 May 2024 10:32:35 -0700 From: Deepak Gupta To: Alexandre Ghiti 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, 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, 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: Re: [PATCH v3 13/29] riscv mmu: write protect and shadow stack Message-ID: References: <20240403234054.2020347-1-debug@rivosinc.com> <20240403234054.2020347-14-debug@rivosinc.com> <276fa17b-cd62-433d-b0ec-fa98c65a46ca@ghiti.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <276fa17b-cd62-433d-b0ec-fa98c65a46ca@ghiti.fr> X-Stat-Signature: iaym1971j7kwub4bnc86khkri8pu98om X-Rspamd-Queue-Id: 5E2391C0006 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1715621561-135619 X-HE-Meta: U2FsdGVkX1/OCZVERjVxI3UB/l82v/SO9PMeEno7gRhpSkjbpMa7j9yrI/5dotpywELgrUZrRfG6B/TyfebFKfErdlpAqXV1CuxkqTQYx1XWnUvAaZp4zL3KPNfDoXxyfR74zHvEa1bGHYdWSkWDJpO6lMLZ8U/dnvnd1rnKow8H7hlmXWkALa1svBnfmKkWCwRgDEQcEo01LESdl+b6n8zys/NzvKe4yRSvQYBxRSJYn91udxuCsa8mJA4mC4/uxNFZEUayrEAfPORfYz4C/uQMMnlhbBVhs062Y219BA2uy32dwEL0Exrwzqkr1ZdjMPQ0rMgfiaNQha7VIVVTPPrjnNf1/yFtuyaBCHhGjERY0jpK10nfMjVd+lIW+K7Apr2UEtcMkbHG57/ElIV+xRoBJUIf6Z5OL22ZfoXXrumb7z3wKlFi1bNoPq4NBr9c7lIvGBz0DgV/R3wLaZQUaLFYypjG/tfGjDLa5QFwIMl86KadRzs7KDP1Kljcps88XTluiKmPrXy4ywTf+cBhyY1m6xmU2zefKVdA0+7wtFX+UH9PErDF+ix2xOjo1eJdA/W7e1qPC+YUD/b5B/19IgrP2dcp4TXWvdplMssdKnedY1PyV6/7d6QdViVNNZKVEqc1Ogp+HhcFA5ybuUqjYtXwZG1yq6yUFkm1Nf44Bfe45T2XXyYbvqlRKJf+jy/M97OE5WJiw7CZakoBggswTCWZknQtLEV8yV5/i+f1tkHPEWLgzt4kg0JRFek02/P9UPcWyZXJO5IUkQmcoIsJklCnK4FG0Ot+1p1MTkSUKa5YBTLzfonZWXv1XWPRnq1SrzUM5gA0vJmCNDNhaDGEPD0/+uf2rbr5T5eGaK7Kwk1xcLoz+dSqIirYM9wgKZmmKY/SXz+qI7C19g0uth6Wmt0aj7Ti8nzW8g68wVGLFmcsThKJkqED1ezSn7rZed++4Eh8Mhg0EKyfbSeytIr uq8MVKyU dcAtOtfjzVQKa9qIOjpkETH+beDV6WpFUtr0LQpVWVc+2HKnbZ11iyONxxuvkXSFnO1aInIiU9j8i+UNqPBr6PLX5+2eFfTbuCUBDm4xFlcVLS8fEkDL5K10HZA2XCDovh/bel//cqMTjNBK/riRIFt0PFvZQPNjL8CQ8zGWOWz/fFrYydErHCQYFCzJ9W6QWvZ9bK69uU8WRdkfHzvpQJLbQcQ6Tn2Y/hsdSIHMiG9HtzxVKr7fN3h44MVlTavJlurD5+0t4nMMUroHudpW4pum/eYcA95hsO7gYxIWbvX0DFq6Gh1y6/e4z6UUU7RQaFv/FIzj4Z8Dkkb8dkZtpT4N8DEhhw2ShpmbzMubSE5VX6DFB/azKAWCdDdjGNpsU+dvz0f9JhRn9p9Q8ElaZsGNQr2oIJIem8kBF1dPo2KpJQIrjCSEkm5U5hirBOmrq3ob8T38I4jdcbnU9AOwYIVLEvDZ1qnWSLhRWZb18pyWXolaRqa+K2Z2hjrXGf7MtxJ63An+G8h2lxiI26z0SBFLgZw== 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 Sun, May 12, 2024 at 06:31:24PM +0200, Alexandre Ghiti wrote: >On 04/04/2024 01:35, Deepak Gupta wrote: >>`fork` implements copy on write (COW) by making pages readonly in child >>and parent both. >> >>ptep_set_wrprotect and pte_wrprotect clears _PAGE_WRITE in PTE. >>Assumption is that page is readable and on fault copy on write happens. >> >>To implement COW on such pages, > > >I guess you mean "shadow stack pages" here. Yes I meant shadow stack pages. Will fix the message. > > >> clearing up W bit makes them XWR = 000. >>This will result in wrong PTE setting which says no perms but V=1 and PFN >>field pointing to final page. Instead desired behavior is to turn it into >>a readable page, take an access (load/store) fault on sspush/sspop >>(shadow stack) and then perform COW on such pages. >>This way regular reads >>would still be allowed and not lead to COW maintaining current behavior >>of COW on non-shadow stack but writeable memory. >> >>On the other hand it doesn't interfere with existing COW for read-write >>memory. Assumption is always that _PAGE_READ must have been set and thus >>setting _PAGE_READ is harmless. >> >>Signed-off-by: Deepak Gupta >>--- >> arch/riscv/include/asm/pgtable.h | 12 ++++++++++-- >> 1 file changed, 10 insertions(+), 2 deletions(-) >> >>diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h >>index 9b837239d3e8..7a1c2a98d272 100644 >>--- a/arch/riscv/include/asm/pgtable.h >>+++ b/arch/riscv/include/asm/pgtable.h >>@@ -398,7 +398,7 @@ static inline int pte_special(pte_t pte) >> static inline pte_t pte_wrprotect(pte_t pte) >> { >>- return __pte(pte_val(pte) & ~(_PAGE_WRITE)); >>+ return __pte((pte_val(pte) & ~(_PAGE_WRITE)) | (_PAGE_READ)); >> } >> /* static inline pte_t pte_mkread(pte_t pte) */ >>@@ -581,7 +581,15 @@ static inline pte_t ptep_get_and_clear(struct mm_struct *mm, >> static inline void ptep_set_wrprotect(struct mm_struct *mm, >> unsigned long address, pte_t *ptep) >> { >>- atomic_long_and(~(unsigned long)_PAGE_WRITE, (atomic_long_t *)ptep); >>+ volatile pte_t read_pte = *ptep; >>+ /* >>+ * ptep_set_wrprotect can be called for shadow stack ranges too. >>+ * shadow stack memory is XWR = 010 and thus clearing _PAGE_WRITE will lead to >>+ * encoding 000b which is wrong encoding with V = 1. This should lead to page fault >>+ * but we dont want this wrong configuration to be set in page tables. >>+ */ >>+ atomic_long_set((atomic_long_t *)ptep, >>+ ((pte_val(read_pte) & ~(unsigned long)_PAGE_WRITE) | _PAGE_READ)); >> } >> #define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH > > >Doesn't making the shadow stack page readable allow "normal" loads to >access the page? If it does, isn't that an issue (security-wise)? When shadow stack permissions are there (i.e. R=0, W=1, X=0), then also shadow stack is readable through "normal" loads. So nothing changes when it converts into a readonly page from page permissions perspective. Security-wise it's not a concern because from threat modeling perspective, if attacker had read-write primitives (via some bug in program) available to read and write address space of process/task; then they would have availiblity of return addresses on normal stack. It's the write primitive that is concerning and to be protected against. And that's why shadow stack is not writeable using "normal" stores. >