Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp5129018imm; Tue, 12 Jun 2018 03:04:33 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKNY+bD7E0HnBbn7MZfl7Hk9sCD2lBBqjb/fhGaRvCkmLn7u+mdBEB0f1lj4yk9+biQX0bJ X-Received: by 2002:a63:ae06:: with SMTP id q6-v6mr2626020pgf.255.1528797873811; Tue, 12 Jun 2018 03:04:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528797873; cv=none; d=google.com; s=arc-20160816; b=N76Dk0N61jWXyPRyQ9UFqY7F3I91Ud1F6HdvcWeMCKhAPOBdYufS3B+wZpw/Isz1hm Tb9Pac83HMHekZ3FBjop2PTc1ZkluP+b02bkoLVuzJHlgFmoOZXWR58aCt7W8RoAOYGJ rNSxryoNdhIv9zKnJPUWDyZ1w4gOOvmTQt+vOqkz1XRBH5c9yaa2579TsVuRi5gsXyFt xkNnATmSkHK9ZKPI28llRxnqFMAQB3eqEGz7+DNe0n0ciJpRcPm3Gtio09MCO449VqRC vePMJB/aLWRF2lEWGJdzKmu2wwzPvmG249/ulY6RUWBA3hlkBLV11pfHEMANW7fiX5iq Meag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=rtVEo9GT2M+CYO1LyjQSLcZYYiqKyzQqa2mZWYEL1EU=; b=CRciWeNC4G65/mb43CZw8eFbBw+LN5LAYcpF+j9EqHA+I7HqFh00flYzTlBlMbOeCW mSLM0tcQXYGMGwd5rmIEnkWRBDkNDDeO5EUNHTHJA7uti6HZtCv+BlgX5bndxWoiVzGB O4u4H4Tyh2aHmdlDkQiys8g0cSBeyzpvnVkOm/HsPTJxE7BQWksvBZrsicLmfDKprTts QPjiPMOfkm204NeajmbxLLFFbyGTsc+yvhhd/iCWjFnnEV2xWUuV1DDoCaZiugYsTqZf zFIrovAZ8XNnJHDkieAJKA9FXi8OtglPyh89ecmtXBL2oH0UPfcn0FNLCaqvE1KapMlt X3RA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b67-v6si604440plb.272.2018.06.12.03.04.19; Tue, 12 Jun 2018 03:04:33 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932565AbeFLKDX (ORCPT + 99 others); Tue, 12 Jun 2018 06:03:23 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:40312 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752832AbeFLKDV (ORCPT ); Tue, 12 Jun 2018 06:03:21 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fSg8x-0004I7-K1; Tue, 12 Jun 2018 12:03:15 +0200 Date: Tue, 12 Jun 2018 12:03:15 +0200 (CEST) From: Thomas Gleixner To: "H.J. Lu" cc: Andy Lutomirski , Yu-cheng Yu , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , X86 ML , "H. Peter Anvin" , Ingo Molnar , "Shanbhogue, Vedvyas" , "Ravi V. Shankar" , Dave Hansen , Jonathan Corbet , Oleg Nesterov , Arnd Bergmann , mike.kravetz@oracle.com Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack In-Reply-To: Message-ID: References: <20180607143807.3611-1-yu-cheng.yu@intel.com> <20180607143807.3611-7-yu-cheng.yu@intel.com> <1528403417.5265.35.camel@2b52.sc.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Jun 2018, H.J. Lu wrote: > On Thu, Jun 7, 2018 at 2:01 PM, Andy Lutomirski wrote: > > Why is the lockout necessary? If user code enables CET and tries to > > run code that doesn't support CET, it will crash. I don't see why we > > need special code in the kernel to prevent a user program from calling > > arch_prctl() and crashing itself. There are already plenty of ways to > > do that :) > > On CET enabled machine, not all programs nor shared libraries are > CET enabled. But since ld.so is CET enabled, all programs start > as CET enabled. ld.so will disable CET if a program or any of its shared > libraries aren't CET enabled. ld.so will lock up CET once it is done CET > checking so that CET can't no longer be disabled afterwards. That works for stuff which loads all libraries at start time, but what happens if the program uses dlopen() later on? If CET is force locked and the library is not CET enabled, it will fail. I don't see the point of trying to support CET by magic. It adds complexity and you'll never be able to handle all corner cases correctly. dlopen() is not even a corner case. Occasionally stuff needs to be recompiled to utilize new mechanisms, see retpoline ... Thanks, tglx