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 2F0CFC05027 for ; Mon, 23 Jan 2023 10:45:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9ECF6B0073; Mon, 23 Jan 2023 05:45:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A4DA16B0074; Mon, 23 Jan 2023 05:45:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93C366B0075; Mon, 23 Jan 2023 05:45:19 -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 85E4C6B0073 for ; Mon, 23 Jan 2023 05:45:19 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 47B0680720 for ; Mon, 23 Jan 2023 10:45:19 +0000 (UTC) X-FDA: 80385731958.13.8986068 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf23.hostedemail.com (Postfix) with ESMTP id 92E30140008 for ; Mon, 23 Jan 2023 10:45:17 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DOjT2enm; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf23.hostedemail.com: domain of fweimer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674470717; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lQYrnwFUsQDqjmZGkPEbqFd0u/uKqN3ucpVdTalmvp0=; b=jM0PV/ry1YrltXgzzTlHrhsSSxAZeREK6KP/j0Z209yYlSA9Miw5Q2M+9IvcKcrUroJJFe AqYdYKkzSwk5+fOqfEgkjKnQ6na5/cmDX7BoJAchaoJMJ7tfUdmxh657ZdfnoPQ+DYZ7Um dzMiPKRP4g/o2w5wmC7S5ux6+Lydrbk= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DOjT2enm; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf23.hostedemail.com: domain of fweimer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674470717; a=rsa-sha256; cv=none; b=gSQDwi76wpUV5LOSV9msbW6e1XMFj4xbKc9qvQt/hr1oGbvJ8JuhZm/rQfKO63UmQC1Cdf nG2uFhOv9EzOMdxQkVNW9NNg9tyZcm7QgQj2tu2W8IqWCfv8NZ8SzflC8VXS/NVgTFoNAm ueWi0fV9FWTeCwiJF7fG7GUjKs+IRZI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674470716; 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: in-reply-to:in-reply-to:references:references; bh=lQYrnwFUsQDqjmZGkPEbqFd0u/uKqN3ucpVdTalmvp0=; b=DOjT2enm8V4mJ2xTsEJUeLKMWxwZ0G1pwC3wl/mUkzIHP15dJeHGUmMZxcMBWFKfX7nyoY AbQmz+OaN0NqF5IWuZ8KcdIFScFmSmsKQTTXoqtS63tiEKu7ym+RcFUQnRHTmaj+5pem5p VyWbwNQ5vlMJwAEDix6ymshlgtpAzHE= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-14-z2gzx7qvMwO7rvRXUnnpYw-1; Mon, 23 Jan 2023 05:45:13 -0500 X-MC-Unique: z2gzx7qvMwO7rvRXUnnpYw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DEA7629ABA00; Mon, 23 Jan 2023 10:45:11 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.50]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 22BF74014EBE; Mon, 23 Jan 2023 10:45:06 +0000 (UTC) From: Florian Weimer To: David Hildenbrand Cc: 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 , "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 Subject: Re: [PATCH v5 23/39] mm: Don't allow write GUPs to shadow stack memory References: <20230119212317.8324-1-rick.p.edgecombe@intel.com> <20230119212317.8324-24-rick.p.edgecombe@intel.com> Date: Mon, 23 Jan 2023 11:45:04 +0100 In-Reply-To: (David Hildenbrand's message of "Mon, 23 Jan 2023 10:10:04 +0100") Message-ID: <87fsc1il73.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Rspamd-Queue-Id: 92E30140008 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: tmgeuqn8m4z9iuqa9p3ju1htyy5js8fo X-HE-Tag: 1674470717-507742 X-HE-Meta: U2FsdGVkX19H4UOFXWQW1ZMcZDiN55Gzwc1dk5NmgxVgwc//7hBD6bZJdZIVbqx42+sUqrrmqeimVbhZL7mWCH2bH4buC/5+WQIFwXBl3608ekykbIao6auANOc/nzUD9FUFTovt9KZyuIs7EEj1IuuB86rYwsh3qhTHxRk/NpFIdGcI4IQULy7JzMYaW9fm0fP3Sf5zmEwvFh8I2fM3XFZp1W7hPnebIUGB70d9QrJ7bh6GonkqAUxxfEWZh9vlPHkSWuWlQSQOCm9Gdh6cAVS4fk53wii9SYXqZ/5fR+9kjmw/BoWY6/c5NdvjLj/BSGYuMJeixe4JvOSOQQc87Z1eIWKeqZ1LtkRHrCVSqbFdCJZDXAaKV5XtJLyCqgsiLU2Ew0otetjoAUI89yQerHmn8mXOfMjXrya2NMXLCaG+2OoJ6ot4mitRlUeHWc7gXn47To1b+GjXT2fQYTwjPlv0lLYKyBVElwKbCUHpWgpZTcUkt/CC3Cb+evC37XpQEnnpBE9HoD9AzsdW8nwz/VUSqWXt2hu7wkdAScaZsRjVJiyUOv0GVTTy5BXW3wksQs5sxkDHDVa8b8GsaMPwO1fO0myjvUTMiGHTf+IAgLA1ANNDJj78AZqRsqeIU6Nok+2HF27fA9CawNgt113dbD1dALndKWhdtBsP2/nYw3Z124kO177yWmSPxvkRembzygNfVNk2Z7Jmb09Onk7uaLKa+GntQOZ0kQc/8INemVH89mo9FsSsjF4kSW42alkQPG2iAaqD+aFZVqyH0cAuoIoCxSNCMaJkr3/Uxww3m0g5d/X2ah5EpY52XItCjrn9zpAmN3T/jTNoDJrMZDcxayQMUu2yMUiFj3ihUP6fo0xM25VSEiQdjxHu/3yhpt70OwjdXCgsXENTRn1ei60mhqDM3nsc1+tKbHVaDQ/FzfvQzYu/HU8trNFjO07CMN2Ijj55Bw7oNadJxYqM/b6 ZKjTH3n0 G0BCXSr05cigZQuAhUDq8aSXOwqckcYUUUQMubKtLgae487wWLvb9Sg4O31JBON3WEp/OVw2MEy2O7vXzLmvXVDEHVl10+ePXExPnTwsQ60FKuyO2vRAhQ8ns6uQibPImSU5TX8JA8D7Ip158nbq8zZZXuO6TGK9b/Ikgt1O4dU+ibjy66Tkkkr+TF9ubSd9MqBF94DQOFOiMIKA= 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: * David Hildenbrand: > On 19.01.23 22:23, 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. > > So an app can simply modify the shadow stack itself by writing to > /proc/self/mem ? > > Is that really intended? Looks like security hole to me at first > sight, but maybe I am missing something important. Isn't it possible to overwrite GOT pointers using the same vector? So I think it's merely reflecting the status quo. Thanks, Florian