Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp48176imm; Thu, 7 Jun 2018 13:34:10 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJW/h5bZDrDiwqdpFxLXFHGhTwe6RALuQZqmrcmHcAPwYNVswgpje32py+UmHaJTg1thH52 X-Received: by 2002:a65:610d:: with SMTP id z13-v6mr2834913pgu.260.1528403650722; Thu, 07 Jun 2018 13:34:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528403650; cv=none; d=google.com; s=arc-20160816; b=eN+kfzsCDIkjY7usuQM6bbtDCPjY/rzzUVKtIMOWrLFpkN8sCne90FCUfvbe+7xP1J OWyYU67gn4HbDdUvPvcPJDvdW0y5CYB3xROLWGezok8hGW2IXK3urSpZmZvkqSsZBFr0 bMajWv90UR0CP1Y9gMKXvnDxg7Fn4CZ5e0INLA7vy4N9zjI3ZROogP4kVHVIyu4GN2mt 8dG0y0Cn/c49q1tGA5qjzmPKT6E6Z+UFIWC2Hp9jprSGkTzbahCJsY7DaSv2dbl+RPWK cuZzJYdhPyJmXmAObfrduLfQU+6l+e5hee8caTnsb5t78pecrqBhHdYg0sBNsbd1BR8q gzPw== 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=TTdIqwztKHmOX24o/rhU6i04B/N2ZXynQ5j7jJWlu/0=; b=RWsdzh8VfST7w20GCSxaKJcKWp/p6Y5SD2JdPgzm8oS+n1xT30k27qt0eIiNLfaH1g AKxadxXCfAuQBbv3FyXWKetKH5JRYndQ12xR18WgC0iLoBpfgw2/FPfJoyOQVm5mCLAR yCXa9e7ODjLVceuJQd8cAz40uUPVVybtScmS/2wglLZDKPJDph5VhOD8MwQaMCz2HWgj 69rOMl8X+5upKn5HH3cKN1AucbfWJSCvwqL0TQxOlURegZAALS+5Eqrjgrb/gW6sqHJk UqlocX59c4TMlqhra1nHzVLcy6YQafKtM5XIBDgyEVbsji8F85Wd1vyCxFoDeo0bxN6o s3ng== 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 c7-v6si23064492pgu.535.2018.06.07.13.33.55; Thu, 07 Jun 2018 13:34:10 -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 S932366AbeFGUda (ORCPT + 99 others); Thu, 7 Jun 2018 16:33:30 -0400 Received: from mga14.intel.com ([192.55.52.115]:36195 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932213AbeFGUd2 (ORCPT ); Thu, 7 Jun 2018 16:33:28 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2018 13:33:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,487,1520924400"; d="scan'208";a="61319966" Received: from 2b52.sc.intel.com (HELO [143.183.136.51]) ([143.183.136.51]) by fmsmga004.fm.intel.com with ESMTP; 07 Jun 2018 13:33:28 -0700 Message-ID: <1528403417.5265.35.camel@2b52.sc.intel.com> Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack 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 13:30:17 -0700 In-Reply-To: References: <20180607143807.3611-1-yu-cheng.yu@intel.com> <20180607143807.3611-7-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 11:48 -0700, Andy Lutomirski wrote: > On Thu, Jun 7, 2018 at 7:41 AM Yu-cheng Yu wrote: > > > > The following operations are provided. > > > > ARCH_CET_STATUS: > > return the current CET status > > > > ARCH_CET_DISABLE: > > disable CET features > > > > ARCH_CET_LOCK: > > lock out CET features > > > > ARCH_CET_EXEC: > > set CET features for exec() > > > > ARCH_CET_ALLOC_SHSTK: > > allocate a new shadow stack > > > > ARCH_CET_PUSH_SHSTK: > > put a return address on shadow stack > > > > ARCH_CET_ALLOC_SHSTK and ARCH_CET_PUSH_SHSTK are intended only for > > the implementation of GLIBC ucontext related APIs. > > Please document exactly what these all do and why. I don't understand > what purpose ARCH_CET_LOCK and ARCH_CET_EXEC serve. CET is opt in for > each ELF program, so I think there should be no need for a magic > override. CET is initially enabled if the loader has CET capability. Then the loader decides if the application can run with CET. If the application cannot run with CET (e.g. a dependent library does not have CET), then the loader turns off CET before passing to the application. When the loader is done, it locks out CET and the feature cannot be turned off anymore until the next exec() call. When the next exec() is called, CET feature is turned on/off based on the values set by ARCH_CET_EXEC. I will put more details in Documentation/x86/intel_cet.txt.