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 43001C64EC7 for ; Tue, 21 Feb 2023 08:34:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D2836B0073; Tue, 21 Feb 2023 03:34:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 983066B0074; Tue, 21 Feb 2023 03:34:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FC4D6B0075; Tue, 21 Feb 2023 03:34:44 -0500 (EST) 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 6F4C96B0073 for ; Tue, 21 Feb 2023 03:34:44 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 27F7AC106D for ; Tue, 21 Feb 2023 08:34:44 +0000 (UTC) X-FDA: 80490638088.26.B8C9FCE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf30.hostedemail.com (Postfix) with ESMTP id E725980011 for ; Tue, 21 Feb 2023 08:34:41 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GtvOw71B; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf30.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=1676968481; 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=s3hA7io5oEGOw3xKaHyd+KsM6je8a9BDLLtnwSNoTqc=; b=SNrxPF3PY7nBZCF9dMjjHAmU5hwNIijMvwpAppaIWjvaCOmEqpVTL4x7H4AFL/c8IvxWx/ 3Hu5IPrubfljQ1zwdmEqtBPYqaUMYgnSuLVrumwCiWcGD18VbvIjEKUWyHU+BIfzpilcYX kfaJrYG3Dy1FV035SzJZisHAVCBoo7I= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GtvOw71B; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf30.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=1676968481; a=rsa-sha256; cv=none; b=VhSb0f3dSAswxOKNyddle51sKQDy1o3oIIb/LzauNOHNmu1qEjFQmKQkU12yX8RdUmidi0 GIoH0o/AZ6ReESGqQEiP1oIsF07DV5msz6PbL9i5Pwfkn+KHxyu6p9tnrt8mmDzXfYvX+7 GXI2vIsGtfHpjR3X696r3X2dNF7iWZw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676968481; 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=s3hA7io5oEGOw3xKaHyd+KsM6je8a9BDLLtnwSNoTqc=; b=GtvOw71B/sdc67NR8XisOqariHMAhHWxiWTJVzcXx6qp4/JY0zNUrcyvZk61XCqoMDsGrI 53Q4ibc3t4wq6DZufYV7T7Glcz0mWVIksbadTIX4EboTRbD5xhxgYdteENVsBxzqhwe7/0 XZDRpRpDk3sISiwPyEKAw9JFnWOR0Eg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-554-b4BLZ-xZPPmdOiT1pPpD1w-1; Tue, 21 Feb 2023 03:34:39 -0500 X-MC-Unique: b4BLZ-xZPPmdOiT1pPpD1w-1 Received: by mail-wm1-f72.google.com with SMTP id m22-20020a05600c4f5600b003dffc7343c3so1683194wmq.0 for ; Tue, 21 Feb 2023 00:34:39 -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=s3hA7io5oEGOw3xKaHyd+KsM6je8a9BDLLtnwSNoTqc=; b=62VV+QPQtoVGy9YQ9Zqsbm6DHpiHWwHIAuJ5bR0nTBBRSoatnVcxeSezqOK7bcpNJm n5EjaSB7ClmfnjzS2Uv1iTF8PtsSqpzAEi2Wfv8KQBoXzz9X5R8+hyvQSXtBT9PyXVQi 06LhhRSPYYvOTQ+rrieraxY7CZvcPcAE4b+QzOW0kqbGE1Sodp0ZGO8q35ycm86Gl8qK vSszXSUKJGrBKHNERsBwJt34M1a/WbwmbcGHoQdu4EY76j2B/D5KV8gqN+eBQ4tvAZzL 8FLIrCLPCD8uaKFsl83GAfSO+Eb2pBfViF2iVXd2hSHSDwNdtx+0udHFwSvvdt+CGmwe xO1Q== X-Gm-Message-State: AO0yUKXo26G+3uIvUeMQMnv1vEPOS9YHLNtiTLeFRU5/ac27pAcLqfI7 IXlf/WCNSyIEvdXP0/7pWm5M438q18ovAqhttHZWctZ3aLQme0FtXGffjb/dI2VBeWNbkqjfHfm Ts7vjXLYLTBk= X-Received: by 2002:adf:f883:0:b0:2c7:3f9:7053 with SMTP id u3-20020adff883000000b002c703f97053mr1601060wrp.52.1676968478707; Tue, 21 Feb 2023 00:34:38 -0800 (PST) X-Google-Smtp-Source: AK7set/VzopSRLbEFNZlfiqKhL0ooGf/sc8yqRhmWuymXLlPTJDz78LKcQjIJ00MRvJ21tbfpizkTg== X-Received: by 2002:adf:f883:0:b0:2c7:3f9:7053 with SMTP id u3-20020adff883000000b002c703f97053mr1601006wrp.52.1676968478294; Tue, 21 Feb 2023 00:34:38 -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 a15-20020adffb8f000000b002c3f03d8851sm3539769wrr.16.2023.02.21.00.34.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Feb 2023 00:34:37 -0800 (PST) Message-ID: Date: Tue, 21 Feb 2023 09:34:35 +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 18/41] mm: Introduce VM_SHADOW_STACK for shadow stack memory 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-19-rick.p.edgecombe@intel.com> <366c0af9-850f-24b1-3133-976fa92c51e2@redhat.com> <9e25a24f3783f3960e2c1e5e68a6c6fdf3d89442.camel@intel.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <9e25a24f3783f3960e2c1e5e68a6c6fdf3d89442.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: E725980011 X-Stat-Signature: redkppa7cii4prcguadgpok1xxpu1nnx X-HE-Tag: 1676968481-856867 X-HE-Meta: U2FsdGVkX19imucvbMmsTAz6d1zrxcT8O+Uxnha5vCS5G65C7SWY6Mg9tLFT1BfQxPq7nXqYw+xHsdkOzk/Qva0l82pT6piEG2viVFcixVAD4/HTKcQguMEylFeAIymeyVOarL0wBbim/PlEUhMxNnuI0SVjGNvMAii//bXoN+esGwADAwPwMQjlb0O2tsNRgJcrK/5r87HnLCWSmnZ9TZ6o49K6jJghNlD8UFUzuE1y872eWv9Ref8Ch39hKLe9eH8ecE0hV2hdGM/WrQFnOPTlBdKuNGHRpDhUTlfMbeurevXSlnJNEKyEnDgKPa36Zta+gLCFwRb3KhrWVFSbjqrMyhpUh2e0xAKWiS6+P2LmWtIFtsl/VJRZD1djYSM5QOffG5pYCh8TQ7z0q4Thg2ObERsvrEhDC9loGOE8nFmBOlmYQrlJH+oXKGH4h3WN0SjZTpw6ndAC/Fz2Z7AzcqBw+Nhn0QxcRQLzixmuREHKzuqhk1+PZtUpNNmIsKbue8+Lnhy42eqtCSL4ZVKNucJ0NVjSwvzZ0UpvnAm9IULdQOcivfnWBEOFY07blYoIjEHpFft6kbS1CKYMbErsi3b8S8KT5YhAB8+VyyeCyZBX2WiKX4lMqMzuL1oXB/ZpQmNWgtofEpMeul6zgGQN1Vy+Yqlk5986S+a9wjb7NwN0EonTEWB9ASKBLEMeyEx7ftciKddOozJw4S/pvvwXZNuxTifCIvyQPF3irRpWgZf3guKPyaCzlCpbLlSAZm1mi4/iSno+Dv4kOIFByUM5PQIHfrjKV2LHvueVVM29QtDDm5mIUBVSPp7zHp4xzMglcqYJh3fPVbYtvueHuARiKgKJBwsvB+4+gdbD50p6SZHAMtB9eufEjMQqcdz6VvyJywiinackiqzQu0xMNAJQBAS/I4QuJu/9jdvRv38OQs7gMytEI2uRubcXMjL/RIOphdLo8/X5XLptBZGsNOW lsoX3iDV pTZmrZOEbe/M7c+V6YhELrWDbzQAdwk0GbRD4t6qO/jsaX3VANFab/2vBb1z1EBJImAxdEqVRXZ1qheQkJ7I8dK0k4zECQcDUhSmXANmil38llMkCp5CBr8tv3BRLcti/9m414RmR63Ys8GdD0vQAi4Tiyub75DWTU8lP3DOjOFk37rapht1GPddLTOuP+la10Ju3c3+ZyAemjhlbOAZRbvB/epLlSUOGzkUv/i6JXk6IxCeY06nNW6jGBWycCfb0Rd9pfYQeKpmylgOiI1tqkWtNUcgmF62c3LRAgVjAkNh/GT3oBR73gfNz+kUA3XXCm4od6FF4mFAQhplrxoDLB/c4gP7UZnLDf5GzTx5QACOMC7E5Xm5P0XpypUE96jGGRjokRt9y9Uf0Q69YxhxYH1dVhqQX87Ff0XVGVGPB5eNmPCj8VdUFeDzPrFfmHGK5HJz0ArRO5LQiHKHdnrRFKewmEtQiddrdw7QWcVCUkVJdIFyPQaPjGIfyX5GCS2cvvP3Qek176hYPU2ZQ7tXhSUMczwm3O/HAaeqh6VCVZJeV8ihApDQoItfz2QbdW+t16k5PUyqvwhVVKx8pkNrE5yAiv5aDZylOhcofstEDAsrMZpVKfzkomWVy+qDIQcfGbZm/7dw460CahQmlcQ9tGoFt40+75KEwv2up 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 23:08, Edgecombe, Rick P wrote: > On Mon, 2023-02-20 at 13:56 +0100, David Hildenbrand wrote: >> On 18.02.23 22:14, Rick Edgecombe wrote: >>> From: Yu-cheng Yu >>> >>> The x86 Control-flow Enforcement Technology (CET) feature includes >>> a new >>> type of memory called shadow stack. This shadow stack memory has >>> some >>> unusual properties, which requires some core mm changes to function >>> properly. >>> >>> A shadow stack PTE must be read-only and have _PAGE_DIRTY set. >>> However, >>> read-only and Dirty PTEs also exist for copy-on-write (COW) pages. >>> These >>> two cases are handled differently for page faults. Introduce >>> VM_SHADOW_STACK to track shadow stack VMAs. >> >> I suggest simplifying and abstracting that description. >> >> "New hardware extensions implement support for shadow stack memory, >> such >> as x86 Control-flow Enforcement Technology (CET). Let's add a new VM >> flag to identify these areas, for example, to be used to properly >> indicate shadow stack PTEs to the hardware." > > Ah yea, that top blurb was added to all the non-x86 arch patches after > some feedback from Andrew Morton. He had said basically (in some more > colorful language) that the changelogs (at the time) were written > assuming the reader knows what a shadow stack is. Okay. It's a bit repetitive, though. Ideally, we'd just explain it in the cover letter in detail and Andrews's script would include the cover letter in the first commit. IIRC, that's what usually happens. > > So it might be worth keeping a little more info in the log? Copying the same paragraph into each commit is IMHO a bit repetitive. But these are just my 2 cents. [...] >> Should we abstract this to CONFIG_ARCH_USER_SHADOW_STACK, seeing >> that >> other architectures might similarly need it? > > There was an ARCH_HAS_SHADOW_STACK but it got removed following this > discussion: > > https://lore.kernel.org/lkml/d09e952d8ae696f687f0787dfeb7be7699c02913.camel@intel.com/ > > Now we have this new RFC for riscv as potentially a second > implementation. But it is still very early, and I'm not sure anyone > knows exactly what the similarities will be in a mature version. So I > think it would be better to refactor in an ARCH_HAS_SHADOW_STACK later > (and similar abstractions) once that series is more mature and we have > an idea of what pieces will be shared. I don't have a problem in > principle with an ARCH config, just don't think we should do it yet. Okay, easy to factor out later. Acked-by: David Hildenbrand -- Thanks, David / dhildenb