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 DD349C83011 for ; Mon, 30 Nov 2020 18:15:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 65E0620789 for ; Mon, 30 Nov 2020 18:15:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alien8.de header.i=@alien8.de header.b="cYDnN961" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388014AbgK3SPl (ORCPT ); Mon, 30 Nov 2020 13:15:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54782 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726376AbgK3SPl (ORCPT ); Mon, 30 Nov 2020 13:15:41 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D534CC0613D4; Mon, 30 Nov 2020 10:15:00 -0800 (PST) Received: from zn.tnic (p200300ec2f0c0400dc0f4426b730eaa1.dip0.t-ipconnect.de [IPv6:2003:ec:2f0c:400:dc0f:4426:b730:eaa1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 382831EC0249; Mon, 30 Nov 2020 19:14:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1606760099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=DsIkyRDqsHAg65QslwmCp09JK5IjAEIZ6mx1FlBzzao=; b=cYDnN961MFrBT2jgiFz98Jd1x2JPsKSatoVYE6Ap3wX8nWbvd9+BnwaGXSppVat3ie+7Pi 4M3BhZGFiVKezT3prSdk2+xQZivfw0GqWSQ6QMI/IL1S8vhW1jUqZE0+8bZfSt56qp4ZcU 4ImngURjhKH93VTjAU3Fj/J8Y+wUYtw= Date: Mon, 30 Nov 2020 19:15:00 +0100 From: Borislav Petkov To: "Yu, Yu-cheng" Cc: 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 , 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 , Weijiang Yang , Pengfei Xu Subject: Re: [PATCH v15 05/26] x86/cet/shstk: Add Kconfig option for user-mode Shadow Stack Message-ID: <20201130181500.GH6019@zn.tnic> References: <20201110162211.9207-1-yu-cheng.yu@intel.com> <20201110162211.9207-6-yu-cheng.yu@intel.com> <20201127171012.GD13163@zn.tnic> <98e1b159-bf32-5c67-455b-f798023770ef@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <98e1b159-bf32-5c67-455b-f798023770ef@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Sat, Nov 28, 2020 at 08:23:59AM -0800, Yu, Yu-cheng wrote: > We have X86_BRANCH_TRACKING_USER too. My thought was, X86_CET means any of > kernel/user shadow stack/ibt. It is not about what it means - it is what you're going to use/need. You have ifdeffery both with X86_CET and X86_SHADOW_STACK_USER. This one +#ifdef CONFIG_X86_SHADOW_STACK_USER +#define DISABLE_SHSTK 0 +#else +#define DISABLE_SHSTK (1 << (X86_FEATURE_SHSTK & 31)) +#endif for example, is clearly wrong and wants to be #ifdef CONFIG_X86_CET, for example. Unless I'm missing something totally obvious. In any case, you need to analyze what Kconfig defines the code will need and to what they belong and add only the minimal subset needed. Our Kconfig symbols space is already nuts so adding more needs to be absolutely justified. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette