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 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 9BD3AC433F5 for ; Thu, 30 Aug 2018 17:58:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3DB1A20658 for ; Thu, 30 Aug 2018 17:58:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3DB1A20658 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 S1727270AbeH3WCA (ORCPT ); Thu, 30 Aug 2018 18:02:00 -0400 Received: from mga06.intel.com ([134.134.136.31]:45764 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726959AbeH3WB7 (ORCPT ); Thu, 30 Aug 2018 18:01:59 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2018 10:58:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,307,1531810800"; d="scan'208";a="69138882" Received: from 2b52.sc.intel.com ([143.183.136.52]) by orsmga007.jf.intel.com with ESMTP; 30 Aug 2018 10:58:40 -0700 Message-ID: <1535651666.27823.6.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: Dave Hansen , Jann Horn 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 , 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 10:54:26 -0700 In-Reply-To: <33d45a12-513c-eba2-a2de-3d6b630e928e@linux.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> 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 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? Yu-cheng