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 C6F472BAF7; Mon, 15 Jan 2024 10:12:52 +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="SITVhrct" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1705313572; x=1736849572; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=MEptrc0fT+8LksarjLhrGDoVU7ynwzFrpAwX1CpyhrM=; b=SITVhrctcssEHP9cN+G/XXQ+/QH6E6AYEJVoGRrVXyf/Qa4p5msug2d0 UZd+SXCcTDLXi9/vXjGOWSOvWIYX68xpgrrR2CKLbh5kkwfqU8Vi9e6p+ v7l12GDgmIpALbkZNbVHld/TvZEP+IZy9FY7SsJFo2yf+/tqpWadFBEvq omxGsciAKT5d3RGQjwx0Yp5a9RkIR2tbv/QYDzzRxYueKBkxX49mL0E4g G1RvTANQ38u+Xas8sPXQVSUQ/5LXJZh9q4ZvDHLrh/P8KN4izNR8X7gjZ HFTKVD1qcC3wI9dyPlieDxs9znrNu7KH72kGcZLc1wPUejMpCk8paD/te A==; X-IronPort-AV: E=McAfee;i="6600,9927,10953"; a="403343252" X-IronPort-AV: E=Sophos;i="6.04,196,1695711600"; d="scan'208";a="403343252" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2024 02:12:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10953"; a="853957004" X-IronPort-AV: E=Sophos;i="6.04,196,1695711600"; d="scan'208";a="853957004" Received: from jeroenke-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.55.160]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2024 02:12:42 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id 93EE910A58F; Mon, 15 Jan 2024 13:12:39 +0300 (+03) Date: Mon, 15 Jan 2024 13:12:39 +0300 From: "Kirill A. Shutemov" 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 , Tom Lendacky , Michael Kelley , Pankaj Gupta , Stephen Rothwell , Arnd Bergmann , Steve Rutherford , Alexander Shishkin , Hou Wenlong , Vegard Nossum , Josh Poimboeuf , Yuntao Wang , Wang Jinchao , David Woodhouse , Brian Gerst , Hugh Dickins , Ard Biesheuvel , Joerg Roedel , Randy Dunlap , Bjorn Helgaas , Dionna Glaze , Brijesh Singh , Michael Roth , linux-kernel@vger.kernel.org, llvm@lists.linux.dev, linux-coco@lists.linux.dev, Ashish Kalra , Andi Kleen , Adam Dunlap , Peter Gonda , Jacob Xu , Sidharth Telang Subject: Re: [RFC PATCH v2] x86/sev: enforce RIP-relative accesses in early SEV/SME code Message-ID: <20240115101239.nab725vuazvutgw6@box.shutemov.name> References: <20240111223650.3502633-1-kevinloughlin@google.com> <20240112121725.3amxlumpifhagamb@box> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Jan 12, 2024 at 10:29:36AM -0800, Kevin Loughlin wrote: > On Fri, Jan 12, 2024 at 4:17 AM Kirill A. Shutemov > wrote: > > > > Can we replace existing fixup_pointer() (and other fixup_*()) with the new > > thing? I don't think we need two confusing things for the same function. > > Per my tests, yes we can; I replaced the fixup_*() functions with > GET_RIP_RELATIVE_PTR()/PTR_TO_RIP_RELATIVE_PTR(), and guests with and > without SEV, SEV-ES, and SEV-SNP all successfully booted under both > clang and gcc builds. Okay good. BTW, do we need both macros? Caller can do &var, right? If we are okay with single macro, maybe rename it to RIP_RELATIVE_PTR(). One other thing: I see you sprinkle casts to for every use of the macros. But why? void* can cast to any other pointer without explicit casting. > I have a slight preference for sending that as a > separate follow-up commit, but please let me know if you feel > differently. Thanks. I'm okay with a separate patch in the same patchset. > > > Also, is there any reason why GET_RIP_RELATIVE_PTR() and > > PTR_TO_RIP_RELATIVE_PTR() have to be macros? Inline functions would be > > cleaner. > > I used macros because we need to use both the global variable itself > and the global variable's string name (obtained via #var in the macro) > in the inline assembly. As a secondary reason, the macro also avoids > the need to provide separate functions for each type of variable for > which we'd like to get RIP-relative pointers (ex: u64, unsigned int, > unsigned long, etc.). If we do it only on pointers, wouldn't void * -> void * be enough? -- Kiryl Shutsemau / Kirill A. Shutemov