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_HELO_NONE,SPF_PASS autolearn=no 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 5A366C10F25 for ; Fri, 6 Mar 2020 21:16:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 38D7F206E6 for ; Fri, 6 Mar 2020 21:16:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726781AbgCFVQ6 (ORCPT ); Fri, 6 Mar 2020 16:16:58 -0500 Received: from mga17.intel.com ([192.55.52.151]:11090 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726185AbgCFVQ6 (ORCPT ); Fri, 6 Mar 2020 16:16:58 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2020 13:16:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,523,1574150400"; d="scan'208";a="244724810" Received: from yyu32-desk.sc.intel.com ([143.183.136.146]) by orsmga006.jf.intel.com with ESMTP; 06 Mar 2020 13:16:56 -0800 Message-ID: Subject: Re: [RFC PATCH v9 05/27] x86/cet/shstk: Add Kconfig option for user-mode Shadow Stack protection From: Yu-cheng Yu To: Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , x86-patch-review@intel.com Date: Fri, 06 Mar 2020 13:16:55 -0800 In-Reply-To: References: <20200205181935.3712-1-yu-cheng.yu@intel.com> <20200205181935.3712-6-yu-cheng.yu@intel.com> <070d9d78981f0aad2baf740233e8dfc32ecd29d7.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) 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 Fri, 2020-03-06 at 11:02 -0800, Dave Hansen wrote: > On 3/6/20 10:37 AM, Yu-cheng Yu wrote: > > We used to do this for CET instructions, but after adding kernel-mode > > instructions and inserting ENDBR's, the code becomes cluttered. I also > > found an earlier discussion on the ENDBR: > > > > https://lore.kernel.org/lkml/CALCETrVRH8LeYoo7V1VBPqg4WS0Enxtizt=T7dPvgoeWfJrdzA@mail.gmail.com/ > > > > It makes sense to let the user know early on that the system cannot support > > CET and cannot build a CET-enabled kernel. > > > > One thing we can do is to disable CET in Kconfig and not in kernel > > build, which I will do in the next version. > > I'll go on the record and say I think we should allow building > CET-enabled kernels on old toolchains. We need it for build test > coverage. We can spit out a warning, but we need to allow building it. The build test will go through (assembler or .byte), once the opcode patch is applied [1]. Also, when we enable kernel-mode CET, it is difficult to build IBT code without the right tool chain. Yu-cheng [1] opcode patch: https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yu-cheng Yu Subject: Re: [RFC PATCH v9 05/27] x86/cet/shstk: Add Kconfig option for user-mode Shadow Stack protection Date: Fri, 06 Mar 2020 13:16:55 -0800 Message-ID: References: <20200205181935.3712-1-yu-cheng.yu@intel.com> <20200205181935.3712-6-yu-cheng.yu@intel.com> <070d9d78981f0aad2baf740233e8dfc32ecd29d7.camel@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-doc-owner@vger.kernel.org To: Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz List-Id: linux-arch.vger.kernel.org On Fri, 2020-03-06 at 11:02 -0800, Dave Hansen wrote: > On 3/6/20 10:37 AM, Yu-cheng Yu wrote: > > We used to do this for CET instructions, but after adding kernel-mode > > instructions and inserting ENDBR's, the code becomes cluttered. I also > > found an earlier discussion on the ENDBR: > > > > https://lore.kernel.org/lkml/CALCETrVRH8LeYoo7V1VBPqg4WS0Enxtizt=T7dPvgoeWfJrdzA@mail.gmail.com/ > > > > It makes sense to let the user know early on that the system cannot support > > CET and cannot build a CET-enabled kernel. > > > > One thing we can do is to disable CET in Kconfig and not in kernel > > build, which I will do in the next version. > > I'll go on the record and say I think we should allow building > CET-enabled kernels on old toolchains. We need it for build test > coverage. We can spit out a warning, but we need to allow building it. The build test will go through (assembler or .byte), once the opcode patch is applied [1]. Also, when we enable kernel-mode CET, it is difficult to build IBT code without the right tool chain. Yu-cheng [1] opcode patch: https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ 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_HELO_NONE,SPF_PASS autolearn=no 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 09D7DC10DCE for ; Fri, 6 Mar 2020 21:17:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AEDFF206E6 for ; Fri, 6 Mar 2020 21:17:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AEDFF206E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1C4A26B0005; Fri, 6 Mar 2020 16:17:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 14E736B0006; Fri, 6 Mar 2020 16:17:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 014B96B0007; Fri, 6 Mar 2020 16:16:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id DAEAB6B0005 for ; Fri, 6 Mar 2020 16:16:59 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A53612C37 for ; Fri, 6 Mar 2020 21:16:59 +0000 (UTC) X-FDA: 76566197358.18.jeans64_3cff7234d0906 X-HE-Tag: jeans64_3cff7234d0906 X-Filterd-Recvd-Size: 3701 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Fri, 6 Mar 2020 21:16:58 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2020 13:16:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,523,1574150400"; d="scan'208";a="244724810" Received: from yyu32-desk.sc.intel.com ([143.183.136.146]) by orsmga006.jf.intel.com with ESMTP; 06 Mar 2020 13:16:56 -0800 Message-ID: Subject: Re: [RFC PATCH v9 05/27] x86/cet/shstk: Add Kconfig option for user-mode Shadow Stack protection From: Yu-cheng Yu To: Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , x86-patch-review@intel.com Date: Fri, 06 Mar 2020 13:16:55 -0800 In-Reply-To: References: <20200205181935.3712-1-yu-cheng.yu@intel.com> <20200205181935.3712-6-yu-cheng.yu@intel.com> <070d9d78981f0aad2baf740233e8dfc32ecd29d7.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 2020-03-06 at 11:02 -0800, Dave Hansen wrote: > On 3/6/20 10:37 AM, Yu-cheng Yu wrote: > > We used to do this for CET instructions, but after adding kernel-mode > > instructions and inserting ENDBR's, the code becomes cluttered. I also > > found an earlier discussion on the ENDBR: > > > > https://lore.kernel.org/lkml/CALCETrVRH8LeYoo7V1VBPqg4WS0Enxtizt=T7dPvgoeWfJrdzA@mail.gmail.com/ > > > > It makes sense to let the user know early on that the system cannot support > > CET and cannot build a CET-enabled kernel. > > > > One thing we can do is to disable CET in Kconfig and not in kernel > > build, which I will do in the next version. > > I'll go on the record and say I think we should allow building > CET-enabled kernels on old toolchains. We need it for build test > coverage. We can spit out a warning, but we need to allow building it. The build test will go through (assembler or .byte), once the opcode patch is applied [1]. Also, when we enable kernel-mode CET, it is difficult to build IBT code without the right tool chain. Yu-cheng [1] opcode patch: https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/