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 21A74C05027 for ; Mon, 23 Jan 2023 09:50:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 681476B0071; Mon, 23 Jan 2023 04:50:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6313A6B0072; Mon, 23 Jan 2023 04:50:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D15D6B0073; Mon, 23 Jan 2023 04:50:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3E4C96B0071 for ; Mon, 23 Jan 2023 04:50:22 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 699F81402C4 for ; Mon, 23 Jan 2023 09:50:21 +0000 (UTC) X-FDA: 80385593442.10.B613AF3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf30.hostedemail.com (Postfix) with ESMTP id F14A380015 for ; Mon, 23 Jan 2023 09:50:18 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="H/R+ghhr"; spf=pass (imf30.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674467419; 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=kSYxORSo5fJ20pO0AdfHiuiQJWJRfHcLYdctAQzz20k=; b=SqeWrZRtuJlj+8g+fSS4frVucS4o5u+Tw8wTQNCF3pJ1IsRT5UG0FVVVINWKddKNFa7LiO Ngs9Oaq2NfI3KzWGxnNqGHfSQRAlzhhinqfe2tTDg6kDSbhwds+DoHbQwxsPaB+agSXNjU ZuJSx/uo7At6NUbarMaGl5oAmxH9hFw= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="H/R+ghhr"; spf=pass (imf30.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674467419; a=rsa-sha256; cv=none; b=F2yqr+atw9ytA++hbMJdtR42yGfPufcKBCrOEU6ZqjO/KE5vuMSRio7iO1lukKV3AFm+m+ 4Bz5Hr382eLaii2vNrrXYuOV5T4uiOPE8Ai3AQEl7Kcxu4A34fx5OE6OWzWeOEL/M/GhO5 l75XpwhIzBfGfNoSL3PxJvUNCp5I998= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674467418; 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=kSYxORSo5fJ20pO0AdfHiuiQJWJRfHcLYdctAQzz20k=; b=H/R+ghhrhsiL4pY11BZXl3daqHx8WZF9OqyOcYz/9Wxd8mXnL9Y7sqFbqcmQ/lezkZ/8f3 tD3l0mZA8vkuxHZHLPBJ3suL4i0PL9YXfGxIODHHD3mnT746dnerwFpkT9TY5EnSNXAwZf NeGlMVtwhjznBVEuGxvOQqEED+TcBQg= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-533-SMFCED77PmeKU0bYS4ekQQ-1; Mon, 23 Jan 2023 04:50:16 -0500 X-MC-Unique: SMFCED77PmeKU0bYS4ekQQ-1 Received: by mail-wr1-f69.google.com with SMTP id o15-20020a5d684f000000b002be540246e1so1264498wrw.22 for ; Mon, 23 Jan 2023 01:50:16 -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:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kSYxORSo5fJ20pO0AdfHiuiQJWJRfHcLYdctAQzz20k=; b=C6HnY3VNeaDDh+Nvd1Rt0SNgIIW8s7XjudHysYaXirF+RX8fAswNeTdA+4DYFS8d+C BxfxPrVSv6IkXtGnYgOKEDNtL6cqsf5DSWPsW0bwlF7YEavZH0+rcmRGRvVAJ7UZ/zxV twfKhelqgfbZQ+RUhXFB/UoBpXqpnUGPxWgweTwyJ+k9wF/La86A5SdkGhuhh6Y3r3i5 9eAlnCZx8tfkuRfTuBWI50Db6cfUK/uB/Tlbh7tBzQZMA0nqtaNgbN9mfctccZLQCMo5 hjmooxKOtQokWEFmxh4fNS3jih5bdyde9flk0slHgprJbl1gtnrGEmSbYXnQk3sqRfSP w3pQ== X-Gm-Message-State: AFqh2kqyY+7EpUosKxf0BV7hrIurZbwnHW+cJkeGdDdOhMdRDhQWLRSN VpcnLumilDbE8kEv4rWUSDKl8S04Ls5/p9qaU4VZwQ3itTtHDjaYNZQT1cHZWWj3qdAHkzUv4JB wAMYcqJu3Jwg= X-Received: by 2002:a05:600c:3b1e:b0:3cf:497c:c4f5 with SMTP id m30-20020a05600c3b1e00b003cf497cc4f5mr23576047wms.13.1674467415696; Mon, 23 Jan 2023 01:50:15 -0800 (PST) X-Google-Smtp-Source: AMrXdXs9yQJkaBPo8s7D1+JPWykvhgcJBeDr0ywpOXES22KIpL3qQHqi+WIix769Us7mHmdo/CB66w== X-Received: by 2002:a05:600c:3b1e:b0:3cf:497c:c4f5 with SMTP id m30-20020a05600c3b1e00b003cf497cc4f5mr23576006wms.13.1674467415336; Mon, 23 Jan 2023 01:50:15 -0800 (PST) Received: from ?IPV6:2003:cb:c704:1100:65a0:c03a:142a:f914? (p200300cbc704110065a0c03a142af914.dip0.t-ipconnect.de. [2003:cb:c704:1100:65a0:c03a:142a:f914]) by smtp.gmail.com with ESMTPSA id p1-20020a1c7401000000b003b3307fb98fsm10069782wmc.24.2023.01.23.01.50.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Jan 2023 01:50:14 -0800 (PST) Message-ID: <7f63d13d-7940-afb6-8b25-26fdf3804e00@redhat.com> Date: Mon, 23 Jan 2023 10:50:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 To: Rick Edgecombe , x86@kernel.org, "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H . J . Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , Weijiang Yang , "Kirill A . Shutemov" , John Allen , kcc@google.com, eranian@google.com, rppt@kernel.org, jamorris@linux.microsoft.com, dethoma@microsoft.com, akpm@linux-foundation.org, Andrew.Cooper3@citrix.com, christina.schimpe@intel.com Cc: Yu-cheng Yu References: <20230119212317.8324-1-rick.p.edgecombe@intel.com> <20230119212317.8324-19-rick.p.edgecombe@intel.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v5 18/39] mm: Handle faultless write upgrades for shstk In-Reply-To: <20230119212317.8324-19-rick.p.edgecombe@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: rspam03 X-Stat-Signature: zwixopppws5q611i77uxb5pcswdj89xk X-Rspamd-Queue-Id: F14A380015 X-HE-Tag: 1674467418-53522 X-HE-Meta: U2FsdGVkX1+lbpKMpYTuyBqJNf7dQ/jIzIcHPFYPiJnElcln0d1WDgGxBT379hDxaIs60Arv2lPNi4DXGtHKBH3MwdnzmGrIkVdgpRetA8EW9qg3iRcY5SRXsARGSHSpoo0eUjTh+0HzpkHUjs+R9SWfknyaNOKFQ/Jc6bw6mmDVu8Vp81MdlMRPGNGfvQ782yt93xrvg1erJlcISTfLbDpaMVgZVh8vjBnc7e/ssQhlSSZneWm06Z4rh94F8GxXB4ot1ns7U8iZ8dxIlTG9bwjqNXnMJqKd+Sq8Xt0KuzhoTxdCwGNLUle5gyO6PK08BygGr4Ra/+Negg1YBp61y7CmGWEvDh0fFSPnAq+0aeRFKNprofed52WrbXlEIIWybAV3570ohHhMpxZGp8eSm3GJvaqLtmBgnxTMfPidxyeZY6oF8iCjXGO+257+7/dbI+8GPp+3u7u7CmooT56pAGINBr1sOkwDiO1a+eWUkXB4IRqm/0cTc3LvAjHNuUSX8G3U9dTR81uWDCXpcp6YGIor8ydBWwG4AUMV/CwGhEGJdy6LuSCwW344do1lSC/Kj5O/nL4S2FQP+Nz2Yog+Hm9qATMrZ3uBzWHS97Scu0qbpvI9zDO+o8o55mAUUgU4l0sbkvLVROSll38xzKM47YmGf+R7+zD2WHQSDnho7YujnU89w8FSV8kswfY6mqq6sp6xqs3Q05E0JPQlrnIr1rqWgX8Kahy+59xLTyPO7es5Y3ElvrEGiCJZ8Rjc53xso2vx4r7RIZoi43pObanfxfrV2gUKr81bQB18/lveGSiBom798X3XgecaJK96yUuFfP2t6ZnQXsfrsUS0e7MR7fxdFiyRVcr3PlFcfyBbfxDSwoZuzNjZEHGbbnhRJdQCedLs6kzlPHJuRsCU+8gsjA8+BEc5xhVTAxQl+7KyuF+K+LoPdCE8usPVhXZUW+/QAOZzpAyqu+jTk+btH+3 Aj3PL3TN 0ecROYn+CAAzSAp8NjMUmAsSESlIE08hIwCHvvSkGRXrMymw6O7oQOJs3/Nc5cjBslmmiw9xEy1digGWg5HdueIBuicq61A3I7PaP0fwu2xTDOdnRnDckafDwDxIDn50whnckEyv59NztgBbDPitClNkhENHHO3JESmId/RTPSjWlnXHdkcAuNkNxV447H3VE1FWzflkAu1zQqAwp/4jyypByefKnflQyZrtnlOC/3WtIoAXLtUsbqDCfN/HYMIYUN5LVBbtz0LrDpoW/gKr0WP2ymgO7WCHhQp0w1QuySl4cG5y/N9/eSgWxnQtP5EUpFPRGI0JuhPvf6VjEIPS04Z+IgQlw9Xsn+iBT5Cy5TAY0Qm9yg919HohAvhRmMQYvvNHK3AbtsqyPrBdOeOdVeLRUJWNLevoAOpUd0MdY/5TiHOY/lqqTmeAQ+YQT+GdGstEEi9boWM1mPFfvH9n9Dib8F6uH6Dp5+uX4QVYP7hMCZ0G8glS8PKrh63JYjzrTgxclzosmyzy29bp5S7cvO4VkGhp87FDI44CS 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 19.01.23 22:22, Rick Edgecombe wrote: > 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. > > Since shadow stack memory can be changed from userspace, is both > VM_SHADOW_STACK and VM_WRITE. But it should not be made conventionally > writable (i.e. pte_mkwrite()). So some code that calls pte_mkwrite() needs > to be adjusted. > > One such case is when memory is made writable without an actual write > fault. This happens in some mprotect operations, and also prot_numa faults. > In both cases code checks whether it should be made (conventionally) > writable by calling vma_wants_manual_pte_write_upgrade(). > > One way to fix this would be have code actually check if memory is also > VM_SHADOW_STACK and in that case call pte_mkwrite_shstk(). But since > most memory won't be shadow stack, just have simpler logic and skip this > optimization by changing vma_wants_manual_pte_write_upgrade() to not > return true for VM_SHADOW_STACK_MEMORY. This will simply handle all > cases of this type. > > Cc: David Hildenbrand > Tested-by: Pengfei Xu > Tested-by: John Allen > Signed-off-by: Yu-cheng Yu > Reviewed-by: Kirill A. Shutemov > Signed-off-by: Rick Edgecombe > --- Instead of having these x86-shadow stack details all over the MM space, was the option explored to handle this more in arch specific code? IIUC, one way to get it working would be 1) Have a SW "shadowstack" PTE flag. 2) Have an "SW-dirty" PTE flag, to store "dirty=1" when "write=0". pte_mkwrite(), pte_write(), pte_dirty ... can then make decisions based on the "shadowstack" PTE flag and hide all these details from core-mm. When mapping a shadowstack page (new page, migration, swapin, ...), which can be obtained by looking at the VMA flags, the first thing you'd do is set the "shadowstack" PTE flag. -- Thanks, David / dhildenb