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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 6105DC43381 for ; Wed, 17 Mar 2021 10:16:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2094B64F5E for ; Wed, 17 Mar 2021 10:16:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229643AbhCQKPs (ORCPT ); Wed, 17 Mar 2021 06:15:48 -0400 Received: from casper.infradead.org ([90.155.50.34]:57244 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229554AbhCQKPa (ORCPT ); Wed, 17 Mar 2021 06:15:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=GbFSfPvAGSrYmcgjy1/jiFvVWTiImeZT/N+n10CQYO8=; b=K/KBfR1lYuJIbFmu1hfj4ix8Jn em4xUzlucCoj6dtG0B0LlJmZrrSdTywCapOny9m8bf0LhsIJR6smrTPigMfjkJTWb7+/6bXwxQyI1 fSgsrI6fG4w8L6QtBYV71XY39G/clhb/nivLkMUQaciYMDFrNnxm0ez3Jwi+qYgfmmU/10ymuYnal s14JDtuNqJtjTCiVuMLnE7KAW5BFIJ66gTT5tl0N0EG+DvuOrMfKIQcIntXUv7LQHmr7IveCyAh2O t1sQ6hBj4yVh5Vz1sQyRFlF7b5PKE+LFa0o7yVrfQusilBrwT7Xli35PPfbSqpZhnkJmuEFnOtc6H vpx1alMQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94 #2 (Red Hat Linux)) id 1lMTC5-001MbO-GD; Wed, 17 Mar 2021 10:14:29 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 44F923012DF; Wed, 17 Mar 2021 11:14:24 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 3537F2C3C233C; Wed, 17 Mar 2021 11:14:24 +0100 (CET) Date: Wed, 17 Mar 2021 11:14:24 +0100 From: Peter Zijlstra To: Ingo Molnar Cc: "Yu, Yu-cheng" , 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 , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang , Pengfei Xu , Haitao Huang Subject: Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack Message-ID: References: <20210316151054.5405-1-yu-cheng.yu@intel.com> <20210316211552.GU4746@worktop.programming.kicks-ass.net> <90e453ee-377b-0342-55f9-9412940262f2@intel.com> <20210317091800.GA1461644@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210317091800.GA1461644@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 17, 2021 at 10:18:00AM +0100, Ingo Molnar wrote: > > * Yu, Yu-cheng wrote: > > > On 3/16/2021 2:15 PM, Peter Zijlstra wrote: > > > On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote: > > > > Control-flow Enforcement (CET) is a new Intel processor feature that blocks > > > > return/jump-oriented programming attacks. Details are in "Intel 64 and > > > > IA-32 Architectures Software Developer's Manual" [1]. > > > > > > > > CET can protect applications and the kernel. This series enables only > > > > application-level protection, and has three parts: > > > > > > > > - Shadow stack [2], > > > > - Indirect branch tracking [3], and > > > > - Selftests [4]. > > > > > > CET is marketing; afaict SS and IBT are 100% independent and there's no > > > reason what so ever to have them share any code, let alone a Kconfig > > > knob. > > > > We used to have shadow stack and ibt under separate Kconfig options, but in > > a few places they actually share same code path, such as the XSAVES > > supervisor states and ELF header for example. Anyways I will be happy to > > make changes again if there is agreement. > > I was look at: > > x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states > > didn't see any IBT logic - it's essentially all shadow stack state. > > Which is not surprising, forward call edge integrity protection (IBT) > requires very little state, does it? They hid the IBT enable bit in the U_CET MSR, which is in the XSAVE thing.