From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out187-20.us.a.mail.aliyun.com (out187-20.us.a.mail.aliyun.com [47.90.187.20]) (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 72DF217E9; Wed, 17 Jan 2024 02:52:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=47.90.187.20 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705459965; cv=none; b=DBejKltHi9fxjetMuNfRUtm9FopKOl70rK5+ARTocUN2hNFZi1oF1PT6BPacMUBncDvM8R20yqfY0QVWJsRrhXqnfMMr/28g3XvZcqj3OXsVtk+SM06DWBRClg25VRBGjQSi80TcfosymaI4dMJgvWKwWXtLEFSVJ0Dlg/R+4Jg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705459965; c=relaxed/simple; bh=f2vOvPOp7ODqJoWpEW+g6YZ4ClQrHu8xwoToqzW/ISo=; h=X-Alimail-AntiSpam:Received:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:In-Reply-To:User-Agent; b=CxS2EHr6SWlGVx7sOolLTYlAtypf9DmShQ3igtT2SmfmJtCK7VltRhR7QyXDEu0yxam/AJWNMQed7ZFaM0WoQTmrivM4BU4o90t1YCPh55+3HSAdYaowU+XRWA0VgVjLtht2uhAGduh3CAwzbSzKyawufIuaFXQXknu6RsN40IE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=antgroup.com; spf=pass smtp.mailfrom=antgroup.com; arc=none smtp.client-ip=47.90.187.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=antgroup.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=antgroup.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R581e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018047212;MF=houwenlong.hwl@antgroup.com;NM=1;PH=DS;RN=44;SR=0;TI=SMTPD_---.W8.S.yY_1705459622; Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.W8.S.yY_1705459622) by smtp.aliyun-inc.com; Wed, 17 Jan 2024 10:47:04 +0800 Date: Wed, 17 Jan 2024 10:47:02 +0800 From: "Hou Wenlong" To: Kevin Loughlin Cc: Borislav Petkov , Thomas Gleixner , Ingo Molnar , 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 , 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 , "Kirill A. Shutemov" , 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: <20240117024702.GA112065@k08j02272.eu95sqa> References: <20240111223650.3502633-1-kevinloughlin@google.com> <20240115204634.GHZaWZqsVyU_fvn_RW@fat_crate.local> 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: User-Agent: Mutt/1.5.21 (2010-09-15) On Wed, Jan 17, 2024 at 08:07:49AM +0800, Kevin Loughlin wrote: > On Mon, Jan 15, 2024 at 12:47 PM Borislav Petkov wrote: > > > > On Thu, Jan 11, 2024 at 10:36:50PM +0000, Kevin Loughlin wrote: > > > SEV/SME code can execute prior to page table fixups for kernel > > > relocation. However, as with global variables accessed in > > > __startup_64(), the compiler is not required to generate RIP-relative > > > accesses for SEV/SME global variables, causing certain flavors of SEV > > > hosts and guests built with clang to crash during boot. > > > > So, about that. If I understand my gcc toolchain folks correctly: > > > > mcmodel=kernel - everything fits into the high 31 bit of the address > > space > > > > -fPIE/PIC - position independent > > > > And supplied both don't make a whole lotta of sense: if you're building > > position-independent, then mcmodel=kernel would be overridden by the > > first. > > > > I have no clue why clang enabled it... > > > > So, *actually* the proper fix here should be not to add this "fixed_up" > > gunk everywhere but remove mcmodel=kernel from the build and simply do > > -fPIE/PIC. > > I believe that the key distinction is that using mcmodel=kernel (upper > 2 GB of address space) or the similar mcmodel=small (lower 2 GB) means > the compiler *can* use RIP-relative addressing for globals (because > everything is within +/- 2GB of RIP) but is not *required* to do so. > In contrast, fPIE/fPIC *requires* relative addressing but does not > necessarily require a specific 2 GB placement range. Altogether, I do > think there are use cases for both options individually. I can't think > of a reason why gcc wouldn't be able to support mcmodel=kernel in > conjunction with fPIE off the top of my head, but I admittedly haven't > looked into it; I simply observed that the combination is not > currently supported. > > RE: compiling the whole x86-64 kernel with fPIE/fPIC, I believe the > required changes would be very extensive (see "[PATCH RFC 00/43] > x86/pie: Make kernel image's virtual address flexible" at > https://lore.kernel.org/lkml/cover.1682673542.git.houwenlong.hwl@antgroup.com/). FYI I have sent a small patchset[0] that attempts to build the head code (head64.c and mem_encrypt_identity.c) as PIE. However, there are still a few functions that are called by the head code but are not in these two files. [0] https://lore.kernel.org/lkml/cover.1689130310.git.houwenlong.hwl@antgroup.com