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 3EE8DC677F1 for ; Thu, 23 Feb 2023 12:56:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 779836B0071; Thu, 23 Feb 2023 07:56:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 728C16B0073; Thu, 23 Feb 2023 07:56:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C98D6B0074; Thu, 23 Feb 2023 07:56:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4DCFD6B0071 for ; Thu, 23 Feb 2023 07:56:04 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1643E1403A0 for ; Thu, 23 Feb 2023 12:56:04 +0000 (UTC) X-FDA: 80498554248.14.2F4E29A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf03.hostedemail.com (Postfix) with ESMTP id 1348020015 for ; Thu, 23 Feb 2023 12:56:00 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bJQ4O+sQ; spf=pass (imf03.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=1677156961; 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=PT6kgDTp7/GY4ysTzhnQOlEbU8Ib9XDdtbwXVzEvIDI=; b=jGZrcQx+os/yW/lr8IG0UZLIj5WD7sECOi6QlrLwONU9kVo7SwRZXM6BhOskccNwz3XGKQ v8D0S3bFVI87s9pcN4/vD0mpXw46fvQbIFYYDJ9UK5ilzTAtFlENzi93g1u0e/i9RC4emV Vw47s7NF+XSmDDRwdu/0PjHMZnHwPKA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bJQ4O+sQ; spf=pass (imf03.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=1677156961; a=rsa-sha256; cv=none; b=scF1K4AbvKyBSL7il2HiJbAzp1m8uonaZOpYdu4kH6K076B5oyGXOGnkpsXbBMn9HJ76Ag x/lQi44SzNc9iuhY0gskiBUHkgBOx871UoG5Oj7MrCHNV2OfGHUzHw3sQ3gwSBVmVyPedi sZvioPp56+xhpUO1tfSpHerlZgVNIPQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677156960; 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=PT6kgDTp7/GY4ysTzhnQOlEbU8Ib9XDdtbwXVzEvIDI=; b=bJQ4O+sQNW+tygC7jqyF77mFM4QbhSQ99yW7/FlLGe7KVnoEIABMKLiXUbVTQtTyjB2+16 Aeikl3nfOyxBL9Wkd5X7tdaYCg6BGC+HtGAB55H8X+Lwjgeq2KXGldkQ8GknQ77aza54Fw NtEp1pH+ECHxKZEBLSjvug/Q9eSvjRQ= 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-145-EOKNsTbSMuu-P11gGz0AVQ-1; Thu, 23 Feb 2023 07:55:51 -0500 X-MC-Unique: EOKNsTbSMuu-P11gGz0AVQ-1 Received: by mail-wr1-f69.google.com with SMTP id v18-20020adfedd2000000b002c3f0a93825so2557964wro.15 for ; Thu, 23 Feb 2023 04:55:51 -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=PT6kgDTp7/GY4ysTzhnQOlEbU8Ib9XDdtbwXVzEvIDI=; b=lefJrykzpmJRojYCvMajXS3YQTUMOZm1/QjrwygwOp9gnORFLltZ0XLxWlakgAtvsc /5a1OT4cBuIg87NwdM+2BT3vjp6xqM9cWcwJ4r2nGf/uzSaW/T4Bbm70LVRi/v+5M6h6 0NbA1N5VxwJl/g9MuFlb266ba5EPDqXqEsTmT3/hHht6kp6XKLAQdPqQj/kpqKK12orW zh7pYRGrW/bAq3+YfUGI1t0KGtLtpJpY+gqUh+8VfGgWe9b57NXSM6gqx61myT4Wc1+G Fm0oFIrREUtk7Q3zayad9QXbQR0SCv6ZDvMoztbZ7Jpl7UG2D3oRnXcHoNl3WwjhS/GY W5bg== X-Gm-Message-State: AO0yUKX6hLL2y57abzfQJkdxcmfcHIy+fE7A5MeWlaZrw7G0Kdrqf96+ YWoD6DjQxgFJHHG/QEpo4kYvQ7NkZV1vulzEQyKYYlvgZ8fqK9OiePwTCr2TSjE3kzhG73JekFa vedVz02vQNn0= X-Received: by 2002:a05:600c:13d4:b0:3ea:dbdd:66e1 with SMTP id e20-20020a05600c13d400b003eadbdd66e1mr129178wmg.28.1677156950092; Thu, 23 Feb 2023 04:55:50 -0800 (PST) X-Google-Smtp-Source: AK7set+z4Zckn4kGh4RDzbT5i3WSb5X8+Y/ga4x3DBVsKlX44yNblYKhzFO6jE19EiwrBNHiOOrHYg== X-Received: by 2002:a05:600c:13d4:b0:3ea:dbdd:66e1 with SMTP id e20-20020a05600c13d400b003eadbdd66e1mr129131wmg.28.1677156949645; Thu, 23 Feb 2023 04:55:49 -0800 (PST) Received: from ?IPV6:2a09:80c0:192:0:5dac:bf3d:c41:c3e7? ([2a09:80c0:192:0:5dac:bf3d:c41:c3e7]) by smtp.gmail.com with ESMTPSA id m3-20020a05600c4f4300b003df5be8987esm4390794wmq.20.2023.02.23.04.55.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Feb 2023 04:55:49 -0800 (PST) Message-ID: <2905adaa-97f8-912d-5d23-bee92eb4483e@redhat.com> Date: Thu, 23 Feb 2023 13:55:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 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-20-rick.p.edgecombe@intel.com> <458b3d39-ddce-c0f2-fe80-4e0cc5b101bd@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v6 19/41] x86/mm: Check shadow stack page fault errors 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-Queue-Id: 1348020015 X-Stat-Signature: esuijcj568cdnhegnxjmrzoidcnuo5ce X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1677156960-207365 X-HE-Meta: U2FsdGVkX1+3oMuzg2rLMsC022gANt6uwkR+SODLdsEUxwQepckQQ3L+CDM49YjlJ8nDa4vKcbjkc6S8HfdrQOz7sLuaY513/nVLRr6He9tY/Uz5Oywea5rvAqW+xL0YF9uxAjwtUC2LfjiDMcKaF+d8LlsGPi33+zgET1BW9j9PbaPm6A4OsFDz6UG4idFMz7aeQC/GJVWX2GqwS277gsbdhQxiH+hji6KxgPB0NPDQYxnex/2TLLLtyt4Qj/BM/e4+Qz8ohnRGDElwX4YHk53A3RlUJ3v6pNfLsoDW2ucFkKGow9gUr4y9NQxIKgszwPajYkgRjKp+XpcmpDu+75FIIjtj+JK3/F3fLiGQBINpOY86kg13rc+bchK/zpe1kzNwaWFqxaAYKsW4eCN8mqz5VLGESQCD6UjURSjcbYJcfT/n7F8tdmgnzqDzdydihN3zWgWZgzYJeLSrKFJGjS0uUxoi86MDvFNkuV8/0ZSPpfJBO4ABnF3BxeICAZpGn9DrokOleqZZBZTKpQGTE9eKKgdUD/i0KTS40CRC3yqzx5/1Xa7N6f3f89ePjSjNW7CB7eDprRSUNHym+DHEh/3MvJvOCnFHqcZPTygfQA5vbn4mE4g0x6l9cEWd4ipf+lUbFvDXMzy48iHSkevcx8U5W0FqgqDfsJaoLKU2ZBDVBp+nYB9Ng1A0sgZAHMmS148aCYhgXaO8EdCgDVljHa4CmI0gcVJVYWCzWvEIU8hajgqWO4B6R2izE+SwLxFQZpWNnv91Qocz/oTsXC8CqBpGUpmnhCWwK/os//HoxQghtdB9fiH9sIK0UMUzBggwLhBW8ee2OZmKSJfEGrKi8GniysvCvapuBgnK940uIbGg5syPq+AAr9zjyO94MPN/v22yNK6EfeF9AjenVz3Jnj7Y1hqLIfj2zm4i0v6/8MgFvYNG5sY+Jprp2JudVqZTSCQsXZkn5bTu7R18opj WpwgvpQ+ uIa4laY1bJuvLJgIJu3pxYXvQfEIjPk8bJ+G1bzL0Sj0yljATS+7etsgqFIhkyyNecja7TadOASlz+K/kpzt/wKeVvWaeM+0BVvRmw4k5ssZWg6kPlsIIsgadN3jHUQtjLcx5hAjjoUEPGcttIpSfDk4XDCSynOuwJJIUrnSMwPMBu+BRIECOVaHM213/ozzesD4yoMo5soaPe3mhobSwUlfhhg1gImCP6dOysRSerXedBqp5acJaipk3b8kyfK5Ci9Jck7TVnR4ykYzpZOSKpAGyEnaOitaTPtLDLTJLcLI45w3x1ERKyXh7Ru3DpAlLpLW5V9IcwXUkEUZ1Wq8iTz929+nEfrhY7WU64IOzG8REyA+ATy5UKBYV97B6SWUmirujOIcPMJ9DEgw+0nija8cMtDw14hrVH0F2 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.02.23 00:07, Edgecombe, Rick P wrote: > On Mon, 2023-02-20 at 13:57 +0100, David Hildenbrand wrote: >>> >>> + /* >>> + * When a page becomes COW it changes from a shadow stack >>> permission >>> + * page (Write=0,Dirty=1) to (Write=0,Dirty=0,SavedDirty=1), >>> which is simply >>> + * read-only to the CPU. When shadow stack is enabled, a RET >>> would >>> + * normally pop the shadow stack by reading it with a "shadow >>> stack >>> + * read" access. However, in the COW case the shadow stack >>> memory does >>> + * not have shadow stack permissions, it is read-only. So it >>> will >>> + * generate a fault. >>> + * >>> + * For conventionally writable pages, a read can be serviced >>> with a >>> + * read only PTE, and COW would not have to happen. But for >>> shadow >>> + * stack, there isn't the concept of read-only shadow stack >>> memory. >>> + * If it is shadow stack permission, it can be modified via >>> CALL and >>> + * RET instructions. So COW needs to happen before any memory >>> can be >>> + * mapped with shadow stack permissions. >>> + * >>> + * Shadow stack accesses (read or write) need to be serviced >>> with >>> + * shadow stack permission memory, so in the case of a shadow >>> stack >>> + * read access, treat it as a WRITE fault so both COW will >>> happen and >>> + * the write fault path will tickle maybe_mkwrite() and map >>> the memory >>> + * shadow stack. >>> + */ >> >> Again, I suggest dropping all details about COW from this comment >> and >> from the patch description. It's just one such case that can happen. > > Hi David, Hi Rick, > > I was just trying to edit this one to drop COW details, but I think in > this case, one of the major reasons for the code *is* actually COW. We > are not working around the whole inadvertent shadow stack memory piece > here, but something else: Making sure shadow stack memory is faulted in > and doing COW if required to make this possible. I came up with this, > does it seem better? Regarding the fault handling I completely agree. We have to treat a read like a write event. And as read-only shadow stack PTEs don't exist, we have to tell the MM to create a writable one for us. > > > /* > * For conventionally writable pages, a read can be serviced with a > * > read only PTE. But for shadow stack, there isn't a concept of > * read- > only shadow stack memory. If it a PTE has the shadow stack > * > permission, it can be modified via CALL and RET instructions. So > * core > MM needs to fault in a writable PTE and do things it already > * does for > write faults. > * > * Shadow stack accesses (read or write) need to be > serviced with > * shadow stack permission memory, so in the case of a > shadow stack > * read access, treat it as a WRITE fault so both any > required COW will > * happen and the write fault path will tickle > maybe_mkwrite() and map > * the memory shadow stack. > */ That sounds good! I'd rewrite the last part slightly. " Shadow stack accesses (read or write) need to be serviced with shadow stack permission memory, which always include write permissions. So in the case of a shadow stack read access, treat it as a WRITE fault. This will make sure that MM will prepare everything (e.g., break COW) such that maybe_mkwrite() can create a proper shadow stack PTE. " -- Thanks, David / dhildenb