From mboxrd@z Thu Jan 1 00:00:00 1970 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 EB5F14D12F; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="V7sPz6UQ" 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="402373800" X-IronPort-AV: E=Sophos;i="6.04,184,1695711600"; d="scan'208";a="402373800" 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-coco@lists.linux.dev 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