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 46F80C6379F for ; Tue, 21 Feb 2023 08:38:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E50D6B0075; Tue, 21 Feb 2023 03:38:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 86E1D6B0078; Tue, 21 Feb 2023 03:38:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C0096B007B; Tue, 21 Feb 2023 03:38:35 -0500 (EST) 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 554AC6B0075 for ; Tue, 21 Feb 2023 03:38:35 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2535FC107F for ; Tue, 21 Feb 2023 08:38:35 +0000 (UTC) X-FDA: 80490647790.30.A0219DB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf24.hostedemail.com (Postfix) with ESMTP id E7B16180009 for ; Tue, 21 Feb 2023 08:38:32 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Zss+aczP; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf24.hostedemail.com: domain of david@redhat.com designates 170.10.133.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=1676968713; 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=Ka8yKsNqGuV7c8XzxIyetsQ+yohDTXMzd54elUnsMIg=; b=1I89AzIm1C0DsEiaRRjXEAzXAz25hDlC29B/EwFPZGmscWzd9Pd4oM6iXzLcKiXpTmRzEg 8fU8dbRMOxsaI1JZx3TaFO5sJnsxsI8Q+K0NY3KwHJc7z8KwW/oJIHRPlVJYiNqs9xM00F RU8bh81D/FH4UDvceqUUysr3VFjQNIc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Zss+aczP; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf24.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676968713; a=rsa-sha256; cv=none; b=y/5+aOAW5nvlH0wuTbSzlHttb4/vjgehoXYFmqk09sw/B2bI2Od8SgSwdVJA4pTZIVwcf0 Z5N34Vwt2CKiHfExgmrt98X2Qe6TxPuYuSOjLqrEKhpTVmKD5z9R2jVQiYepyCgynqS8My JBffDpZ4a+lL0IjCcDOzznxXs2HbBhM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676968712; 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=Ka8yKsNqGuV7c8XzxIyetsQ+yohDTXMzd54elUnsMIg=; b=Zss+aczPyZ+QlgWEotnfDYjtA0pyOMfemEcuYlEEVLp8RwMzhwsH5ao5KfPVuuUhh/Gs+F MwdA/ztlVqcCjllhTDdL3h2Evg9z5r9tpiKbpHUBsMN0NmWZclROcLi2/BujhBXY4Q+7T/ vWY/PU9pcpQbaYST9j/uB0PLbNrB2h4= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-542-ZTV-kBE6OpKjcA3nHLtnmQ-1; Tue, 21 Feb 2023 03:38:31 -0500 X-MC-Unique: ZTV-kBE6OpKjcA3nHLtnmQ-1 Received: by mail-wm1-f69.google.com with SMTP id n15-20020a05600c500f00b003dd07ce79c8so1554358wmr.1 for ; Tue, 21 Feb 2023 00:38: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=Ka8yKsNqGuV7c8XzxIyetsQ+yohDTXMzd54elUnsMIg=; b=exln7zFrlEK2ZsJ6O20I1lRVf8f7K9BVXuxp8eg7QxySJwJ2pPN+ugGy01L1DsJqk8 5BPc30bc3mZ6pB7HcLn2Yga/fqnnbWpghjXzpqCh0utj4cLQkLVBUVKI3hW7ZiPpY2Py a+gPL6UxoOy56QMEHBo+HmdIKTgeRHCn5kSUt/AHVhd8PEY0c0ttiXT1t7cj6at/8dIe PZK51TlbdbAzR66chCzrVujSy4kv+1idhQUK4dkKmUCohd9CB5cusnpqp4aEC2DR2DzE oxynuhoEvHCzkN3k1P9/7kMp7T9tsC/L8qLBBebsuKxA4iFSJ9jOSR/LaicWn4tXkuMy oMYw== X-Gm-Message-State: AO0yUKWdIfmthSa/00pXQ3n9vzgLUA5PVKO87eGt0KMX7JaXcgn4afnt A2Dtw4kaJsRJBYVTdBSEU1EI6i+aMFbI55N3gUYd86QDotfV7vIj8Nu0zAiFqEtpB9zFVSjwxhn JiJScmjVdGQg= X-Received: by 2002:a05:6000:1141:b0:2c5:a19e:6d16 with SMTP id d1-20020a056000114100b002c5a19e6d16mr2106362wrx.61.1676968709916; Tue, 21 Feb 2023 00:38:29 -0800 (PST) X-Google-Smtp-Source: AK7set9xmVVeqlz0SJdIvYxvoGZ+QENG9hT6lVbWaYP3zkoQhjiyjPjHe9AF4f0plUey4v3xSojS0w== X-Received: by 2002:a05:6000:1141:b0:2c5:a19e:6d16 with SMTP id d1-20020a056000114100b002c5a19e6d16mr2106332wrx.61.1676968709569; Tue, 21 Feb 2023 00:38:29 -0800 (PST) Received: from ?IPV6:2003:cb:c707:4800:aecc:dadb:40a8:ce81? (p200300cbc7074800aeccdadb40a8ce81.dip0.t-ipconnect.de. [2003:cb:c707:4800:aecc:dadb:40a8:ce81]) by smtp.gmail.com with ESMTPSA id u3-20020adff883000000b002c703d59fa7sm1615085wrp.12.2023.02.21.00.38.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Feb 2023 00:38:28 -0800 (PST) Message-ID: <6e1201f5-da25-6040-8230-c84856221838@redhat.com> Date: Tue, 21 Feb 2023 09:38:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [PATCH v6 14/41] x86/mm: Introduce _PAGE_SAVED_DIRTY To: "Edgecombe, Rick P" , "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "dave.hansen@linux.intel.com" , "kirill.shutemov@linux.intel.com" , "Eranian, Stephane" , "linux-mm@kvack.org" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "linux-arch@vger.kernel.org" , "kcc@google.com" , "pavel@ucw.cz" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "bp@alien8.de" , "Lutomirski, Andy" , "linux-doc@vger.kernel.org" , "arnd@arndb.de" , "tglx@linutronix.de" , "Schimpe, Christina" , "x86@kernel.org" , "mike.kravetz@oracle.com" , "Yang, Weijiang" , "debug@rivosinc.com" , "jamorris@linux.microsoft.com" , "john.allen@amd.com" , "rppt@kernel.org" , "andrew.cooper3@citrix.com" , "mingo@redhat.com" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" , "akpm@linux-foundation.org" Cc: "Yu, Yu-cheng" References: <20230218211433.26859-1-rick.p.edgecombe@intel.com> <20230218211433.26859-15-rick.p.edgecombe@intel.com> <70681787-0d33-a9ed-7f2a-747be1490932@redhat.com> <6f19d7c7ad9f61fa8f6c9bd09d24524dbe17463f.camel@intel.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <6f19d7c7ad9f61fa8f6c9bd09d24524dbe17463f.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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E7B16180009 X-Stat-Signature: geaje7tm1afcscxnodrfedafaqi79jmt X-HE-Tag: 1676968712-24847 X-HE-Meta: U2FsdGVkX1+pq9CmxuFP4zcJkKMEVqCqPD5jdPSXzPJfvuCrTudV5FsQWSFv7o5KdKUNxpY2zD0zRKjfYiY5siJmae6m5ycfTkKUYZyMghBhROzY/mE5uqYkenKsO43OL7NgcNCES2xOjh5cQanLJhfq8ANEle6VFIqUOBee4NjH6YagLmY/m//OGEDsKKiv2h0btOJ8JvRnarcwL7n0CNicqZpdkbgGK0nPiz/8y3rVKVlaMsG3x/Bl4e4tUh4uvR0jOggGFN4xhg7UfdZunmBSf47EQ3ILFLiC3QfqvAFR1SCw4URmn2y10sbkapw2EDbo1EPm4ZnYTwp3Q//kNK50qjQstYXCRBAldbGLFW+1WarQdSbdfVyGKrfwFcaPNzSF40VCgVrJ0tRm8SyK+wU0sCOezN0cbLWEPvLQ58bNj9vrPtmFjdYK8sHxmRGn0l3c+rPYi2wagYxUjKoO3ZcVr6nB1PNIi9DjPmdoidaYBYfrWqyaKxyUDOWDcEtSkr3hMxJPFkuoaW0NRowC3X04NjRZn9z3tTwxgCg035G/IfFFQreFvTbHCXwsaQwm1HeImgm6hutPkneg6Z1T29A5ujVQQKKxLX8pKG/daRo0WeiFUbtYAUQkfuWnbmJkD0f68MVGmPm0wWVfzlysDs77ft+/Tw0F7fvS6nlTL/mQt66oKq3Cp1iAAtmEmQqZgpmr9Qjg0eMDj/+lo2vtd3c+hrwVaI7fwJK6DeNvT8YtIk7E8L8nu2IjGjmgIADLdfBFaXr8wp7/GxsKztF3ma/EbEOhJ8iN+4KGxAxxf1aa+B7az6PnA433FG0pMYcCNhnB/Gp2P32rMIvFyfCW2xSDt3b8T4gwDrv1KDFEOagFkBdzgkz52vvQ6eWJaNgMjEaXH4MbsUQqiJTby+IgJNk/IosGnEB4uoP0ODvaUbLIhg92/ACXrfbG39PJON6bRXfsI0FzmuAANB68ZEx V4ZHvhus J1pB54tv/1gVI4ZGZPdtIAvoNpFwRByEQRk04JjtOuuT+YpDh0+mqXv0ay5NoDFDHWvg5IZyR7/OXzF+UaKdgbq6lwIS0PJR11P0Cz10MVFOYteLRng1FHt/ZJERwQxjQ17p/nOMeirQWTOdaUmiM9+TPYFCkTqmIJkEqnMqQl+iXIjEnluvwt5VB7SE2mezOn9hqB3Pnhnjy0luy2Q6ZngcKm5v3dlX730wKBN3elohHv8qD1ARgFe+2u+PlhABpphZADBKs/0dTOVmCBRlzblRYXHoa1JF4hNiFsFThU6j22r3RAOhK3mRTmzBHO/vRtnoRR5eddCvX/4D+RkRS4a56Ctxr2c7nOeonik9CWxj7vY9iuByZSHFun5SY4I0lSNNWyqjZ3DZf7aFXuft4SH2CGDXxXLtOVFjvnZp/Re3cjTJVuMjt0RJ7aewDVwbONuCPiTIRErfOn+hojzVWmqddOuNYQtyoIbqkv00574PaszeLx389FurNF1a5anQkMEf5mcyik3W2cH09wQ4fbZbB5Chr7HvsWC0x/SF9BiNIbAOQCLwNW4AovA== 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 20.02.23 22:38, Edgecombe, Rick P wrote: > On Mon, 2023-02-20 at 12:32 +0100, David Hildenbrand wrote: >> On 18.02.23 22:14, Rick Edgecombe wrote: >>> Some OSes have a greater dependence on software available bits in >>> PTEs than >>> Linux. That left the hardware architects looking for a way to >>> represent a >>> new memory type (shadow stack) within the existing bits. They chose >>> to >>> repurpose a lightly-used state: Write=0,Dirty=1. So in order to >>> support >>> shadow stack memory, Linux should avoid creating memory with this >>> PTE bit >>> combination unless it intends for it to be shadow stack. >>> >>> The reason it's lightly used is that Dirty=1 is normally set by HW >>> _before_ a write. A write with a Write=0 PTE would typically only >>> generate >>> a fault, not set Dirty=1. Hardware can (rarely) both set Dirty=1 >>> *and* >>> generate the fault, resulting in a Write=0,Dirty=1 PTE. Hardware >>> which >>> supports shadow stacks will no longer exhibit this oddity. >>> >>> So that leaves Write=0,Dirty=1 PTEs created in software. To achieve >>> this, >>> in places where Linux normally creates Write=0,Dirty=1, it can use >>> the >>> software-defined _PAGE_SAVED_DIRTY in place of the hardware >>> _PAGE_DIRTY. >>> In other words, whenever Linux needs to create Write=0,Dirty=1, it >>> instead >>> creates Write=0,SavedDirty=1 except for shadow stack, which is >>> Write=0,Dirty=1. Further differentiated by VMA flags, these PTE bit >>> combinations would be set as follows for various types of memory: >> >> I would simplify (see below) and not repeat what the patch contains >> as >> comments already that detailed. > > This verbiage has had quite a bit of x86 maintainer attention already. > I hear what you are saying, but I'm a bit hesitant to take style > suggestions at this point for fear of the situation where people ask > for changes back and forth across different versions. Unless any x86 > maintainers want to chime in again? More responses below. Sure, for my taste this is (1) too repetitive (2) too verbose (3) to specialized. But whatever x86 maintainers prefer. [...] >> " >> However, there are valid cases where the kernel might create read- >> only >> PTEs that are dirty (e.g., fork(), mprotect(), uffd-wp(), soft-dirty >> tracking). In this case, the _PAGE_SAVED_DIRTY bit is used instead >> of >> the HW-dirty bit, to avoid creating a wrong "shadow stack" PTEs. >> Such >> PTEs have (Write=0,SavedDirty=1,Dirty=0) set. >> >> Note that on processors without shadow stack support, the >> _PAGE_SAVED_DIRTY remains unused. >> " >> >> The I would simply drop below (which is also too COW-specific I >> think). > > COW is the main situation where shadow stacks become read-only. So, as > an example it is nice in that COW covers all the scenarios discussed. > Again, do any x86 maintainers want to weigh in here? Again, I'd not specialize on COW in all patches to much (IMHO, it creates more confusion than it actually helps for understanding what's happening) and just call it a read-only PTE that is dirty. Simple as that. And it's easy to see why that's problematic, because read-only PTEs that are dirty would be identified as shadow stack PTEs, which we want to work around. Again, just my 2 cents. I'm not an x86 maintainer ;) -- Thanks, David / dhildenb