Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1236213imm; Fri, 14 Sep 2018 13:43:53 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYj3KQgjdi5qM3B7rXPl3CJi+MYpZBgofdhkF6J3j2IQ2B/WNsKcJauPE9HIi0bcjpYOSsE X-Received: by 2002:aa7:881a:: with SMTP id c26-v6mr2980012pfo.82.1536957833635; Fri, 14 Sep 2018 13:43:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536957833; cv=none; d=google.com; s=arc-20160816; b=OzulvTqEFMdWpft8RRjEohQROAcen4Wl9yz9rmBL4El08hwLvqFiZls4P9KKWN24hj +0bKap/Jwmc1lO8KZemU6DDLt5svU76ZRr9J5XPbMOBcXMszNSr0DSbDnfjFnWayQpt1 d87Q/o2K8iVfgd5hooyaqYX6dmnalZ7LsQtEfb8NjMayCuaL2FISwL2sHBVn8EDLQ2lj p8kioWOLNGo8A8f/tnxPmLJ8i6fBfkvKSmhO2XzC3/ft9m1rGZRG6WzlXsnUxhuEsyQi fQhbxwnQmyrCiiCl9obBv2SZsiHyOtN832THwLq83TcHdWxkYCM9YSy83TII8yUuPsJs 9JqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=j8jauz5O3VxkeBwk9Ov7Ry0lSdGTUrZ8aFUR8W4HRK4=; b=E8ifLvac1IJGPYBpAQfRbcTowG0KNAkgA1kf1HiTld3PgptXtCsfCxyY99H0wOeXoz 60XJZs4Hm9nrk61uBS4KfjJEH/d7pv9D0p7GP95SXrhbqbSPCcp5ieNIQIcVkKo0fibe +qNtjY2uJdLPk+xPOxaKUdlqIN1DG7ipQwuMWAGYePF915JCriiovdIU5J3s3ytVqfVy eLeGSMJCOYD/8zqzVthkgE+W/RtK9NAPHRtQLT1Yvh5fMjcF8z8+puI1WSiJBV+8JbGk txxEycw8KlJI5JctxPxzQJF1q0/CmhWJHcNNBFBQDMx8VROfveXp9YAY5FxVOo9R2lbt HuiA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 7-v6si8010004pgq.637.2018.09.14.13.43.37; Fri, 14 Sep 2018 13:43:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727865AbeIOB7j (ORCPT + 99 others); Fri, 14 Sep 2018 21:59:39 -0400 Received: from mga06.intel.com ([134.134.136.31]:8694 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727128AbeIOB7j (ORCPT ); Fri, 14 Sep 2018 21:59:39 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2018 13:43:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,374,1531810800"; d="scan'208";a="70937186" Received: from 2b52.sc.intel.com ([143.183.136.51]) by fmsmga008.fm.intel.com with ESMTP; 14 Sep 2018 13:43:32 -0700 Message-ID: <1536957543.12990.9.camel@intel.com> Subject: Re: [RFC PATCH v3 12/24] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW From: Yu-cheng Yu To: Peter Zijlstra , Dave Hansen Cc: Jann Horn , the arch/x86 maintainers , "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , kernel list , linux-doc@vger.kernel.org, Linux-MM , linux-arch , Linux API , Arnd Bergmann , Andy Lutomirski , Balbir Singh , Cyrill Gorcunov , Florian Weimer , hjl.tools@gmail.com, Jonathan Corbet , keescook@chromium.org, Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , ravi.v.shankar@intel.com, vedvyas.shanbhogue@intel.com Date: Fri, 14 Sep 2018 13:39:03 -0700 In-Reply-To: <20180831162920.GQ24124@hirez.programming.kicks-ass.net> References: <1535660494.28258.36.camel@intel.com> <1535662366.28781.6.camel@intel.com> <20180831095300.GF24124@hirez.programming.kicks-ass.net> <1535726032.32537.0.camel@intel.com> <1535730524.501.13.camel@intel.com> <6d31bd30-6d5b-bbde-1e97-1d8255eff76d@linux.intel.com> <20180831162920.GQ24124@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-08-31 at 18:29 +0200, Peter Zijlstra wrote: > On Fri, Aug 31, 2018 at 08:58:39AM -0700, Dave Hansen wrote: > > > > On 08/31/2018 08:48 AM, Yu-cheng Yu wrote: > > > > > > To trigger a race in ptep_set_wrprotect(), we need to fork from one of > > > three pthread siblings. > > > > > > Or do we measure only how much this affects fork? > > > If there is no racing, the effect should be minimal. > > We don't need a race. > > > > I think the cmpxchg will be slower, even without a race, than the code > > that was there before.  The cmpxchg is a simple, straightforward > > solution, but we're putting it in place of a plain memory write, which > > is suboptimal. > Note quite, the clear_bit() is LOCK prefixed. With the updated ptep_set_wrprotect() below, I did MADV_WILLNEED to a shadow stack of 8 MB, then 10,000 fork()'s, but could not prove it is more or less efficient than the other.  So can we say this is probably fine in terms of efficiency? Yu-cheng --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -1203,7 +1203,36 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,  static inline void ptep_set_wrprotect(struct mm_struct *mm,         unsigned long addr, pte_t *ptep)  { +#ifdef CONFIG_X86_INTEL_SHADOW_STACK_USER + pte_t new_pte, pte = READ_ONCE(*ptep); + + /* +  * Some processors can start a write, but end up +  * seeing a read-only PTE by the time they get +  * to the Dirty bit.  In this case, they will +  * set the Dirty bit, leaving a read-only, Dirty +  * PTE which looks like a Shadow Stack PTE. +  * +  * However, this behavior has been improved and +  * will not occur on processors supporting +  * Shadow Stacks.  Without this guarantee, a +  * transition to a non-present PTE and flush the +  * TLB would be needed. +  * +  * When changing a writable PTE to read-only and +  * if the PTE has _PAGE_DIRTY_HW set, we move +  * that bit to _PAGE_DIRTY_SW so that the PTE is +  * not a valid Shadow Stack PTE. +  */ + do { + new_pte = pte_wrprotect(pte); + new_pte.pte |= (new_pte.pte & _PAGE_DIRTY_HW) >> + _PAGE_BIT_DIRTY_HW << _PAGE_BIT_DIRTY_SW; + new_pte.pte &= ~_PAGE_DIRTY_HW; + } while (!try_cmpxchg(ptep, &pte, new_pte)); +#else   clear_bit(_PAGE_BIT_RW, (unsigned long *)&ptep->pte); +#endif  }