Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp158430imm; Tue, 17 Jul 2018 16:05:13 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeF90sAAqVtqCazhEPWEl9UI0ACdDMIQeLGyZY9ut70GcCE9KoHf9QR95rTQVDd3z/1/AF4 X-Received: by 2002:a63:f309:: with SMTP id l9-v6mr3315046pgh.369.1531868713022; Tue, 17 Jul 2018 16:05:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531868712; cv=none; d=google.com; s=arc-20160816; b=eL0cckhOVVF7HBKB4fVyvgW2psF0ky1xsQVYbGahZLxJw6a2+VpuQS9HRUqoY0kTBG +LtkUD55qMTs5h4OHd7gEFpB8t3JFn7InorUY1UaQeNM/IDeuP8kh834MauSagJ70lNY 7hHjG+8ycZhNpawNEyJpu8wej3DBcfdf493tgb9fuv3ghxGLtT2J1vulLN5mB6/DilGi N37ZD/9cGaFaNHjgu6hANt5Khshc3M0uUZqpcD4+vyjEKB/kJw85igkINXXjyq6V+ZjJ 5yz6JxH5HLPbl1R+vGkf4h4Hx76ohW3W+Bu95iEmfFDDsIfc+0A0FcQTCqb284EVI3Hn ObKQ== 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 :arc-authentication-results; bh=Q1LNbGIV4d6SgYM15spEyNdmvzmMZWRLiJHMSjpADl0=; b=sSBUTuAVvFLsZhG5MEuC/+sqCkNPZlRe0G0WJqtq26y4A/0c53UaSuwCb1pE5TBg3W Fw1+qOY7XnNNn4t0Iz4WWLSSivAFlNENJB+uFz+PX7MfGwtXU6wjcCZd/xSxoZK5ldcH oJssVnflE3WoLePrmYKWuHVgcsx+ZmTcH+2qfDvfu6kC4CECRtUIKJjjdWgeS5teahqY Qsof0koWh0huFIkkmtOfCrIpgV1cBQjy8Mi2FRp/DlmeMVHD1Lz5vMeWXx7FdNOJIA5z vvI7LsdkegUAGydSBY9kWYFMb/pEEnf/PWzVm7UBdIizXE1LdSF325/5hKSJJHE8lgiO W3Bg== 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 t18-v6si1720918plo.163.2018.07.17.16.04.56; Tue, 17 Jul 2018 16:05:12 -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 S1730731AbeGQXjP (ORCPT + 99 others); Tue, 17 Jul 2018 19:39:15 -0400 Received: from mga17.intel.com ([192.55.52.151]:34308 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730055AbeGQXjP (ORCPT ); Tue, 17 Jul 2018 19:39:15 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 16:04:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,367,1526367600"; d="scan'208";a="73200020" Received: from 2b52.sc.intel.com ([143.183.136.146]) by fmsmga001.fm.intel.com with ESMTP; 17 Jul 2018 16:04:22 -0700 Message-ID: <1531868435.3541.18.camel@intel.com> Subject: Re: [RFC PATCH v2 16/27] mm: Modify can_follow_write_pte/pmd for shadow stack From: Yu-cheng Yu To: Peter Zijlstra 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 , Cyrill Gorcunov , Dave Hansen , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , "Ravi V. Shankar" , Vedvyas Shanbhogue Date: Tue, 17 Jul 2018 16:00:35 -0700 In-Reply-To: <20180711092951.GW2476@hirez.programming.kicks-ass.net> References: <20180710222639.8241-1-yu-cheng.yu@intel.com> <20180710222639.8241-17-yu-cheng.yu@intel.com> <20180711092951.GW2476@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 Wed, 2018-07-11 at 11:29 +0200, Peter Zijlstra wrote: > On Tue, Jul 10, 2018 at 03:26:28PM -0700, Yu-cheng Yu wrote: > > > > There are three possible shadow stack PTE settings: > > > >   Normal SHSTK PTE: (R/O + DIRTY_HW) > >   SHSTK PTE COW'ed: (R/O + DIRTY_HW) > >   SHSTK PTE shared as R/O data: (R/O + DIRTY_SW) > I count _2_ distinct states there. > > > > > Update can_follow_write_pte/pmd for the shadow stack. > So the below disallows can_follow_write when shstk && _PAGE_DIRTY_SW, > but this here Changelog doesn't explain why. Doesn't even get close. Can we add the following to the log: When a SHSTK PTE is shared, it is (R/O + DIRTY_SW); otherwise it is (R/O + DIRTY_HW). When we (FOLL_WRITE | FOLL_FORCE) on a SHSTK PTE, the following must be true:   - It has been COW'ed at least once (FOLL_COW is set);   - It still is not shared, i.e. PTE is (R/O + DIRTY_HW); > > Also, the code is a right mess :/ Can't we try harder to not let this > shadow stack stuff escape arch code. We either check here if the VMA is SHSTK mapping or move the logic to pte_dirty().  The latter would be less obvious.  Or can we create a can_follow_write_shstk_pte()? Yu-cheng