From patchwork Tue Jul 17 23:03:30 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Yu-cheng Yu X-Patchwork-Id: 10531027 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 989EF600D0 for ; Tue, 17 Jul 2018 23:08:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8A06028D58 for ; Tue, 17 Jul 2018 23:08:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7D4BF2931A; Tue, 17 Jul 2018 23:08:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0D58D28D58 for ; Tue, 17 Jul 2018 23:08:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24D6F6B0006; Tue, 17 Jul 2018 19:08:01 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 201C36B0007; Tue, 17 Jul 2018 19:08:01 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EF336B0008; Tue, 17 Jul 2018 19:08:01 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by kanga.kvack.org (Postfix) with ESMTP id C2BC76B0006 for ; Tue, 17 Jul 2018 19:08:00 -0400 (EDT) Received: by mail-pg1-f200.google.com with SMTP id o16-v6so1033391pgv.21 for ; Tue, 17 Jul 2018 16:08:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:message-id :subject:from:to:date:in-reply-to:references:mime-version :content-transfer-encoding; bh=4Wuvansw6VLrazg2n278RjVAr6BWliEji+cfurp1TRI=; b=T1UrQrrYGORDj/SxeT3jmjtx2dEXSttEqqVc99S1pk4AM3A5U7n5iDIzlArPBXEYd+ taOOph1FXFKDiXT0T6FABmZbVh7IqIjeYyckaX5Bb+6wS1G/bwm84lkyoqKSyuC2s4Vf T/v90tKJzsn7SiVWUQr/pYI2Gz9O6qyDOq4gPcE+P1T328g0Du/B1j79wVqUvxJBxRug csImu70cRgYBQT9Vp2VNqw0WF4W6WErcSIn7yOgTLCkMbz32zsyLF0y2G8eAynuEzvuQ cbFBupUjHpOvRqPe9Z6q1mFuu9LtYBzB0JIsJMkcixlTvpLklrMSzBk5claOCywFtyjL Ccxg== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of yu-cheng.yu@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=yu-cheng.yu@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Gm-Message-State: AOUpUlGRHyYO8eNAb7WI3rtAuscZOiQVhgyp3GImg9kCUnWMXeFfCW62 TKEMIz8qBmRwqoVn8SlMgTPIy/SMlWQl2cnGrDOh15P0mmE87Zbw/N9+HHRrWZRnx4Xhla9oWcB CJwwXi+3J1m6CZ3Anuaq94f2bxgJhtcVaNi0gM/x1tbpCRDMDctHIcKMZsuIM6uAjFw== X-Received: by 2002:a17:902:7c0a:: with SMTP id x10-v6mr3370094pll.77.1531868880476; Tue, 17 Jul 2018 16:08:00 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdGxp/B0T0ZmBzsnChPNaG2Hd6/ObQvt+fhQ4VGAUyxpf4vTXimODC2fmUcef1CkRDMWpnM X-Received: by 2002:a17:902:7c0a:: with SMTP id x10-v6mr3370046pll.77.1531868879680; Tue, 17 Jul 2018 16:07:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531868879; cv=none; d=google.com; s=arc-20160816; b=dpma8pKHIG31uoFdm+TorzbfGswPxJXoJj6csccYsvn6dPKU2aJctauU+u6kOMX+/P qQJUJGy/PklxEPpEC22Wi+JzUzJHVx5mY6lshdh082kAe2zo1U03MOcDcdQFJDY5ys6Z tmHiHqcY+Enw4JwHGSk5hWV4sU5772xlLmrd97jRTdTCh7Ohb51llGVA08eK5WfUTbfC Q9qzTaFrhcT59ogndYZ69WmX704nYJ3D+Pcv9F9MiNEXocFONWUaWWC/54XyJOpvZkIw pJzUpwZdyYQSRjRKsSs7cK/QW/0ekoZGRA26ySVPjIrIzRHV2AMMG2uKYUCxxL4vojZ0 kxXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to:date :to:from:subject:message-id:arc-authentication-results; bh=4Wuvansw6VLrazg2n278RjVAr6BWliEji+cfurp1TRI=; b=cEzyzp3Wm5BXY4jepN7zGg24rIFlmv+VeuamjApfhrGnPflV1HztlIHY+YyRcBkIPD DBDvGgYMdAhR9/3I62bza1Fv4zN+HEI94PNiKWNKq5egUC/Jns2jPYf1U/st7+ys+7Jm CfwMsAgBKHX/HlMkuieUjh9xd3m2guCMgQzcMkzJQLQsK6eJZoPe/EaANjC2rOJ8FRDZ 1+Ocg35vi+m1A+cdn38eBdGJ5f0FjX8sC3iR+ebm3MO+tazt8A4pLA2MMBEYr0ZT4YaQ Xon4HW0AcGNRXsYq4asKV1+49bkKHfJwLmFZi9CJcBl0UAp/qXsiTiUEl7zSGy50wEXU VsPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of yu-cheng.yu@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=yu-cheng.yu@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from mga06.intel.com (mga06.intel.com. [134.134.136.31]) by mx.google.com with ESMTPS id 61-v6si1928232plf.63.2018.07.17.16.07.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 16:07:59 -0700 (PDT) Received-SPF: pass (google.com: domain of yu-cheng.yu@intel.com designates 134.134.136.31 as permitted sender) client-ip=134.134.136.31; Authentication-Results: mx.google.com; spf=pass (google.com: domain of yu-cheng.yu@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=yu-cheng.yu@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 16:07:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,367,1526367600"; d="scan'208";a="75608409" Received: from 2b52.sc.intel.com ([143.183.136.146]) by orsmga002.jf.intel.com with ESMTP; 17 Jul 2018 16:07:18 -0700 Message-ID: <1531868610.3541.21.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: Dave Hansen , 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 , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , "Ravi V. Shankar" , Vedvyas Shanbhogue Date: Tue, 17 Jul 2018 16:03:30 -0700 In-Reply-To: <45a85b01-e005-8cb6-af96-b23ce9b5fca7@linux.intel.com> References: <20180710222639.8241-1-yu-cheng.yu@intel.com> <20180710222639.8241-17-yu-cheng.yu@intel.com> <1531328731.15351.3.camel@intel.com> <45a85b01-e005-8cb6-af96-b23ce9b5fca7@linux.intel.com> X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 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: X-Virus-Scanned: ClamAV using ClamSMTP On Fri, 2018-07-13 at 11:26 -0700, Dave Hansen wrote: > On 07/11/2018 10:05 AM, Yu-cheng Yu wrote: > > > > My understanding is that we don't want to follow write pte if the page > > is shared as read-only.  For a SHSTK page, that is (R/O + DIRTY_SW), > > which means the SHSTK page has not been COW'ed.  Is that right? > Let's look at the code again: > > > > > -static inline bool can_follow_write_pte(pte_t pte, unsigned int flags) > > +static inline bool can_follow_write_pte(pte_t pte, unsigned int flags, > > + bool shstk) > >  { > > + bool pte_cowed = shstk ? is_shstk_pte(pte):pte_dirty(pte); > > + > >   return pte_write(pte) || > > - ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte)); > > + ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_cowed); > >  } > This is another case where the naming of pte_*() is biting us vs. the > perversion of the PTE bits.  The lack of comments and explanation inthe > patch is compounding the confusion. > > We need to find a way to differentiate "someone can write to this PTE" > from "the write bit is set in this PTE". > > In this particular hunk, we need to make it clear that pte_write() is > *never* true for shadowstack PTEs.  In other words, shadow stack VMAs > will (should?) never even *see* a pte_write() PTE. > > I think this is a case where you just need to bite the bullet and > bifurcate can_follow_write_pte().  Just separate the shadowstack and > non-shadowstack parts. In case I don't understand the exact issue. What about the following. diff --git a/mm/gup.c b/mm/gup.c index fc5f98069f4e..45a0837b27f9 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -70,6 +70,12 @@ static inline bool can_follow_write_pte(pte_t pte, unsigned int flags)   ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte));  }   +static inline bool can_follow_write_shstk_pte(pte_t pte, unsigned int flags) +{ + return ((flags & FOLL_FORCE) && (flags & FOLL_COW) && + is_shstk_pte(pte)); +} +  static struct page *follow_page_pte(struct vm_area_struct *vma,   unsigned long address, pmd_t *pmd, unsigned int flags)  { @@ -105,9 +111,16 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,   }   if ((flags & FOLL_NUMA) && pte_protnone(pte))   goto no_page; - if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags)) { - pte_unmap_unlock(ptep, ptl); - return NULL; + if (flags & FOLL_WRITE) { + if (is_shstk_mapping(vma->vm_flags)) { + if (!can_follow_write_shstk_pte(pte, flags)) { + pte_unmap_unlock(ptep, ptl); + return NULL; + } + } else if (!can_follow_write_pte(pte, flags) { + pte_unmap_unlock(ptep, ptl); + return NULL; + }   }     page = vm_normal_page(vma, address, pte);