Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp933064rwb; Tue, 29 Nov 2022 07:06:04 -0800 (PST) X-Google-Smtp-Source: AA0mqf5WWUUchoIUkzIf2+cIk8DzMU42F4OKOiiSZHtVbPisugmwiFRnOFtQK+Fbg3o0QI5W7Wn1 X-Received: by 2002:a05:6402:685:b0:46a:890d:b0d1 with SMTP id f5-20020a056402068500b0046a890db0d1mr24808521edy.292.1669734364249; Tue, 29 Nov 2022 07:06:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669734364; cv=none; d=google.com; s=arc-20160816; b=kQnZQ/47CJIKihfjL8rusIckNNJorLr67fDaypbOrdqFhkyvQhpgMsN1TnaTwDYXMu RndzQbfuoHtMxStiTMZNwwAsMQEPoroLhxfX8h0eFkk8y/ix316Ni8my3qj5Lq0B1PrI 8UwqWykVvq+sGrWnPYEpG9+dUkYFpFHoUE2Ds2SOkb+mEndKtC/xOtJ+lKLUF+iqO8ON Ep7XYkMMRrlgkn+hIApSg4pUHz23QJKU3ufvIdh5BX7rQsksSD9pLYZ4b1XTJmyQnu/O Tw/KGF4oYJ7HxG7d6pL8+x0CmuZxgNjkM+T6X4Uj2sTBI7SC9MYwBIl9Qv2umjhGRV68 WBGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=QfcMOLpL7FrCvY8GSfK+YtqploCAsF27JXhObDSNnEE=; b=JYB3Bl034bmfKyE4NkrCaFdBrSXvTPRGY9BI/HvemLlOv/AUyeNhwZEtsglFrKxbjm XRVio2BSqNc3gH8JRIvYEu8GBQwQn2v4T4V0yww/PtH3jUrE7wmjfqK8PeKS3ss37i2f jyn5omj3QVnZpPJwoFtPBF4ZB9VboRn2rESvDP9tzt+5+Mq6GrByPND9jAjQB0cgz6RN 3M3Qp5/Rve2U6RqpFHuJV/OYXbQg5Bn3SxWYpgawIx1X5MG+yNAcIevu7HpU1nZUNacm Mbwlu4Xv4PWhDc5tFjQBRrwLH7iPQnR+T/6he/513a6dZJq9ycgBxfWMBv5+H+8n0lBr yAcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=P0lDuBgf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nc36-20020a1709071c2400b007ae8d01144dsi12940241ejc.717.2022.11.29.07.05.25; Tue, 29 Nov 2022 07:06:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=P0lDuBgf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234784AbiK2Oqe (ORCPT + 84 others); Tue, 29 Nov 2022 09:46:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230151AbiK2Oqc (ORCPT ); Tue, 29 Nov 2022 09:46:32 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBA8B55AAA for ; Tue, 29 Nov 2022 06:46:30 -0800 (PST) Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (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 17D311EC06D0; Tue, 29 Nov 2022 15:46:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1669733188; 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=QfcMOLpL7FrCvY8GSfK+YtqploCAsF27JXhObDSNnEE=; b=P0lDuBgfn9IqvTwDDPpdEc4JFS2K2xw3IEuxT5D93ihP2mgdkMQsynJxl+FhUbvWS2wUh6 Rd45Kv1TLxuzVyOcUi+l6yU+NVh5KqGjTEnJ74jFA5CFixUXMxCaCn0HjxeTEhqjO6nZb+ kpG6UA5jtPu/p++6xyGeGfTXg7uvvCQ= Date: Tue, 29 Nov 2022 15:46:24 +0100 From: Borislav Petkov To: Uros Bizjak Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , "H. Peter Anvin" Subject: Re: [PATCH] x86/boot: Remove x86_32 PIC using ebx workaround Message-ID: References: <20221104124546.196077-1-ubizjak@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ok, I tried to summarize what we talked on the thread and have the whole deal explained in greater detail. Holler if something's missing: --- From: Uros Bizjak Date: Fri, 4 Nov 2022 13:45:46 +0100 Subject: [PATCH] x86/boot: Remove x86_32 PIC using %ebx workaround The currently supported minimum gcc version is 5.1. Before that, the PIC register, when generating Position Independent Code, was considered "fixed" in the sense that it wasn't in the set of registers available to the compiler's register allocator. Which, on x86-32, is already a very small set. What is more, the register allocator was unable to satisfy extended asm "=b" constraints. (Yes, PIC code uses %ebx on 32-bit as the base reg.) With gcc5: "Reuse of the PIC hard register, instead of using a fixed register, was implemented on x86/x86-64 targets. This improves generated PIC code performance as more hard registers can be used. Shared libraries can significantly benefit from this optimization. Currently it is switched on only for x86/x86-64 targets. As RA infrastructure is already implemented for PIC register reuse, other targets might follow this in the future." (from: https://gcc.gnu.org/gcc-5/changes.html) which basically means that the register allocator has a higher degree of freedom when handling %ebx, including reloading it with the correct value before a PIC access. Furthermore: arch/x86/Makefile: # Never want PIC in a 32-bit kernel, prevent breakage with GCC built # with nonstandard options KBUILD_CFLAGS += -fno-pic $ gcc -Wp,-MMD,arch/x86/boot/.cpuflags.o.d ... -fno-pic ... -D__KBUILD_MODNAME=kmod_cpuflags -c -o arch/x86/boot/cpuflags.o arch/x86/boot/cpuflags.c so the 32-bit workaround in cpuid_count() is fixing exactly nothing because 32-bit configs don't even allow PIC builds. As to 64-bit builds: they're done using -mcmodel=kernel which produces RIP-relative addressing for PIC builds and thus does not apply here either. So get rid of the thing and make cpuid_count() nice and simple. There should be no functional changes resulting from this. [ bp: Expand commit message. ] Signed-off-by: Uros Bizjak Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20221104124546.196077-1-ubizjak@gmail.com --- arch/x86/boot/cpuflags.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/arch/x86/boot/cpuflags.c b/arch/x86/boot/cpuflags.c index a83d67ec627d..d75237ba7ce9 100644 --- a/arch/x86/boot/cpuflags.c +++ b/arch/x86/boot/cpuflags.c @@ -64,20 +64,11 @@ int has_eflag(unsigned long mask) return !!((f0^f1) & mask); } -/* Handle x86_32 PIC using ebx. */ -#if defined(__i386__) && defined(__PIC__) -# define EBX_REG "=r" -#else -# define EBX_REG "=b" -#endif - void cpuid_count(u32 id, u32 count, u32 *a, u32 *b, u32 *c, u32 *d) { - asm volatile(".ifnc %%ebx,%3 ; movl %%ebx,%3 ; .endif \n\t" - "cpuid \n\t" - ".ifnc %%ebx,%3 ; xchgl %%ebx,%3 ; .endif \n\t" - : "=a" (*a), "=c" (*c), "=d" (*d), EBX_REG (*b) - : "a" (id), "c" (count) + asm volatile("cpuid" + : "=a" (*a), "=b" (*b), "=c" (*c), "=d" (*d) + : "0" (id), "2" (count) ); } -- 2.35.1 -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette