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 83774C433FE for ; Mon, 3 Oct 2022 16:26:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 157828E0002; Mon, 3 Oct 2022 12:26:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 12FC86B0073; Mon, 3 Oct 2022 12:26:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F38368E0002; Mon, 3 Oct 2022 12:26:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DEA626B0071 for ; Mon, 3 Oct 2022 12:26:26 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AEE87140DB8 for ; Mon, 3 Oct 2022 16:26:26 +0000 (UTC) X-FDA: 79980165972.24.42B3FD2 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf21.hostedemail.com (Postfix) with ESMTP id 917051C000E for ; Mon, 3 Oct 2022 16:26:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664814385; x=1696350385; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=swCjk5aBIHIQCZtdbrAcSo1PiTWyf4fjhzdNzOBH0No=; b=ZPEz/9bPIbj/2ux+vc+WUTAFeEAHFnqnS/YIOc7006Bfydr2/FQzk3VK +rsTgwnCy40NEvP3c1xHmQeHGPu7hXwd1MoAbKLBnCOA3g9GAmUvLzXXN Zhh2IIVupcGn5+/nKhKxEfihkqHAx4NNHj6yZ6ZmHHBdj7vVmXABlz1/i FBd9xnOswsnnYXfX6SoIX31DBFdBmQO2m8CLpSc+ToiWwWVit58H/ZDft zCgJuDJLftdr8lCI+k9brtYKTSSjAnB+hhC9P27+yB1ibg4YFydK0w57I gmRxjdY0AQnP296jRsYvgjkpgRRuSgMWRmwjAVeiXopUr2TBehy2A/tAc Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10489"; a="300284621" X-IronPort-AV: E=Sophos;i="5.93,365,1654585200"; d="scan'208";a="300284621" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Oct 2022 09:26:24 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10489"; a="692126892" X-IronPort-AV: E=Sophos;i="5.93,365,1654585200"; d="scan'208";a="692126892" Received: from bandrei-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.37.219]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Oct 2022 09:26:16 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id C4D61104CE4; Mon, 3 Oct 2022 19:26:13 +0300 (+03) Date: Mon, 3 Oct 2022 19:26:13 +0300 From: "Kirill A . Shutemov" To: Rick Edgecombe Cc: 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 , "Ravi V . Shankar" , Weijiang Yang , joao.moreira@intel.com, John Allen , kcc@google.com, eranian@google.com, rppt@kernel.org, jamorris@linux.microsoft.com, dethoma@microsoft.com, Yu-cheng Yu Subject: Re: [PATCH v2 10/39] x86/mm: Introduce _PAGE_COW Message-ID: <20221003162613.2yvhvb6hmnae2awz@box.shutemov.name> References: <20220929222936.14584-1-rick.p.edgecombe@intel.com> <20220929222936.14584-11-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220929222936.14584-11-rick.p.edgecombe@intel.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664814386; 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=9bd40HLvUxV3U45Q1UofSmhTPdApqg2xa4krxWUi/0M=; b=qC2Bms+LjPE8BjNu+2V7SJti+RL9KpfdA8w79Pcv/suD3G8pZfl7t0hNKjSEgYoMkFisac BqnHqG3DdnUFPwE4OictC5YmbX+RLXqnCA8WUozWORqNlbkFNYIH5QzTu7u0ef/fm48Wf9 bdtS7QhRFJ533ptSOxQPvh7mXjxLpvA= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="ZPEz/9bP"; spf=none (imf21.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664814386; a=rsa-sha256; cv=none; b=jlYZSSmBtCGlVHHR4uIDiGx6VCcltOk0ljvWfQkBqZp7HfdTHCjFtxKSETAoiwqOSmYPGg 3p7crJOksEnUGSM6slRGGzbTMQOBRQ5KQmwOMboZ2w8/XXq/xQRf6exRut5CdEXru80vhO KKskkKwoOuOXSKKqgyc50eclaOnha2s= X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="ZPEz/9bP"; spf=none (imf21.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 917051C000E X-Stat-Signature: mezxdatwqdgkykeicj341cpo6ze7gfa7 X-HE-Tag: 1664814385-876945 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 Thu, Sep 29, 2022 at 03:29:07PM -0700, Rick Edgecombe wrote: > +/* > + * Normally the Dirty bit is used to denote COW memory on x86. But > + * in the case of X86_FEATURE_SHSTK, the software COW bit is used, > + * since the Dirty=1,Write=0 will result in the memory being treated > + * as shaodw stack by the HW. So when creating COW memory, a software > + * bit is used _PAGE_BIT_COW. The following functions pte_mkcow() and > + * pte_clear_cow() take a PTE marked conventially COW (Dirty=1) and > + * transition it to the shadow stack compatible version of COW (Cow=1). > + */ > + > +static inline pte_t pte_mkcow(pte_t pte) > +{ > + if (!cpu_feature_enabled(X86_FEATURE_SHSTK)) > + return pte; > + > + pte = pte_clear_flags(pte, _PAGE_DIRTY); > + return pte_set_flags(pte, _PAGE_COW); > +} > + > +static inline pte_t pte_clear_cow(pte_t pte) > +{ > + /* > + * _PAGE_COW is unnecessary on !X86_FEATURE_SHSTK kernels. > + * See the _PAGE_COW definition for more details. > + */ > + if (!cpu_feature_enabled(X86_FEATURE_SHSTK)) > + return pte; > + > + /* > + * PTE is getting copied-on-write, so it will be dirtied > + * if writable, or made shadow stack if shadow stack and > + * being copied on access. Set they dirty bit for both > + * cases. > + */ > + pte = pte_set_flags(pte, _PAGE_DIRTY); > + return pte_clear_flags(pte, _PAGE_COW); > +} These X86_FEATURE_SHSTK checks make me uneasy. Maybe use the _PAGE_COW logic for all machines with 64-bit entries. It will get you much more coverage and more universal rules. > + > #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP > static inline int pte_uffd_wp(pte_t pte) > { > @@ -319,7 +381,7 @@ static inline pte_t pte_clear_uffd_wp(pte_t pte) > > static inline pte_t pte_mkclean(pte_t pte) > { > - return pte_clear_flags(pte, _PAGE_DIRTY); > + return pte_clear_flags(pte, _PAGE_DIRTY_BITS); > } > > static inline pte_t pte_mkold(pte_t pte) > @@ -329,7 +391,16 @@ static inline pte_t pte_mkold(pte_t pte) > > static inline pte_t pte_wrprotect(pte_t pte) > { > - return pte_clear_flags(pte, _PAGE_RW); > + pte = pte_clear_flags(pte, _PAGE_RW); > + > + /* > + * Blindly clearing _PAGE_RW might accidentally create > + * a shadow stack PTE (Write=0,Dirty=1). Move the hardware > + * dirty value to the software bit. > + */ > + if (pte_dirty(pte)) > + pte = pte_mkcow(pte); > + return pte; > } Hm. What about ptep/pmdp_set_wrprotect()? They clear _PAGE_RW blindly. -- Kiryl Shutsemau / Kirill A. Shutemov