From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C2201AAA6 for ; Fri, 12 Jan 2024 18:29:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ax9IqFwR" Received: by mail-ua1-f54.google.com with SMTP id a1e0cc1a2514c-7cbeaacbcb8so1763175241.0 for ; Fri, 12 Jan 2024 10:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705084187; x=1705688987; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Y1csma4A5U64O+REmW+zu6/PA7desA13VUuUwLGfC3Q=; b=ax9IqFwRO3QGLemyprcJ05Br5v2R+yrGerWiG19J92TsZdNQuurXSijiKvN9ogphaI smtnUS+zjFpWbjLUaEEf5gA5o78RtuQZPnG/w0/AfbQpBCYKFFEdLf79fSsEvW9Fp04q PGtrFWbH/mojmlAqcm58TMqBZULxH9wyvOUCSc7nw3t/2vLrlf0wEAwdT3W0jg3Vxc8U 4O2YPY2qFUg/BiIZ99hY85O1MM58DJ71MLRbcR9yFpCJ6m8wXLHgsphrzIhcjmrrzcLX +r+8B9JqUC7PdkZ66apdV5F7bN+OWH9Nj7cNSSq7Y2ssb0DZ0DajOF/0cf9JcMpMJCxU xq4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705084187; x=1705688987; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Y1csma4A5U64O+REmW+zu6/PA7desA13VUuUwLGfC3Q=; b=WOBINi+GMsPhC47u4k6v3Ys3rhxWeb2pkFlltI/TYegXeEo1h2zGMLd2lBE+0Ygpzm V3rXMeLwJkPuFLRMZ/g+oR+Bx2zYB4FS+nOfe2gMVxrBFGkvyMkDWIj76i0b2rhhHCF6 tHQHn50XMK3yyr/qFNbGMIajzo2Q6S9DHxey6ftHsIG4YXwqXmhkS+2EI3AI+ChLMhoX FpeTLyMzDJpNt7pJdLX2COaBcFL8PwNf9XQpip+lRlGu+x8W6ovaM9R02aQGK6LrB8h3 7c72O+GKxxlcuj2m5iMthxoszgdOfOkVr7x14Xu5TyX7M4jLyuddM6bO1eL25dfiLWxZ RxPg== X-Gm-Message-State: AOJu0Yzl2VLCBQFM17qVx57jitedHKZEcBzbGYDEtfZ4tWbYfRtSrG0E 0G64TD2kM6Rvw8JY5m9CWEctIsRC5GNUYQoNaO/mCYmxIWab X-Google-Smtp-Source: AGHT+IFbEsPC+6pQYmKgmUdqKvTP1jQV+FRoiuzD78v/fDaV2RhMwCdQ3K00zV5/Vj8TA9sq36+8X1YIL/ffox626bo= X-Received: by 2002:a05:6122:3809:b0:4b6:f254:b234 with SMTP id em9-20020a056122380900b004b6f254b234mr1441346vkb.32.1705084187287; Fri, 12 Jan 2024 10:29:47 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240111223650.3502633-1-kevinloughlin@google.com> <20240112121725.3amxlumpifhagamb@box> In-Reply-To: <20240112121725.3amxlumpifhagamb@box> From: Kevin Loughlin Date: Fri, 12 Jan 2024 10:29:36 -0800 Message-ID: Subject: Re: [RFC PATCH v2] x86/sev: enforce RIP-relative accesses in early SEV/SME code To: "Kirill A. Shutemov" 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 12, 2024 at 4:17=E2=80=AFAM Kirill A. Shutemov wrote: > > Can we replace existing fixup_pointer() (and other fixup_*()) with the ne= w > 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. I have a slight preference for sending that as a separate follow-up commit, but please let me know if you feel differently. Thanks. > 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.).