Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp84115imm; Thu, 30 Aug 2018 08:52:09 -0700 (PDT) X-Google-Smtp-Source: ANB0VdY/ifr3qLVLlWDdymF4XWatRTzL8V5LK95Xg07IEkYzean/whzM/LLmqeHqUsOkww0Ki/Q+ X-Received: by 2002:a62:d80a:: with SMTP id e10-v6mr7102175pfg.113.1535644329217; Thu, 30 Aug 2018 08:52:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535644329; cv=none; d=google.com; s=arc-20160816; b=kQLwsetSDR/wVJCuGrEJoavfILa8MNvy/1Y/7gFMlnA6Z7SyiV7AKJhb8DDXBAvj06 TAlCGGqi3MntWzaAzIKJXEKav0LjEw0FqqDzaaSHyR8P7KBrlUfuSIu2DsDdlPxo4eVS FyCZXtCFzkepnV5XqfOTOZJrlSOMa8TmYJzOjYcTrhKenYfDqYZrdejOw8hRgTXc8RyD ENw0D/087XXren5vz2ed47SaO63Y9WuCkZO2mHEmwHTdBaw9orD/ZPvfavO5Xl6NNMl9 YD7k5wQQeAS8x9y0c1V0rVsmJq4cvRVLXRvxOpGeCWAnhxTDH9NkwdUKVtpNozZA/bxG beTA== 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=H5ai69DPPIITZF7j51zG04M+vRUm70fEw2Dq1nAZXTU=; b=V5Rstj2F2Om8qHFiZ7gSyz79RLjzyY27QwSVLN+aecu8qdn/Hy+BfJ2e0f3YG4DDtV jesMw3nzyYywEMtyGfJ9RfHO14qxWoWGItB0ioM9Cfw0sfTwjRP6htG4CMvT/D8A7MTp SGp6xSO88TYjW89WyjW0i+G2ue8no4Vdj6/XWBi8wztejIXytBn/X5VRCK/XcnZwmZ0a gXNZvETp02mICa635n5tkF6GKUufwNwatjmbpFR2sYSNUXXYb0TxZNniqDG9gPBLsACX S574vvm+9sJyYrwdd8ptLnfToX9Pddab7lbHzDJ+jKmTI+7kvrhMIT39zFSWiEs99SMh WWuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=TEucg1lQ; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n70-v6si7010801pfa.320.2018.08.30.08.51.54; Thu, 30 Aug 2018 08:52:09 -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=@google.com header.s=20161025 header.b=TEucg1lQ; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727545AbeH3TxI (ORCPT + 99 others); Thu, 30 Aug 2018 15:53:08 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:33888 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727500AbeH3TxI (ORCPT ); Thu, 30 Aug 2018 15:53:08 -0400 Received: by mail-oi0-f65.google.com with SMTP id 13-v6so16313739ois.1 for ; Thu, 30 Aug 2018 08:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H5ai69DPPIITZF7j51zG04M+vRUm70fEw2Dq1nAZXTU=; b=TEucg1lQ3k4ZBgBLoFon6Z+b7HlMm8/Y/IMjoDCf1w9nBQgytff9A2B74qA0kQVFXJ cJtQsCPcCRQKfZoWCUXw/xbqEp/Pzoilxg8MtnDvcIrJucMM01tmQJQAh9WW0YgzR8EJ /CDVWWOT/ZeRHYVoLaQqh2r7ndfEe8d+PD5DGsTdVph5RET4lGLKhM2jLkHlcf0bddtQ 9IVLsH2nZpcASvtYWUDQdCRpcWShlv1eWrTi20pEXGAgM4sW1cz5AKhVVqEeF6s59aTN lbuVe9EWR/b/Iq8voQJfB0hGITOpPU1bHSZO0aylisclLYwizmSEXKIFef52zfL7j0of rlsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H5ai69DPPIITZF7j51zG04M+vRUm70fEw2Dq1nAZXTU=; b=KJQbaXAZ4B9B/Rt2fVJKaiiH14Xg13CUnSqbAUqZ8xr34Qp734XDWjTjrY/no6/9B8 5R39zVgMKI+JuSMWKJf+sQ/bmw3H37sxJzzrI5+/JgTJZi/+K8k2SJrpA+hqPGFbwHWx J66TF2LccBR4mRauOP7O1Oj0z2BOnu8TlJKl2WxFM6Ggx3RhtJrECK6x1R+7LdosBf6m okuu1J7KrvziJWwdqPXyon42DECtBTRvrGjgTI2XNEDxjH9hfIP1GUiwUMjmISok3U6a K5yJhPjwWeA4sGDqZGzkSQjTO/LZEdoYpHNRLJ+e+fmLqd6P/XoodBV0fMEucMorCSq1 WhsQ== X-Gm-Message-State: APzg51BnJxf2kGhMkPYxEey51fIIy1twhCvJQ1+E0bqPtB/Tgpiamjw4 60E96T+YQ4/HvDno7R7Qo/bz+63tILlE65QyxJc+Sw== X-Received: by 2002:aca:e504:: with SMTP id c4-v6mr2929576oih.246.1535644220374; Thu, 30 Aug 2018 08:50:20 -0700 (PDT) MIME-Version: 1.0 References: <20180830143904.3168-1-yu-cheng.yu@intel.com> <20180830143904.3168-13-yu-cheng.yu@intel.com> In-Reply-To: <20180830143904.3168-13-yu-cheng.yu@intel.com> From: Jann Horn Date: Thu, 30 Aug 2018 17:49:53 +0200 Message-ID: Subject: Re: [RFC PATCH v3 12/24] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW To: yu-cheng.yu@intel.com Cc: "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 , Dave Hansen , Florian Weimer , hjl.tools@gmail.com, Jonathan Corbet , keescook@chromiun.org, Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , ravi.v.shankar@intel.com, vedvyas.shanbhogue@intel.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, Aug 30, 2018 at 4:43 PM Yu-cheng Yu wrote: > > When Shadow Stack is enabled, the read-only and PAGE_DIRTY_HW PTE > setting is reserved only for the Shadow Stack. To track dirty of > non-Shadow Stack read-only PTEs, we use PAGE_DIRTY_SW. > > Update ptep_set_wrprotect() and pmdp_set_wrprotect(). > > Signed-off-by: Yu-cheng Yu > --- > arch/x86/include/asm/pgtable.h | 42 ++++++++++++++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h > index 4d50de77ea96..556ef258eeff 100644 > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -1203,7 +1203,28 @@ 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) > { > + pte_t pte; > + > clear_bit(_PAGE_BIT_RW, (unsigned long *)&ptep->pte); > + pte = *ptep; > + > + /* > + * Some processors can start a write, but ending 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 change 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. > + */ > + pte = pte_move_flags(pte, _PAGE_DIRTY_HW, _PAGE_DIRTY_SW); > + set_pte_at(mm, addr, ptep, pte); > } I don't understand why it's okay that you first atomically clear the RW bit, then atomically switch from DIRTY_HW to DIRTY_SW. Doesn't that mean that between the two atomic writes, another core can incorrectly see a shadow stack?