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 CBFACC54EAA for ; Tue, 24 Jan 2023 16:26:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 637BB6B0073; Tue, 24 Jan 2023 11:26:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BF886B0074; Tue, 24 Jan 2023 11:26:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4392C6B0075; Tue, 24 Jan 2023 11:26:52 -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 2E7246B0073 for ; Tue, 24 Jan 2023 11:26:52 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AD80CAB0DE for ; Tue, 24 Jan 2023 16:26:51 +0000 (UTC) X-FDA: 80390221422.27.F78C257 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 5DBA7180010 for ; Tue, 24 Jan 2023 16:26:49 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ft4y85zM; spf=pass (imf16.hostedemail.com: domain of david@redhat.com designates 170.10.133.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=1674577609; 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=i7Pw8HLyonCZeA68egrmyo7nTJgPIzxf4MWuoam80Xs=; b=RAMHpcUuL4YUNIOJDZzTLjalcTD9ukP6vSAHvw7LNbWzkktYSwUvSGwtNI0C2bHyBPETlI ezf5bNvJiMA/i+NfsuAv6x4608g0r+8VddC51rsD6uQlVm9j55xx+udaPxrqw8E5wr7y/I liXppnnft6IW3J7WB4g3RcjvfFtJBus= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ft4y85zM; spf=pass (imf16.hostedemail.com: domain of david@redhat.com designates 170.10.133.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=1674577609; a=rsa-sha256; cv=none; b=pf4Dn+XcCnnkHK/+Jt5PCHmejdoy8EkdCRIoOra0yxoBGFK1Jmck8jOb28r/c9yEl7hzUP f25c0TJ2+yOFQstUvpJeStknCYUmPhY5bd+4BvbejN/GjEfp3tIaubBdyxiv4UAuCsb8F2 OBQZbBLSlUdlkieNzQwnUcfO26BJRos= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674577608; 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=i7Pw8HLyonCZeA68egrmyo7nTJgPIzxf4MWuoam80Xs=; b=Ft4y85zMq2WhjpISQQYHr3FkOgjqBXSoX+O0ExdeDbBjV1k4tg6VU1Doj7E/xYlptJvoO3 yPgHE4pXXomlPTCvVHW2RV+0rgeRMCkG+QuQuluXpnrcBammWSuxjkw66dpqoWAaD+nOtD 7cvOkjzg04LTorkn4lunz7m1dFthmqY= 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-88-9CDzKPytOd27XUCFzMCzKw-1; Tue, 24 Jan 2023 11:26:47 -0500 X-MC-Unique: 9CDzKPytOd27XUCFzMCzKw-1 Received: by mail-wm1-f72.google.com with SMTP id bg25-20020a05600c3c9900b003da1f6a7b2dso11456797wmb.1 for ; Tue, 24 Jan 2023 08:26:47 -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=i7Pw8HLyonCZeA68egrmyo7nTJgPIzxf4MWuoam80Xs=; b=lLrNvdDASBQWWJFvvqh6he3Ngm43ABnjRDwYq4mpk+OHfgZeFjEhqr95D5/UUDkiXY jW4hHTV6VmGiyqwMShXLCKvrcGQroqxEeE3lBHOmr8EqyW4mxbclB85eMtX+rHYCQKdH NF7LO/p04z5fBtH/hcKMrpZLo1C9Rx/oG+StX/g5o/lgbiorJCpcrMuES3Zc45metZyP /6x4BsrUm25Um4DgAim1hoE9b07hvl9UjUhQgLYfi82cUjpYZPd1JGZvsZXzeABsTdnN nUf6a8CAh3297cLYMrzcTVhhLTzYS3qRlPQTrpDB0uOsfJyBZmtHO0mUzym8eZeJleum tfQg== X-Gm-Message-State: AFqh2krOu9C31C7E0+9wLl59LNJ5NGmEEqIVSUV3cp2VPJn32HGAOVAW CsqbQ/5/vIX/S9EB+uvrWMoshfyR35CMEN0zoZpMSC0UeD5j2Fb/L5K1sdiAQAVMiyuV58Jkzbz H+RCIMw536zw= X-Received: by 2002:a05:6000:10c6:b0:2bd:e33e:c04b with SMTP id b6-20020a05600010c600b002bde33ec04bmr23891379wrx.22.1674577606152; Tue, 24 Jan 2023 08:26:46 -0800 (PST) X-Google-Smtp-Source: AMrXdXtQ9TD2bnXMPy82nhP127kncrzx3y56M6S5Ht8LsvTwDvmKsGRFx5R/aF94Ts9iBIA/bwn/sg== X-Received: by 2002:a05:6000:10c6:b0:2bd:e33e:c04b with SMTP id b6-20020a05600010c600b002bde33ec04bmr23891359wrx.22.1674577605843; Tue, 24 Jan 2023 08:26:45 -0800 (PST) Received: from ?IPV6:2003:cb:c707:9d00:9303:90ce:6dcb:2bc9? (p200300cbc7079d00930390ce6dcb2bc9.dip0.t-ipconnect.de. [2003:cb:c707:9d00:9303:90ce:6dcb:2bc9]) by smtp.gmail.com with ESMTPSA id t16-20020a5d49d0000000b002bfb0c5527esm1691618wrs.109.2023.01.24.08.26.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Jan 2023 08:26:45 -0800 (PST) Message-ID: Date: Tue, 24 Jan 2023 17:26:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH v5 23/39] mm: Don't allow write GUPs to shadow stack memory To: "Edgecombe, Rick P" , "fweimer@redhat.com" Cc: "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "dave.hansen@linux.intel.com" , "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "linux-mm@kvack.org" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "bp@alien8.de" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "pavel@ucw.cz" , "Lutomirski, Andy" , "linux-doc@vger.kernel.org" , "arnd@arndb.de" , "tglx@linutronix.de" , "Schimpe, Christina" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "Yang, Weijiang" , "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" References: <20230119212317.8324-1-rick.p.edgecombe@intel.com> <20230119212317.8324-24-rick.p.edgecombe@intel.com> <87fsc1il73.fsf@oldenburg.str.redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: 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: rspam05 X-Rspamd-Queue-Id: 5DBA7180010 X-Stat-Signature: qmt3jyg7734sz96rtkwgpxe167dkze6e X-Rspam-User: X-HE-Tag: 1674577609-768458 X-HE-Meta: U2FsdGVkX18bpX0vJNcKQJGoB3zwUztzHI1765h/nwOAOL6oQFvGhmM+OfBTpocQXpL8u+ZEhnkkCM91Bzg8Yh9EsZV/QchF98V1lPrUViO5sh5Xwvxmj/J2bURQII0A6YfMOlTVb5Gade3op+46JRbqz3pSF4eaH35s3xyx1v2dMOaTOAuORqpmz8N2N4ZEtL0NkaX0AIg0QeCD1EJatT0CdfVDTSvls4f0PPmlvcmJEmr/U1gtYNqH/dX5IztouA2sg/aQ6AFUyeq0Qo2U4So7tmeDX30m1HGutkuWua+5x3UxWTHtwrnn5wbI+Vbgu5yflkjfvqs8DQCr7bfyPfcNw8f4oAsiwI8fdx5yUjSqx1T2Qb9deRm1ShK/9qrbo59sOERDj4ZxMIvDw97U3h0PVSEoILtymnt1s7+5kxuH8fzdM8HoKdiTC77sgmDgRZB8gbYG5K1K0QEfAEu80/84/2Gc8fhgXawcnCmPxeubb+tTn0jwT/uXBUXRr44oCY+Bd2Qb4mKeDi1mFmxXThKH1v6oLGCpp3JRJKPWOIbhMFQmFrCwrUpc/PYgMHeTj+PFpLkDvPBIiVDxpxFFiKg+vyfa0E9XRXpjiyBi3gFIrkKN8S7uv9OtkhEEnRksV69JDvl5TdwCs32pVYKSvM9j+F2oLUPPUs/GGRsU6Xr0pLIZmEpB/qmuwekSC2NCsrr4TMKdtcKmt56+5HPOWrr+9lGz15v5YFwmx+ebmnAhgxdpEkfe8HkdtReQ7JbdnOxzN5CYbvIGLr4P/QhYASwU/WXFyITCsQi4wt2mWTFbTDUh/NCqL6hVxVwLeVXMb/rLxrdZHlcAY+g9VhtLbjxaqvtGh4HoulNRGO8bg4nAAasg3RU0QnH0q+rit5qN1Dy0puq1IMOdTNWClB2GvM09ijdFCUGZRcj43nG+ocP+L4yuZ7fP6DsFh7O9UOT7pDAAA0iGiSAoBx/ze8e T5IKH2w6 nBcwZQ4uNVPQl6G2wuMb2rTciJXHRYHjJTUNma0Q/kCbdY6fA1LV+AlU+ZibdU8W96KWlXPq+PZSKSee0SBjlYrEY8qNgX+Oy9hyqDxaHs7LqjmZWjqODm1pc8Y66M6AuWAiay0KATbDHjcCTlj4lr32rmMxdSRFjNXmK5JnB9LTSHmPEuxGpR8PtrDB+HdUwFpyzixrdNrBd62P7w68uhMEyMQ7jB69ZP1p4fAFi1Gy4jC1DTKGbyIwCqUNYfRfuBksUge9k7q9wQ/LRjjqjiZzqUbD5yWRwCO3/rhT4rWIwlM24+ZazGuvMugkW6xQK4Ej/LEESAnlAAnrAZG8zDLka2uMGhN577dpzkHtTG7dMoHkWWdZ35l+Sb9nOj0rjOGPpoXtacNmBgY8bGnIhQevSK5J4gSxflt14sO8L4VNBmzLs2jxGHSp4HZ0jTgZrm3ppRC7D/Mqj2ONXjQ6D+mDxQMGa46LYa3Z9TXLJEmY457IR+eEBNlGIDKyI6ixCpD+Q 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 23.01.23 21:46, Edgecombe, Rick P wrote: > On Mon, 2023-01-23 at 11:45 +0100, Florian Weimer wrote: >> * 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. > > There was some debate on this. /proc/self/mem can currently write > through read-only memory which protects executable code. So should > shadow stack get separate rules? Is ROP a worry when you can overwrite > executable code? > The question is, if there is reasonable debugging reason to keep it. I assume if a debugger would adjust the ordinary stack, it would have to adjust the shadow stack as well (oh my ...). So it sounds reasonable to have it in theory at least ... not sure when debugger would support that, but maybe they already do. > The consensus seemed to lean towards not making special rules for this > case, and there was some discussion that /proc/self/mem should maybe be > hardened generally. I agree with that. It's a debugging mechanism that a process can abuse to do nasty stuff to its memory that it maybe shouldn't be able to do ... -- Thanks, David / dhildenb