Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2518545imm; Thu, 7 Jun 2018 12:01:45 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKfAHGt3ubxXHzg4LZguWsZKtkIXcqhp0mZGhRjUraDDfIJ1oZ0Kp9kr3LaqaRLizSIPXvX X-Received: by 2002:a63:88c3:: with SMTP id l186-v6mr2575903pgd.226.1528398105206; Thu, 07 Jun 2018 12:01:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528398105; cv=none; d=google.com; s=arc-20160816; b=dR+KuuzDkRN3BD8iVV8siww+6b3/izztQVZqzfodYPi91ImdjOR077M1rPoRLP1eHg Yjw7SQao2vyw/Iw/ernl78XfDL2oMDR5DuuLHXTmjjZw4YweYOTObSNaHI7Vluvs0LU9 nkkzjwaWB5IdSvyJKsq92YOFxTgBWmY7M8IzcBOpegDCgbqbtfvEW4eKT3E/zu1XZNA/ bcbtdN97S6j2Z7jOEdXAR/ygvX+/nYbS7ZqezjpUUTZqoHiw4zZrng5eJM0Sp5NiHW3k mQey6WIBaQvMPoD13+kucQcxrJTGGtICYCL5WXFUZAIUy3CwAbLYN/u6tJjSn7oBy7ZV h4qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=NQTWHaGpxO1c8JBQcUF9I+igi3XyZo8yxYVJukCm1Js=; b=qpXNWjxmsxr0p/GsgOdkY1ALXZqzuyZ7nwFP3MWfbqaX9zFqmC4ayEKgAjK2onlWwb lf9nx/5btOdQl73GGeohgWpCaQZbdUN3mng+ZdAr0fs4UpeY3Pq09OUUPbj3EdiFfpKS YUi8BxCYhW01FIAEJvyzcsGGDhJdxkZOK9nh1dD6k2p+zmXk/aRYG89Z/la08UF+tq4H SSg1uboNx+6plHwNhFl/0FLIK2gE6FQOQTfznwewFv5NHX7glVttD0ULVzYJX3IQ+KBa EthNo662F7NFybz9CdGzhInqD4KkjIamiTamDnzIE/GwpnaV5RIvYJcvvqRxkv87ZKF4 GyjQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u4-v6si33183147plj.43.2018.06.07.12.01.28; Thu, 07 Jun 2018 12:01:45 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753429AbeFGQtX (ORCPT + 99 others); Thu, 7 Jun 2018 12:49:23 -0400 Received: from mga18.intel.com ([134.134.136.126]:18222 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750933AbeFGQtV (ORCPT ); Thu, 7 Jun 2018 12:49:21 -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 orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2018 09:49:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,487,1520924400"; d="scan'208";a="47238763" Received: from 2b52.sc.intel.com (HELO [143.183.136.51]) ([143.183.136.51]) by orsmga007.jf.intel.com with ESMTP; 07 Jun 2018 09:49:20 -0700 Message-ID: <1528389969.4636.25.camel@2b52.sc.intel.com> Subject: Re: [PATCH 7/9] x86/mm: Shadow stack page fault error checking From: Yu-cheng Yu To: Andy Lutomirski Cc: 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" , Dave Hansen , Jonathan Corbet , Oleg Nesterov , Arnd Bergmann , mike.kravetz@oracle.com Date: Thu, 07 Jun 2018 09:46:09 -0700 In-Reply-To: References: <20180607143705.3531-1-yu-cheng.yu@intel.com> <20180607143705.3531-8-yu-cheng.yu@intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-06-07 at 09:26 -0700, Andy Lutomirski wrote: > On Thu, Jun 7, 2018 at 7:40 AM Yu-cheng Yu wrote: > > > > If a page fault is triggered by a shadow stack access (e.g. > > call/ret) or shadow stack management instructions (e.g. > > wrussq), then bit[6] of the page fault error code is set. > > > > In access_error(), we check if a shadow stack page fault > > is within a shadow stack memory area. > > > > Signed-off-by: Yu-cheng Yu > > > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c > > index 73bd8c95ac71..2b3b9170109c 100644 > > --- a/arch/x86/mm/fault.c > > +++ b/arch/x86/mm/fault.c > > @@ -1166,6 +1166,17 @@ access_error(unsigned long error_code, struct vm_area_struct *vma) > > (error_code & X86_PF_INSTR), foreign)) > > return 1; > > > > + /* > > + * Verify X86_PF_SHSTK is within a shadow stack VMA. > > + * It is always an error if there is a shadow stack > > + * fault outside a shadow stack VMA. > > + */ > > + if (error_code & X86_PF_SHSTK) { > > + if (!(vma->vm_flags & VM_SHSTK)) > > + return 1; > > + return 0; > > + } > > + > > What, if anything, would go wrong without this change? It seems like > it might be purely an optimization. If so, can you mention that in > the comment? Without this check, the page fault code could overlook the fact that the application is trying to use non shadow stack area for shadow stack. I will add this to the comments.