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 9EC2DC54EAA for ; Fri, 27 Jan 2023 16:12:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 216A56B0072; Fri, 27 Jan 2023 11:12:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C6F36B0073; Fri, 27 Jan 2023 11:12:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08EA56B0074; Fri, 27 Jan 2023 11:12:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EC67A6B0072 for ; Fri, 27 Jan 2023 11:12:37 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B67F080C16 for ; Fri, 27 Jan 2023 16:12:37 +0000 (UTC) X-FDA: 80401071954.11.E8CBD01 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf26.hostedemail.com (Postfix) with ESMTP id 88ADD14000D for ; Fri, 27 Jan 2023 16:12:34 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HV0oZ7BQ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf26.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674835954; 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=SwogfK/xLNDHbbwXO1sIym9vY9/jCFhsud5wbKcvQaU=; b=x3IE6VVZ2VsE2fnWGbBMC83ihEnu+dypRm6lFT1+pOX61yrOiebSPuDOv/v9LVVWRCVwNs AkEvb7b0LixPY8R6Aos/1hsvE/gXROCojZvHhel2XfH1nGHcSl4AE4Z2Qfkk1Vhe3OPl1P 8zCk2fFhBlz2C7hHn9a432G/tc0Hx3s= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HV0oZ7BQ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf26.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674835954; a=rsa-sha256; cv=none; b=3ydwLj8WrbVorXMl2F6uxd7Ul7NVadfglPSi1KUlD6v2qqQOh6aPbwVr/tZImSkxYe4J2i /ohBY1MYYFX1JvL8w9lLvio5x522kI2SxYn9iYpsCnpqvKwN+KGXrkyh9sofKhZsD+NLRO mDLclHukUsIOTjz/oMcERj4BDbucsWM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674835953; h=from:from: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; bh=SwogfK/xLNDHbbwXO1sIym9vY9/jCFhsud5wbKcvQaU=; b=HV0oZ7BQ3yma5vCmmGenaJOU9xzUAkm0nPm3pzn6AC5M6JiJXHFV/t4ZxK8MKrX9ZynE8I qmad3x2NhKWJnVxtAuldQXgJRzioDAIaSC7TuVnwZmfbMH5LryTFSTfgcEi39xslr3l9Ww cOLq7w0jq7fARJ3C3M+9KMco+0Xr/Hk= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-327-xfGEBTb_MoWXQlQvvzFFaA-1; Fri, 27 Jan 2023 11:12:30 -0500 X-MC-Unique: xfGEBTb_MoWXQlQvvzFFaA-1 Received: by mail-wm1-f71.google.com with SMTP id ay38-20020a05600c1e2600b003da7c41fafcso4902549wmb.7 for ; Fri, 27 Jan 2023 08:12:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SwogfK/xLNDHbbwXO1sIym9vY9/jCFhsud5wbKcvQaU=; b=M7/5g9KngCxjasHTOA95gsQ6grl+c1TVEUTpfzogiUagTP4SHGpgNbuXl8+mMF9JbJ cJV/A7oI19SUJwBkSEgHWBUNt7Yd8BjkU+Z+x9UBR8AxUvTBdOiLgtsEKb6kclPqxrCZ 0WCB1YpzIlR7n5BIAOvSrn7z/oqJE7VlU9U4DM5l+St+rXz2Mp8VQRjHq55hZhC2lLQs ggKyxVJeBX/aJuTb56pONjKW2rrGF9tQ4Pbov1rGiocqPCVVx+xsP0OJ3kBmXgGGDBEH xuwpR1QauH+ti/iunKJnZ1lKqLyLThzoeJ4c7RcU6gtuq+G5bTOFlnRwR4F5Ecp6ro2X AK4g== X-Gm-Message-State: AO0yUKWWLgBbGSRX+tJAAUXYRIsjIJUvI1SEvQeGqiV8trE5Qcthh5iS XJdp5kWWy1n7G2yEj20iXhe8QhKuHLEobZVbQBK9sdKO76//bmcaGbrnQni85oAMs3vjUIJHnyz eQlbIAOHyiqE= X-Received: by 2002:a05:6000:1f05:b0:2bf:bc38:17c1 with SMTP id bv5-20020a0560001f0500b002bfbc3817c1mr9332024wrb.4.1674835949252; Fri, 27 Jan 2023 08:12:29 -0800 (PST) X-Google-Smtp-Source: AK7set9xHxRFMELkql7GhWmWFY9SeZNG8Y1DmSr6SFxhFl3Z+1haelg4X8dDIm2uqRediNz9/rRjDw== X-Received: by 2002:a05:6000:1f05:b0:2bf:bc38:17c1 with SMTP id bv5-20020a0560001f0500b002bfbc3817c1mr9331981wrb.4.1674835948989; Fri, 27 Jan 2023 08:12:28 -0800 (PST) Received: from ?IPV6:2003:d8:2f16:1800:a9b4:1776:c5d9:1d9a? (p200300d82f161800a9b41776c5d91d9a.dip0.t-ipconnect.de. [2003:d8:2f16:1800:a9b4:1776:c5d9:1d9a]) by smtp.gmail.com with ESMTPSA id e21-20020a5d5955000000b002b57bae7174sm4283915wri.5.2023.01.27.08.12.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Jan 2023 08:12:28 -0800 (PST) Message-ID: Date: Fri, 27 Jan 2023 17:12:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH v5 18/39] mm: Handle faultless write upgrades for shstk To: "Edgecombe, Rick P" , "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "pavel@ucw.cz" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "akpm@linux-foundation.org" , "Lutomirski, Andy" , "bp@alien8.de" , "jamorris@linux.microsoft.com" , "Yang, Weijiang" , "Schimpe, Christina" , "mike.kravetz@oracle.com" , "arnd@arndb.de" , "linux-doc@vger.kernel.org" , "x86@kernel.org" , "tglx@linutronix.de" , "andrew.cooper3@citrix.com" , "john.allen@amd.com" , "rppt@kernel.org" , "mingo@redhat.com" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" Cc: "Yu, Yu-cheng" References: <20230119212317.8324-1-rick.p.edgecombe@intel.com> <20230119212317.8324-19-rick.p.edgecombe@intel.com> <7f63d13d-7940-afb6-8b25-26fdf3804e00@redhat.com> <50cf64932507ba60639eca28692e7df285bcc0a7.camel@intel.com> <1327c608-1473-af4f-d962-c24f04f3952c@redhat.com> <8c3820ae1448de4baffe7c476b4b5d9ba0a309ff.camel@intel.com> <4d224020-f26f-60a4-c7ab-721a024c7a6d@redhat.com> <899d8f3baaf45b896cf335dec2143cd0969a2d8a.camel@intel.com> <27b141c06c37da78afca7214ec7efeaf730162d9.camel@intel.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <27b141c06c37da78afca7214ec7efeaf730162d9.camel@intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 88ADD14000D X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: awfkunofg16njn3jffyfxoac85nwswuo X-HE-Tag: 1674835954-97067 X-HE-Meta: U2FsdGVkX19wqLvKYL3vUPq9t8+sxgXmeiiDI5JpMU1NTg2OLH/6IpOYmI7xXWdTTHAIGfdW9+Sdy1wX88z8l86su7fLfzsChznHNx8NMoewo3w9Z3iHoLcB4tf0+L2a5uxe2th8ZC3NiZ0YbkJw8a9Znza/ZVx5KAFK5CHvt+qOZKyd0eCsqu090k5S5lQALaJlBVOnydie+fEhjGjbwBCzEV1JoUez9g+2AXFuLzG0RCnrl+FUBbnpLX8tjlzaWOknnopmMrnlk14/hF0xRoLFLunuCwxwohCdVOwn9NQCXOdxVr1G+sKIDRT4o8ex/jx0VxqfVOMtJ97RB4rsIZl4m6qjZb0drm4Wa7sLWuVSu4eKCmIDs+VXOJ4qAm5OCxatvUxKA6kISOzVh5OccICkCBNSgG6ZGTa/fmS2wnW7eh7Ny2BftS4SAZknNYybbAorvK51CV+Dxw/sX4wECRacRddgrP7HrGhy2wVim5IvgOPvPKgvLu+Jm8ThiPg1weJsou4Ek77PJSxw64sxyum/3TSWMfUXpOE21HP/1tS1umsJWbx/xtDp6EqKvwCnQwDvjd7NesHgckKwRdylRSUeXNnvLG6JmnGhZ7OK37Xw9+dmHOxkaVbRoaPz6xGSBuUa+8Cz8JmPG+y9/p0tRocQK+lDXU8dfr2IYpxB7qA+pw1gPxceL1xkKUbjZNRYKeITqUWFIZGVqk0QPKtqG2aqRXudwfEVwVatQIRRxn/eSEOQYOauIC1PyvNMzbeguJN+rZS3DQdZ5OC8/WIcI9E0XYmTaEB0a4hRfbgAEUy8S2WXfNgKZT7yZJP22LVFdXOIiNn2qvvpSPN76fWkLoXcYsOA3FR0zIjU7ouydq5S43Ju86iySIlMfg7Ji2AcuqCAseRhQct9TSuwMBxLKJvDGOu3tTluhZ7ZXWJGBkYpm7JPbAplS3M5u8bX1uOfxI1Oo1F6akgeLInHpGt G+GLQKhW 2it76sBdC7LzLYdljdv6YkICiruYScjzK91ArzOR+VoYmgMZOD4m7F7DzFm9eNYyHfCYoavkX7xXQcoSilqjpufeDgF9zCt7VG1KD8hxFc0dxSTsCAW7FrQ7PPtXR3c2hL7hfIfCvNSBUHmaSeOUmmUcmT63yHxi/hJ5tVn34rETX3EoN74ko7tleA5QFTQz71s0rgsK9otAq6dMx6XZG0of2j6Pz0yfCF7qq8iEKBJP/WEyZNIAaWDlIvdKAst3dkNpjbDA7oohOG7L7hb6+RD57XpiQOach+4WKT7z5fZTA/SeBD5+CzrBYzsdvLEyCC0giJ60RXEJgWXTvCrvG+nII5suQFa+0bsC9CSTCSOW7ikpJnH1wPIbj/WQ1DcqW/Y8/XbmGRSZ3TmledaGMExzcgQ7gwltEqLopcRNQaiBzlJolE7Y595RyE68Q4CsZ+Zw63eopTanAUjdX31xtrHTIsrL/mE/pAxEJhE60h2YTMh4VBndItOJT5P2KQOaKmzRv 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: On 26.01.23 21:19, Edgecombe, Rick P wrote: > On Thu, 2023-01-26 at 09:46 +0100, David Hildenbrand wrote: >> On 26.01.23 01:59, Edgecombe, Rick P wrote: >>> On Wed, 2023-01-25 at 10:43 -0800, Rick Edgecombe wrote: >>>> Thanks for your comments and ideas here, I'll give the: >>>> pte_t pte_mkwrite(struct vm_area_struct *vma, pte_t pte) >>>> ...solution a try. >>> >>> Well, it turns out there are some pte_mkwrite() callers in other >>> arch's >>> that operate on kernel memory and don't have a VMA. So it needed a >>> new >> >> Why not pass in NULL as VMA then and document the semantics? The >> less >> similarly named but slightly different functions, the better :) > > Hmm. The x86 and generic versions should probably have the same > semantics, so then if you pass a NULL, it would do a regular > pte_mkwrite() I guess? > > I see another benefit of requiring the vma argument, such that raw > pte_mkwrite()s are less likely to appear in core MM code. But I think > the NULL is awkward because it's not obvious, to me at least, what the > implications of that should be. > > So it will be confusing to read in the NULL cases for the other archs. > We also have some warnings to catch miss cases in the PTE tear down > code, so the scenario of new code accidentally marking shadow stack > PTEs as writable is not totally unchecked. > > The three functions that do slightly different things are: > > pte_mkwrite(): > Makes a PTE conventionally writable, only takes a PTE. Very clear that > it is a low level helper and what it does. > > maybe_mkwrite(): > Might make a PTE writable if the VMA allows it. > > pte_mkwrite_vma(): > Makes a PTE writable in a specific way depending on the VMA > > I wonder if the name pte_mkwrite_vma() is maybe just not clear enough. > It takes a VMA, yes, but what does it do with it? > > What if it was called pte_mkwrite_type() instead? Some arch's have > additional types of writable memory and this function creates them. Of > course they also have the normal type of writable memory, and > pte_mkwrite() creates that like usual. Doesn't it seem more readable? The issue is, the more variants we provide the easier it is to make mistakes and introduce new buggy code. It's tempting to simply use pte_mkwrite() and call it a day, where people actually should use pte_mkwrite_vma(). Then, they at least have to investigate what to do about the second VMA parameter. -- Thanks, David / dhildenb