From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D991AC433F4 for ; Thu, 30 Aug 2018 20:25:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8FD8F20834 for ; Thu, 30 Aug 2018 20:25:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8FD8F20834 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727500AbeHaA3p (ORCPT ); Thu, 30 Aug 2018 20:29:45 -0400 Received: from mga03.intel.com ([134.134.136.65]:14599 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727237AbeHaA3p (ORCPT ); Thu, 30 Aug 2018 20:29:45 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2018 13:25:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,308,1531810800"; d="scan'208";a="79683215" Received: from 2b52.sc.intel.com ([143.183.136.52]) by orsmga003.jf.intel.com with ESMTP; 30 Aug 2018 13:25:49 -0700 Message-ID: <1535660494.28258.36.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: Jann Horn Cc: Dave Hansen , 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@chromiun.org, Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , ravi.v.shankar@intel.com, vedvyas.shanbhogue@intel.com Date: Thu, 30 Aug 2018 13:21:34 -0700 In-Reply-To: References: <20180830143904.3168-1-yu-cheng.yu@intel.com> <20180830143904.3168-13-yu-cheng.yu@intel.com> <079a55f2-4654-4adf-a6ef-6e480b594a2f@linux.intel.com> <1535649960.26689.15.camel@intel.com> <33d45a12-513c-eba2-a2de-3d6b630e928e@linux.intel.com> <1535651666.27823.6.camel@intel.com> 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 Thu, 2018-08-30 at 19:59 +0200, Jann Horn wrote: > On Thu, Aug 30, 2018 at 7:58 PM Yu-cheng Yu > wrote: > > > > > > On Thu, 2018-08-30 at 10:33 -0700, Dave Hansen wrote: > > > > > > On 08/30/2018 10:26 AM, Yu-cheng Yu wrote: > > > > > > > > > > > > We don't have the guard page now, but there is a shadow stack > > > > token > > > > there, which cannot be used as a return address. > > > The overall concern is that we could overflow into a page that > > > we > > > did > > > not intend.  Either another actual shadow stack or something > > > that a > > > page > > > that the attacker constructed, like the transient scenario Jann > > > described. > > > > > A task could go beyond the bottom of its shadow stack by doing > > either > > 'ret' or 'incssp'.  If it is the 'ret' case, the token prevents > > it. > >  If it is the 'incssp' case, a guard page cannot prevent it > > entirely, > > right? > I mean the other direction, on "call". In the flow you described, if C writes to the overflow page before B gets in with a 'call', the return address is still correct for B.  To make an attack, C needs to write again before the TLB flush.  I agree that is possible. Assume we have a guard page, can someone in the short window do recursive calls in B, move ssp to the end of the guard page, and trigger the same again?  He can simply take the incssp route. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yu-cheng Yu Subject: Re: [RFC PATCH v3 12/24] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW Date: Thu, 30 Aug 2018 13:21:34 -0700 Message-ID: <1535660494.28258.36.camel@intel.com> References: <20180830143904.3168-1-yu-cheng.yu@intel.com> <20180830143904.3168-13-yu-cheng.yu@intel.com> <079a55f2-4654-4adf-a6ef-6e480b594a2f@linux.intel.com> <1535649960.26689.15.camel@intel.com> <33d45a12-513c-eba2-a2de-3d6b630e928e@linux.intel.com> <1535651666.27823.6.camel@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Jann Horn Cc: Dave Hansen , 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@chromiun.org, Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek List-Id: linux-api@vger.kernel.org On Thu, 2018-08-30 at 19:59 +0200, Jann Horn wrote: > On Thu, Aug 30, 2018 at 7:58 PM Yu-cheng Yu > wrote: > > > > > > On Thu, 2018-08-30 at 10:33 -0700, Dave Hansen wrote: > > > > > > On 08/30/2018 10:26 AM, Yu-cheng Yu wrote: > > > > > > > > > > > > We don't have the guard page now, but there is a shadow stack > > > > token > > > > there, which cannot be used as a return address. > > > The overall concern is that we could overflow into a page that > > > we > > > did > > > not intend.  Either another actual shadow stack or something > > > that a > > > page > > > that the attacker constructed, like the transient scenario Jann > > > described. > > > > > A task could go beyond the bottom of its shadow stack by doing > > either > > 'ret' or 'incssp'.  If it is the 'ret' case, the token prevents > > it. > >  If it is the 'incssp' case, a guard page cannot prevent it > > entirely, > > right? > I mean the other direction, on "call". In the flow you described, if C writes to the overflow page before B gets in with a 'call', the return address is still correct for B.  To make an attack, C needs to write again before the TLB flush.  I agree that is possible. Assume we have a guard page, can someone in the short window do recursive calls in B, move ssp to the end of the guard page, and trigger the same again?  He can simply take the incssp route. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by kanga.kvack.org (Postfix) with ESMTP id 584876B5336 for ; Thu, 30 Aug 2018 16:25:51 -0400 (EDT) Received: by mail-pg1-f198.google.com with SMTP id r20-v6so5593764pgv.20 for ; Thu, 30 Aug 2018 13:25:51 -0700 (PDT) Received: from mga12.intel.com (mga12.intel.com. [192.55.52.136]) by mx.google.com with ESMTPS id y19-v6si7021590plr.497.2018.08.30.13.25.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 13:25:50 -0700 (PDT) Message-ID: <1535660494.28258.36.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 Date: Thu, 30 Aug 2018 13:21:34 -0700 In-Reply-To: References: <20180830143904.3168-1-yu-cheng.yu@intel.com> <20180830143904.3168-13-yu-cheng.yu@intel.com> <079a55f2-4654-4adf-a6ef-6e480b594a2f@linux.intel.com> <1535649960.26689.15.camel@intel.com> <33d45a12-513c-eba2-a2de-3d6b630e928e@linux.intel.com> <1535651666.27823.6.camel@intel.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Jann Horn Cc: Dave Hansen , 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@chromiun.org, Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , ravi.v.shankar@intel.com, vedvyas.shanbhogue@intel.com On Thu, 2018-08-30 at 19:59 +0200, Jann Horn wrote: > On Thu, Aug 30, 2018 at 7:58 PM Yu-cheng Yu > wrote: > > > > > > On Thu, 2018-08-30 at 10:33 -0700, Dave Hansen wrote: > > > > > > On 08/30/2018 10:26 AM, Yu-cheng Yu wrote: > > > > > > > > > > > > We don't have the guard page now, but there is a shadow stack > > > > token > > > > there, which cannot be used as a return address. > > > The overall concern is that we could overflow into a page that > > > we > > > did > > > not intend.A A Either another actual shadow stack or something > > > that a > > > page > > > that the attacker constructed, like the transient scenario Jann > > > described. > > > > > A task could go beyond the bottom of its shadow stack by doing > > either > > 'ret' or 'incssp'.A A If it is the 'ret' case, the token prevents > > it. > > A If it is the 'incssp' case, a guard page cannot prevent it > > entirely, > > right? > I mean the other direction, on "call". In the flow you described, if C writes to the overflow page before B gets in with a 'call', the return address is still correct for B. A To make an attack, C needs to write again before the TLB flush. A I agree that is possible. Assume we have a guard page, can someone in the short window do recursive calls in B, move ssp to the end of the guard page, and trigger the same again? A He can simply take the incssp route.