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 4990DC25B74 for ; Fri, 24 May 2024 07:16:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A8B186B007B; Fri, 24 May 2024 03:16:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3C056B008A; Fri, 24 May 2024 03:16:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 903F46B0092; Fri, 24 May 2024 03:16:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7455A6B007B for ; Fri, 24 May 2024 03:16:37 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9C191A1C8B for ; Fri, 24 May 2024 07:16:36 +0000 (UTC) X-FDA: 82152431592.18.6342289 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf05.hostedemail.com (Postfix) with ESMTP id 86BC6100013 for ; Fri, 24 May 2024 07:16:33 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=iiVGz1Pm; dmarc=none; spf=pass (imf05.hostedemail.com: domain of debug@rivosinc.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=debug@rivosinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716534993; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=G5b7QgiVlAzfw1l+FA1jhqowDIFfn6XCF4+Yt8iGQO0=; b=DmHHOGIZ6IeoO+2bLc6yt5Jpk2OtHMRj/bgmgY1hYMS2fFL8kDCQwtPKDQ7pK8BdnrQfWJ luWH76zvNGoqptLHW3hg9lCRoGE2yH3pgCZMVLQ+UKMvYpSB5bEXFnUe6ZNgDgTwvHEBTG SVYY5pHGHm9HyL/flBgBUD7GmClsQWQ= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=iiVGz1Pm; dmarc=none; spf=pass (imf05.hostedemail.com: domain of debug@rivosinc.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=debug@rivosinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716534993; a=rsa-sha256; cv=none; b=ZDcbi4/MRd0h5MykPBq3YlG4e58+7Y854OjsOT/KPoxJRIJR3XaLIw1y5bJ0/aOqKzMhzw 7X4jq8UunzklWpmF3sOyUzLrWC2Y9wAaThmySH0zM3MvccgrCEbsr2iq+CCOuxhy+zNUca hszWv9L8B9a8i6O+HwhUYNr8ddHMjUQ= Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-68195b58daeso469217a12.2 for ; Fri, 24 May 2024 00:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1716534992; x=1717139792; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=G5b7QgiVlAzfw1l+FA1jhqowDIFfn6XCF4+Yt8iGQO0=; b=iiVGz1PmwKT7VSPvZhOwj/Lc+vtz9ZKD5oMjmXPoMVTG2dqJK9E1r3OPDHDdZbkiQ1 bB+utQot68gB4e4OHNw5wIQN9QKSMiN8VnbU/7SKzkfLp6lpgpNL0sf12DfRSYEpIP0H cMH7pNVX5VRStZAholdR2JmdEJIen5ntkt0XInmWwVpV6AoPJFrXBbtQ4Q8A+TSPOBFW APlHMTG+eLOpJNgF8XFq0V5HDMMxaS77qNi9XcxOha1DGgO4pvi1jdQK250M42rUvi2D AoZb/bfEVMhIy//POAKICIQJcXOs1HhF7+N9Y+5zvz0NsU66kofZ19TVbNX2kRqW1B+C EGpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716534992; x=1717139792; h=in-reply-to:content-transfer-encoding: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=G5b7QgiVlAzfw1l+FA1jhqowDIFfn6XCF4+Yt8iGQO0=; b=ghqldwKE4E7g8Pw7vRC6rSuxl+auy9wEMbW5fMsXUiwE0zl0UrEiIlzKxNBb6gW+WE bZ7ir5Eof7LI7JlOcZhDTCCx2lsOU/Qv3w00Ta1VB5JuKKAEseWME9nFexxc/yfiaQ5S flla2GAlxePYqvF5azo5O6LNBGHMA3Xy6RR/Lt6hduObgevZKo4fmdDwSkTfrInnyzme todN5U+nSydjkUkFSiVrBApK240YWSHnyMcH3C62rtKIf3K8SXSEzv+IQiX8yFg6Owy9 7QK475muUmo2gYN7HDmFooowNqyYgB0Fwepr3TUPI2Qa83eKMcXke2StfSoVnCYBBebj GDdQ== X-Forwarded-Encrypted: i=1; AJvYcCWws3EYXJpc14nQNGTzw/r1C2FMt0VVknGgeVNTmn97rMWmzC4pxeGAyY0YFJzU8snqY6gJAwV+I373MVeJW+iCm8I= X-Gm-Message-State: AOJu0YwtdpcfgCxr1L6AbSoIJ9PYpKhfaifYVRzjQgVq8mgvywSQfo3a 5VnRp2Q/Ee3JI0SWWcF280AaauGvBgj9DfRjOYKTodjw+2Ux/7qDlIIYy/a7BDU= X-Google-Smtp-Source: AGHT+IEDTqTA76mWXJ68mdGF74fNSFi0v4c+GSsV/TK7Kq0h+0BnWlexLZoWy2cb8clnmvmHxGdpVw== X-Received: by 2002:a17:90a:ec12:b0:2bf:5992:31ae with SMTP id 98e67ed59e1d1-2bf5ee1cb71mr1385379a91.20.1716534992281; Fri, 24 May 2024 00:16:32 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2bf5f9b28dcsm742083a91.52.2024.05.24.00.16.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 May 2024 00:16:31 -0700 (PDT) Date: Fri, 24 May 2024 00:16:27 -0700 From: Deepak Gupta To: Alexandre Ghiti Cc: Alexandre Ghiti , 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, 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=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 86BC6100013 X-Stat-Signature: ad8hcetw41umtmgxqdqxo5sf3fatfqhz X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1716534993-504867 X-HE-Meta: U2FsdGVkX1+Ra9FMprirtU0noGINDHHkPyzx+LG/BRz7M8y1p+C6WkvwBGWsveuR6HjzBmeGOkUaGW8AYo0UW21ZdwOh2LAgr1amFpT5ZahW4fqtWp0cD2FjY7aBXjI+18SiX/559JGXG44haAFSFYqWlCf3eFXygD5J/h8lcU89WVWzfPM1+/539VrH/o+z2zYwBUS7QMB7Tft28Ka0koe0NS2nl/A1oZuvALYukdk8gLGlV2b5tyvirLb/sDJ+gUTkZTxS9qoXFgfJtacKq14cHIQyJSJDa7sMw4TVfTtMPNdct6iMvVFzHWNOBGhQTamcE/Zez9CFxIDemHuEq3ZWHAls/uLjLR/N/oVPfqht84Pd0D/UsOqlJ95ZhawJZa+vxu7CWUXSNjfhHiVvua1GKrGbgkdWXUaoMAt5QHZaVQlSDhwQsxl/9q6RWJVf3okP2/8Iov4GwhOnhJOtz95r96xpNlsTrtErOyuBicxUhQooBRL2J4ylBYjpgqnGkUmjzJVxDn3FWE8JmhxUtruPNRHz5zmnvbcJDZn3p2qTjIO+e9yF113g79017t0/mMpTRXTe3UMPP0RweuQrZZ5NW7k/VS5Zx8aCyZmW3u7vzZat20evnnyNchhWE4T0/R1SOURmRkO3W31WftByNxqWRa/seZuXy1a1nHhpC+HcBgrpKCLwuCLNiDmigtaW/36kb51eflqxjcv+7sjMcul2XkvJbIv//nzN8DfPM8o/R3/3gc9mLue1XEoSw9rMBgs5avWo6Blvq5Op/2cZuk1NEn1hRoa4rBgJCe2Rg0VdeYzWw42ODAEJqq/0I3DcLS3+CKPYFE/XKcC7QWzozCUmyLQiYtXvYBoUi4D9CFkMJTvqiNT2OEMRtV1A5f5rAk8GMg75SEjqjn1vKjFgV7fWPs0r+YvMRpqATqoFxLbrhmNWRj2TrvJ1GXQ4NEKlufZuHso1VS010PcNUcy mvAB5wQw eajv9oZo2/Zr07PgH6x2vI67auUErrAEfhqJa+2BXb9FoSkxouV2InoPVNuQi4YhPn0XEphHtRIlRhlyAA+qUrr7UQjuF1h4J0p+KH5rYAB5Rh+MnC666xT5iPBULt76RCxb/EBU4pgcJd1kfbSuw4+bm4+GCzhJcKeYn0Eq57WqJ1NuyIiHoN2JLZPHikqc5MqLz8cVWdm/45ISODOi5+HzniAF/TXjbIkUie87z4lvrjAwVhMWoE/b//1wfKhyip1SfKZeef7DdmwTcG3Y9l+8CfhyxjdDg/X6/N6Cv7FhdWa0BHCVmeKAyAqbZeP7XdKFtRwE35N7dk6JRCtA5bBKcvweQ/V3uOWHO96h67WHAgCol6idYzn/bLJ3DxYeZlOVy+9+CJhKEsgYodLzrRI9SvSi4VAbj9ruVvutxLYf3pmCHeAdglrr6Y5NPBt7PC06Egs2Ar/JNM0GoN3HyNXSFxVRsg/MC7jdU09HJZgPaYjHD+biQ80Z39IQbrCiIuVE5f/CLc1e3wKeUGYwggNq4Ophdyet6JroteSZx8o0xDAnCVIsUoRAjkw== 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 Thu, May 23, 2024 at 04:59:30PM +0200, Alexandre Ghiti wrote: >Hi Deepak, > >On Mon, May 13, 2024 at 7:32 PM Deepak Gupta wrote: >> >> 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; > >Sorry I missed this ^. You need to use ptep_get() to get the value of >a pte. Noted. will fix it. >And why do you need the volatile here? I don't remember the reason. It's probably not needed here. But I am sure I was debugging something and trying everything. And this probably slipped sanitization before sending patches. Will fix it. > >> >>+ /* >> >>+ * 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. >> >> > > >Thanks for the explanation! > >With the use of ptep_get(), you can add: > >Reviewed-by: Alexandre Ghiti > >Thanks, > >Alex