Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp1142559rdd; Wed, 10 Jan 2024 09:50:03 -0800 (PST) X-Google-Smtp-Source: AGHT+IF36oDRiEw7Zy7fPaAqaJnmHJHnsTfv7KWMK5PuFhtKOIuniV/v0C3IGUXNA7fWLKSHAKjr X-Received: by 2002:a17:906:3947:b0:a2c:2094:5acd with SMTP id g7-20020a170906394700b00a2c20945acdmr203564eje.18.1704909003658; Wed, 10 Jan 2024 09:50:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704909003; cv=none; d=google.com; s=arc-20160816; b=uCsRALSpTBvtLxCXHlM9aUpgQWgyl2qLrgZg1YYhypi+FqajNTupVpi++GNbVYC01k Dwfq+D5XlM4Ft6fIk4qMTdmFiOVMY84ltREKkHholQXds5bmLaduyhF17BwWGC3WRakM QLlJmUWJU66aczeTC43Sg7ZfSgX+fYx8V5Uyoumm1fAJcmevAnVXTVggusJlhq5uw6W6 wlbMCafbFRiK4zU9xAG72ADn6XAq2P2ohyAO2G18kchxzD0zTsI0Ln7AQ1S+8mxhH8BM C/8eJ6z55jWl6t/GN6MpNJjvG10dtPlY1xlYnLCR6GvgpGFxmYM9bSVOYKRt3W0id7mr On6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=GRnQMzrXugBFolyNY4ucJzpNfifkIVkFNz2791+j6t4=; fh=xc5gbk/fV5lpm8YAtFD9GA7yuEn3IfzAJVxk9pym034=; b=Et4s9P5edKotdVQmGoPxzaA6JJb7Xa+8kqVPZh9W/XtK78pya1Bk+BnlSXVXldA7oA 24F/7vsMB/ZiooYJ6V62DkzUUZ0zG/8fglxpAtm/dW9Q+F8ze32nGTapu2iO4i91JEzZ qDnhrNufUsaPJNVClw3tGOi9ols+ovxQask6sxNUg76GYzNShcCPwPQAN95xwYBtbU4z cIcgTxE4MFQY0VXFPoIIiZ5/389q6+2FmDqTBMmFr+AKaSwvZpvft9Ni7d9HJfpv2GbX h24rw0g7JFoc6pOKhAvgPGDdmeNH43ErIA7wgJDfi9r8kR6hxCrou9qiDfXf5P+f5WBH w/rg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=V7sPz6UQ; spf=pass (google.com: domain of linux-kernel+bounces-22561-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-22561-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id gh5-20020a170906e08500b00a298de0d4f3si1923307ejb.381.2024.01.10.09.50.03 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jan 2024 09:50:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-22561-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=V7sPz6UQ; spf=pass (google.com: domain of linux-kernel+bounces-22561-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-22561-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 6DFCC1F2990C for ; Wed, 10 Jan 2024 17:50:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 177EC4D131; Wed, 10 Jan 2024 17:49:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="V7sPz6UQ" Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB6134D130 for ; Wed, 10 Jan 2024 17:49:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704908985; x=1736444985; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Y3tMaRHrNobztAav5ypuwIp4QVL+27VKqJqu4MQ0v50=; b=V7sPz6UQsT/Z+DCgRIDNgsK8goV8gESCOLo4/dcsg8yqxQhmNS/KbmTb ZZQYVv5Ger8S6SB+hatHfZ8G1YMYYtM/x5AG8/1pdJp7vIdMg+ESZkdKa aMrGQrjmfcDEo/Bey4CPJGhuoOp9oZ+988R5SztzCD3rBL3LhCeFzRc0t hAfmV6nZ9MlQ1l/edMzGEALbqh9fIMsjkZePn17G50eozeJ08Zxx6LLAe 7m5F1LcqgtsfCyRXpXLKmDI8rgzrnvT6tjCE0xA0jUzmdDlbfsDijN2Ep NrZMs6dHVI2aPBBuTiaRL8KXrmHmBOklQecoKzjGoWTLwSFcjUKLBoMuo w==; X-IronPort-AV: E=McAfee;i="6600,9927,10949"; a="402373794" X-IronPort-AV: E=Sophos;i="6.04,184,1695711600"; d="scan'208";a="402373794" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2024 09:49:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,184,1695711600"; d="scan'208";a="30687266" Received: from tassilo.jf.intel.com (HELO tassilo) ([10.54.38.190]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2024 09:49:46 -0800 Date: Wed, 10 Jan 2024 09:49:44 -0800 From: Andi Kleen To: Kevin Loughlin Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Rick Edgecombe , Kees Cook , "Masami Hiramatsu (Google)" , Ze Gao , Josh Poimboeuf , Pengfei Xu , Brijesh Singh , Michael Roth , Ashish Kalra , "Kirill A. Shutemov" , Tom Lendacky , Joerg Roedel , linux-kernel@vger.kernel.org, llvm@lists.linux.dev, linux-coco@lists.linux.dev, Adam Dunlap , Peter Gonda , Jacob Xu , Sidharth Telang Subject: Re: [RFC PATCH] x86/sev: x86/sev: enforce PC-relative addressing in clang Message-ID: References: <20240110012640.1335694-1-kevinloughlin@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: > On that note, I do have another version of this patch that abstracts > snp_cpuid_get_table() into a macro along the lines of... > > #define GET_RIP_RELATIVE_PTR(var) \ > ({ \ > void *ptr; \ > asm ("lea "#var"(%%rip), %0" \ > : "=r" (ptr) \ > : "p" (&var)); \ > ptr; \ > }) > > ...and uses this new macro to access all SEV/SME global variables (not > just the cpuid_table). It's similar in nature to `fixup_pointer()` > (currently defined in arch/x86/kernel/head64.c) but doesn't require us > to pass around `physaddr` from `__startup64()`. This wouldn't > introduce any new execution model changes between clang vs gcc and > would be consistent with the kernel's current approach of relying on > developers to manually apply fixups for global variable accesses prior > to kernel relocation. I can send an RFC v2 for the > GET_RIP_RELATIVE_PTR() version of this patch. That looks like a far better solution indeed. Ideally objtool would check for this, perhaps with a new ELF section. But actually doing that might be far more work, so perhaps not worth it. Thanks, -Andi