Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2529063imm; Thu, 7 Jun 2018 12:10:56 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIVECat1gZ+ZgcMyEQnQSghwFcoRavZ7FKK4nLu5Coo3NYVoRwwbsudlDSk/gy4a7GTHkpS X-Received: by 2002:a17:902:c3:: with SMTP id a61-v6mr3253984pla.149.1528398656465; Thu, 07 Jun 2018 12:10:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528398656; cv=none; d=google.com; s=arc-20160816; b=MJvF++gMNCsRw6qnGXZlDf2u0D8LhEtcVjxMMp4SLiF87mNySyTd9HN4vuHiCOXWCh cKAW7kt/JkfVkPfmVtK3lD6wueifHThb9ebRU4Qt/qCY37/fzhW22HMM5P7O3fn770Ka tP4zz5f0Bct4aHB4Q/x1zzwfkWqAqyUsxvoNe8nIlKf5G0xp61WtIpOSDU17tmYF5aXX JSnuScKO2P6LK89MYyR6NQG3Nk4b+R2pg8Qv46gvWzBng3LzWV5Pv1l6sIekmlp3tD5t S7Sy8pUb2UJAj5oGvEIant7k/Dre2THWLaDs2Fe/gwG2hCjE5VdtAn/skHqU+xciW8HX pNKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=9gkTbUHPEvdLo0NXaf83ckdreBIn6rhg8AlN6YVEHlc=; b=evA7ACoGjWKjb9NbhslKY9Kmz5kBGZIH2Zznvd7AQGAGq6Ooo5aQsel1f7bCSjUgNS 8E2S5lYlc7VjvLfUiTbd6N2O8AK0wS6wIP4Q5iNKJbpLVzaTZLbT3tTdPnxOymh4jsl0 cIuvFkRQWN4weGlnAlGUjgf21ziHj6ODD74BQ8ytL4LXfADsbRcBRCRw2ORZ8zNCZua5 +xuLbZHNZPU2k5K+aoJcLjSRA+2ugot/ZWTGDzNA6m//F/K88abvkUFKdGs7yYSkq20L djwxwlKQy9O2ha5UmNoOsGj/dZ2RWcfETg7c1ycIH6CL1ry9+mepzk4lglKe3qgam3hX +t1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=PfJcLuQn; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i133-v6si26024138pgc.351.2018.06.07.12.10.42; Thu, 07 Jun 2018 12:10:56 -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; dkim=pass header.i=@kernel.org header.s=default header.b=PfJcLuQn; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936277AbeFGSZB (ORCPT + 99 others); Thu, 7 Jun 2018 14:25:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:33014 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933706AbeFGSY7 (ORCPT ); Thu, 7 Jun 2018 14:24:59 -0400 Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BF791208A4 for ; Thu, 7 Jun 2018 18:24:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1528395899; bh=WRClLQ/CzMKv0aNLsYddJj10Q8PypBI24A8hteB5ZfU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=PfJcLuQnKqF1zfDv1vBVT8maAhByBX+oTvyAVuZDb1Vb7WeZjjcZOE+V9gSldb2zQ DVZ15WwMFf946Y3BN48T73jIu1qHB6yg0mz7fF1jdYfI2juoToGtuF4J8j3CLD37fD IfLe4b9CWPxlgpb6W4+j3VsVpP8IFyPGyEUeG9qg= Received: by mail-wm0-f50.google.com with SMTP id q4-v6so4205904wmq.1 for ; Thu, 07 Jun 2018 11:24:58 -0700 (PDT) X-Gm-Message-State: APt69E0fMnAxZD6CSxLxw3hkmEYoqpEe6cZM/t3lHtYc6wCXkzUgWpul VJrHthGe4gouYHkWnOM5TuhCe7YDMpTXpNIRHPyScw== X-Received: by 2002:a1c:4a9d:: with SMTP id n29-v6mr2204961wmi.46.1528395897272; Thu, 07 Jun 2018 11:24:57 -0700 (PDT) MIME-Version: 1.0 References: <20180607143705.3531-1-yu-cheng.yu@intel.com> <20180607143705.3531-7-yu-cheng.yu@intel.com> In-Reply-To: From: Andy Lutomirski Date: Thu, 7 Jun 2018 11:24:45 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 6/9] x86/mm: Introduce ptep_set_wrprotect_flush and related functions To: Dave Hansen Cc: Yu-cheng Yu , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "H. J. Lu" , "Shanbhogue, Vedvyas" , "Ravi V. Shankar" , Jonathan Corbet , Oleg Nesterov , Arnd Bergmann , mike.kravetz@oracle.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 7, 2018 at 11:23 AM Dave Hansen wrote: > > On 06/07/2018 09:24 AM, Andy Lutomirski wrote: > >> +static inline void ptep_set_wrprotect_flush(struct vm_area_struct *vma, > >> + unsigned long addr, pte_t *ptep) > >> +{ > >> + bool rw; > >> + > >> + rw = test_and_clear_bit(_PAGE_BIT_RW, (unsigned long *)&ptep->pte); > >> + if (IS_ENABLED(CONFIG_X86_INTEL_SHADOW_STACK_USER)) { > >> + struct mm_struct *mm = vma->vm_mm; > >> + pte_t pte; > >> + > >> + if (rw && (atomic_read(&mm->mm_users) > 1)) > >> + pte = ptep_clear_flush(vma, addr, ptep); > > Why are you clearing the pte? > > I think I insisted on this being in there. > > First of all, we need to flush the TLB eventually because we need the > shadowstack PTE permissions to be in effect. > > But, generally, we can't clear a dirty bit in a "live" PTE without > flushing. The processor can keep writing until we flush, and even keep > setting it whenever _it_ allows a write, which it can do based on stale > TLB contents. Practically, I think a walk to set the dirty bit is > mostly the same as a TLB miss, but that's certainly not guaranteed forever. > > That's even ignoring all the fun errata we have. Maybe make it a separate patch, then? It seems like this patch is doing two almost entirely separate things: adding some flushes and adding the magic hwdirty -> swdirty transition. As it stands, it's quite difficult to read the patch and figure out what it does.