From nobody Thu Jan 30 19:11:44 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C78991FC7F9 for ; Mon, 27 Jan 2025 10:20:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737973231; cv=none; b=WMQYusoK9RY1pX+gKkGtM16YMeeJEd77HJ/4xv/N0buewKo4CHA+Pr9P9q7rcfzGzFo6++1gNnNgh/KoncUKX7apOSXRoXwLoPxSGTkBIh4l9ntVolgVlClksBkfcl7akvLs0CSAjqdj+BfGx5iGp8rPYm+DZf12sNqU5L0E9F0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737973231; c=relaxed/simple; bh=vEWnip283woV5DWBDu2Yc3mY2N1co0dBumszt82taj8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZL/Dkqxbl0nwVPJ4R+a+wXThIrEKK6oCYIhjPN1XadtaiaqK7jzsG4X/5xfO1uS9uArBrbUGBiPNJiGMsx0UIt/48DC6vYKdmOxC1/l3CxiUKBAmDTF5xeLSuPwyWmkoC2TC7nZWavvRE6oBf2Ri5a0+GWnuMl8TbjkFfg6MAME= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hQmZAloB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hQmZAloB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 637C6C4CED2; Mon, 27 Jan 2025 10:20:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737973231; bh=vEWnip283woV5DWBDu2Yc3mY2N1co0dBumszt82taj8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hQmZAloBdczwUWIZYwnnLyFXqkKqD83ZR8wz4aaxqi+uvYmFoF1cnsyUJ0O8nh+K5 xFm/b46SP9Xo1r8dM2FDVaWXZKENq/5xQQ6XQbvrQ7JuEuQcOtG+y3v5w5ItAUrPen bXiNrdb//SOu5yj8iXw9g2B5ccfp55z++gQhnRcnOqyB+4jLWHMkuMEnOZmKz5hrSC bZtn8XRfwPPmVwf6XzNr3XUFsWNhpMrW/cS7GGSoHXMmXGYyZkGLC1CdR776QQl4y9 QekCFBwWebHp3pAQ4Y5+Gh1dUxzBZcJsXNS/d1jVXYRmwuL3/xJbtOYDdwrrZdSWVs lbrvbCelTTDww== Date: Mon, 27 Jan 2025 11:20:21 +0100 From: Ingo Molnar To: Linus Torvalds Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, the arch/x86 maintainers , David Woodhouse , Peter Zijlstra , "H. Peter Anvin" Subject: [PATCH] Revert "x86/boot: Reject absolute references in .head.text Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" * Linus Torvalds wrote: > On Tue, 21 Jan 2025 at 13:29, Ingo Molnar wrote: > > > > - A series to remove the last remaining absolute symbol references from > > .head.text, and enforce this at build time, by Ard Biesheuvel: > > [...] > > - Which build-time enforcement uncovered a handful of bugs of essentia= lly > > non-working code, and a wrokaround for a toolchain bug, fixed by > > Ard Biesheuvel as well: > > > > - Fix spurious undefined reference when CONFIG_X86_5LEVEL=3Dn, on= GCC-12 > > - Disable UBSAN on SEV code that may execute very early > > - Disable ftrace branch profiling in SEV startup code >=20 > Bah. I only noticed this today, because I was on the road part of the > week and didn't do my usual "build with clang". >=20 > But this is broken with my normal clang config, and I get a very > unhelpful error message: >=20 > Absolute reference to symbol '.rodata' not permitted in .head.text >=20 > and I have no idea why, or where it comes from. And that error > message doesn't specify enough information for me to even *guess* at > what's going on. >=20 > And bisecting it obviously just points at faf0ed487415 ("x86/boot: > Reject absolute references in .head.text"), since it's just a random > new check for an old issue. >=20 > New random rule, with new random error as a result, and totally opaque > to anybody else than Ard. >=20 > Useless crap, in other words. >=20 > Why isn't the fix a revert? Because that error message is really bad. > It needs to tell me where things went wrong, not just a "You're effed. > Ha! Ha!". >=20 > And to add insult to injury, all of this is done in-place on the > vmlinux file, so when it all fails, make does >=20 > make[2]: *** Deleting file 'vmlinux' >=20 > and doesn't even leave behind anything to look at. Sorry about that - I was really hoping we'd never see this arguably=20 maximally passive-aggressive message and build failure, as the patch=20 has lived in -next for 1.5 months, but here we go ... > Anyway, that check needs to either >=20 > (a) die a painful death very quickly >=20 > (b) be made to actually print out useful information of WHERE the > relocation comes from and WHERE it points to I'd go for (a)+(b): I've queued up a revert which I'll send to you in a=20 few hours, so (b) can be done properly. Also feel free to queue up the=20 revert directly: Acked-by: Ingo Molnar I'd even argue that (b) should first be a non-fatal and 100% helpful=20 message in a standard build warning format so that CI bots pick it up,=20 and then in a kernel release or two we can do (c) that does the hard=20 build failure ... Thanks, Ingo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D> From: Ingo Molnar Date: Mon, 27 Jan 2025 11:08:14 +0100 Subject: [PATCH] Revert "x86/boot: Reject absolute references in .head.text" This reverts commit faf0ed487415f76fe4acf7980ce360901f5e1698. As Linus reported, the hard build failure is entirely unhelpful in tracking down the bug: Absolute reference to symbol '.rodata' not permitted in .head.text ... and to add insult to injury, the offending vmlinux gets deleted, making it hard to figure out what's going on ... So revert this until a (much) more developer-friendly version is merged. Reported-by: Linus Torvalds Cc: Ard Biesheuvel Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/CAHk-=3Dwj7k9nvJn6cpa3-5Ciwn2RGyE605BMkjWE4= MqnvC9E92A@mail.gmail.com --- arch/x86/tools/relocs.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index e937be979ec8..27441e5863b2 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -841,10 +841,10 @@ static int is_percpu_sym(ElfW(Sym) *sym, const char *= symname) static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym, const char *symname) { - int headtext =3D !strcmp(sec_name(sec->shdr.sh_info), ".head.text"); unsigned r_type =3D ELF64_R_TYPE(rel->r_info); ElfW(Addr) offset =3D rel->r_offset; int shn_abs =3D (sym->st_shndx =3D=3D SHN_ABS) && !is_reloc(S_REL, symnam= e); + if (sym->st_shndx =3D=3D SHN_UNDEF) return 0; =20 @@ -900,12 +900,6 @@ static int do_reloc64(struct section *sec, Elf_Rel *re= l, ElfW(Sym) *sym, break; } =20 - if (headtext) { - die("Absolute reference to symbol '%s' not permitted in .head.text\n", - symname); - break; - } - /* * Relocation offsets for 64 bit kernels are output * as 32 bits and sign extended back to 64 bits when