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 123CAC6379F for ; Tue, 21 Feb 2023 08:42:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86E496B0075; Tue, 21 Feb 2023 03:42:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 844286B0078; Tue, 21 Feb 2023 03:42:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70B3C6B007B; Tue, 21 Feb 2023 03:42:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6060D6B0075 for ; Tue, 21 Feb 2023 03:42:25 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 31EE0AB7D4 for ; Tue, 21 Feb 2023 08:42:25 +0000 (UTC) X-FDA: 80490657450.28.9C53B39 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf14.hostedemail.com (Postfix) with ESMTP id 9C602100003 for ; Tue, 21 Feb 2023 08:42:22 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=RUcdOH9x; spf=pass (imf14.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=1676968943; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=TLJIC/RrvVE7PdqmcHdwOf29lNkhzpC8wWHN3DTeCNY=; b=A4vF6jlsnvX8R18fC2Q+dfhpqm5CAVeTZFlcls47vMcN6P6gBPyekO9xO5Wg9ydWZV9wuq UhwxH9omzmcRPbRns6seg4NPbVxg/sqzvDteOUb16snA6QNVYAiY2cBIrG1KBVhxNdQQdW bztO2ZscmRVqzAPFJR0sJDaZdgWl/DM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=RUcdOH9x; spf=pass (imf14.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=1676968943; a=rsa-sha256; cv=none; b=QGMhifWEszPEaBtgt6xiVpwVjXvsyLyCU58oU7Qu98f4RmiN5rPWJF4+SGcmlY2z4agfTV QTfETkNJ9MFrBvulVIkoBfDpjU1qskCTiQFtY1hQf91oIeLXkOUyGSwy/Rk+yH7lUdu9vz Mn/jF1S2uUPxPcuLUVrTzO8AImmmg+Y= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676968941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TLJIC/RrvVE7PdqmcHdwOf29lNkhzpC8wWHN3DTeCNY=; b=RUcdOH9x3MX/9X5WS4larND7VhdnzaHjeJI90NPaFmZCviB8hwFgEkGC1aX2Hef4CLK51G KapvMmBsnLHCZUD1pV2tYrRYJnS/3NOUYv2rxXRT2YoZMFMaNqSrgrvn0q2EioNn96YFu5 TLsv55qad46m/nu3zpV59YCVbiBqe5I= 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-355-gSgXXP-jOK2xsRYr7nc3fQ-1; Tue, 21 Feb 2023 03:42:18 -0500 X-MC-Unique: gSgXXP-jOK2xsRYr7nc3fQ-1 Received: by mail-wm1-f69.google.com with SMTP id bg26-20020a05600c3c9a00b003e21a3f4e84so1381808wmb.8 for ; Tue, 21 Feb 2023 00:42:18 -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 :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=TLJIC/RrvVE7PdqmcHdwOf29lNkhzpC8wWHN3DTeCNY=; b=nfymQk6nhpQdoFOsrV3U01tMVNVFiPHk1CWKk57uVMXptv5xkoXIelQQIVyKYer/5E nHPCyOD8GnnXQ5Mvhfw9hUhE02h15GqA+ZRJ+CueMq8olWV9h3BAhnQL8JBZCdgrVP2N 2XFeAVbYkIrBleGQNlpJ40wrQ7OaliSWZ/J7Scbalefe0IR9sqIXjGb67YPtXqKxtIwe VGEYDDyz7cSMoJbPcqEsOMUaKSrmOtJulNLUQkdvYsKZCH2gVuK+3JH55gMNKncKgAl4 2FdMGcifryfsZKnUp/3Tkcp3FWdWxjpraOQIyXBXllhXCtJ+L8upB4R80Gspn+R4CYEw 7FWw== X-Gm-Message-State: AO0yUKUVodD+MrVvhi8vTeblWZNrxXZYRyx8OxEDiYaLU9rvg5NvEZgL S2CU8xEo6NzEtig2YtA/HKnG1+lv1+a45lPvvzkgO5QJDbeHptceBAl64jvhycoi+9QTPQNttQG cFcw2o6uD7m4= X-Received: by 2002:a5d:5308:0:b0:2c5:6025:cd65 with SMTP id e8-20020a5d5308000000b002c56025cd65mr2218720wrv.9.1676968937540; Tue, 21 Feb 2023 00:42:17 -0800 (PST) X-Google-Smtp-Source: AK7set8HYdakBP7NNr75W24EBS8ylbUTvbqe5cKGc3PV4r6NUAF4mQpJtQCSggSEkz/UdpiRyLcPVw== X-Received: by 2002:a5d:5308:0:b0:2c5:6025:cd65 with SMTP id e8-20020a5d5308000000b002c56025cd65mr2218684wrv.9.1676968937186; Tue, 21 Feb 2023 00:42:17 -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 c24-20020a7bc858000000b003e11ad0750csm1147194wml.47.2023.02.21.00.42.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Feb 2023 00:42:12 -0800 (PST) Message-ID: <8b8ffa43-9003-010d-30ea-c5de128d646d@redhat.com> Date: Tue, 21 Feb 2023 09:42:04 +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 24/41] mm: Don't allow write GUPs to shadow stack memory 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, debug@rivosinc.com References: <20230218211433.26859-1-rick.p.edgecombe@intel.com> <20230218211433.26859-25-rick.p.edgecombe@intel.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20230218211433.26859-25-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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9C602100003 X-Rspam-User: X-Stat-Signature: b9jby3jdmkz918empnbf49r6mqbidrga X-HE-Tag: 1676968942-230012 X-HE-Meta: U2FsdGVkX1933QKIJSU+b/2c5Y3vs/Xb1LIyXMPzyiYejf6xk+1J8E3Mg/oq0osyCtXrhsWzlHqG2ZgEDE03jw1XYwc0U6b02HUhleBIY1AfDywhT02dODyGp+L/780eMrWT/XQPV0RkVTAwSjWQN5XMkgqavbd9wPRMoNj51vPaq0PbfY4lzWpVin704qmZrFX+V/Fl7639FkJs7mmMo0ya5LiMs1ZVMQjarsz1jAUtOLoY4wzO6WN7IWowQren+faTTuh10RityaSR1MsD2QrTikXYxKHzqQZ0uhXCtJDirP8rguEXKZTko7vH+1SAWs9OWOF7dLnsL66OrHSVGqN7dn/fsH9PEfO/Eds54oDLajCyCYl3tC/1xWcsui7RkwEhVkV8GttunQJy6UAzc0/atfioCdfYoy+usEgDj200TMsUPGr9L7Av4FIc7Nu/bp1YUvjo2HYzVndtv2BB+vc5EOnPNuA3jprO6ugQhprH70L0XrTCc9cQqAGykOluBcS6azKs80juLXucAPRbO9K/W1vUmYMj9xZSUFil5vlFFgkl0Y4AC6frReadhVBr+lMg99KnVEgpdQYYPU60Wp58icE1zsqKBXJmaUJe420MuFgyuA2Ye6W9CrHEw/FzByZTrjIL/Gz1X9OCwhU1+pbmiM/LSgzl6EEGSKCzsXMWF5JvAKyO+sfIpj0qeX1R7a6894urCTtE3IyuGb700HZXVhpwGE638Pwwt6R3VW92ZFZH1vfx5S0d8dY9nfWtDv6NeBdYBk+uR5bcJbzcg/2WhflDSRkYIz5HEMNDKWwdXKqPdBicJ9X54VkBchCQQPI/uRD6aP3jRNeXUntvYWBouaYDYHHBvGKgaN9synvSBY2Tx8vrjG7ytO+Z461MUCq7z3t79/ZNVvRAoRhL1+SJ/f8D42nKYIGyIrBNKPK91VWXzqhNsW5MhPvlD8QTb/Tx+tfA/cwPPgVIkDk Xzv0Z3ou 8STfDzWEr2TYqbI9VUBCq7ifRb9HCs00EH2KgO98VQLVyPvyOkkJbTj9DKvI2DFpyyaMtigMLGK1tcuT/fnCdlPVJNWx4QuM5vGY/OgnkkwUu2rmYKF2VF47Zjj0jXM8uNCc/BeOGsf5HT0rYThKFFkaqYUZ4RcFm0fubI8ybtp36qjjA3f4cUJiSvxdfNhYhIv+2iQiv0d/xvomQNVVxxC9IGGVREQ4/bBDNtVCWtp/XPLOzR9Tc9YyoKb0IKAEAzdK18n6pm/SKUe9OgNbpXNuDgb8Sqvw4gEbjn2HMsj8ykWJbBq0Mc4Nq0EMYmK912XiwdN4XZ1Or/K7kyp0fgqN7kki+YYWi6f3fn3pv//ZJlc2e8RH48csSav6R6pbOZ+ScIuveb8PCh8w3lNOXlj5skuPF6jsP7qynphcXNzrNGsVLyHUu90pmYUsS5OTOmqTcCcVMJlaLfS1PYjfLB5dZtWuFMRwBvb47T4UMSDHqQ1ZRBVZaq3UjkLrx43gWPlVTfkUARK3MoSB2awQW7DqVTjs9FYe3CYUeXT370FUmYM4vmDssKngfCzvzJHCDqFca3YGakNeY0lNbQe6H8upmP/xvCuZkXbZf 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 18.02.23 22:14, 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. > > Shadow stack memory is writable only in very specific, controlled ways. > However, since it is writable, the kernel treats it as such. As a result > there remain many ways for userspace to trigger the kernel to write to > shadow stack's via get_user_pages(, FOLL_WRITE) operations. To make this a > little less exposed, block writable GUPs for shadow stack VMAs. > > Still allow FOLL_FORCE to write through shadow stack protections, as it > does for read-only protections. > > Reviewed-by: Kees Cook > Tested-by: Pengfei Xu > Tested-by: John Allen > Signed-off-by: Rick Edgecombe > > --- > v3: > - Add comment in __pte_access_permitted() (Dave) > - Remove unneeded shadow stack specific check in > __pte_access_permitted() (Jann) > --- > arch/x86/include/asm/pgtable.h | 5 +++++ > mm/gup.c | 2 +- > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h > index 6b7106457bfb..20d0df494269 100644 > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -1641,6 +1641,11 @@ static inline bool __pte_access_permitted(unsigned long pteval, bool write) > { > unsigned long need_pte_bits = _PAGE_PRESENT|_PAGE_USER; > > + /* > + * Write=0,Dirty=1 PTEs are shadow stack, which the kernel > + * shouldn't generally allow access to, but since they > + * are already Write=0, the below logic covers both cases. > + */ > if (write) > need_pte_bits |= _PAGE_RW; So, GUP fast will always fail when writing ... > > diff --git a/mm/gup.c b/mm/gup.c > index f45a3a5be53a..bfd33d9edb89 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -982,7 +982,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) > return -EFAULT; > > if (write) { > - if (!(vm_flags & VM_WRITE)) { > + if (!(vm_flags & VM_WRITE) || (vm_flags & VM_SHADOW_STACK)) { > if (!(gup_flags & FOLL_FORCE)) > return -EFAULT; > /* hugetlb does not support FOLL_FORCE|FOLL_WRITE. */ and ordinary GUP without FOLL_FORCE. Acked-by: David Hildenbrand -- Thanks, David / dhildenb