lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241001053318.elfwwiyluw6rlynz@treble>
Date: Mon, 30 Sep 2024 22:33:18 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Ard Biesheuvel <ardb+git@...gle.com>
Cc: linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
	x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Uros Bizjak <ubizjak@...il.com>, Dennis Zhou <dennis@...nel.org>,
	Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	Juergen Gross <jgross@...e.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Masahiro Yamada <masahiroy@...nel.org>, Kees Cook <kees@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Keith Packard <keithp@...thp.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
	Ian Rogers <irogers@...gle.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Kan Liang <kan.liang@...ux.intel.com>, linux-doc@...r.kernel.org,
	linux-pm@...r.kernel.org, kvm@...r.kernel.org,
	xen-devel@...ts.xenproject.org, linux-efi@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-sparse@...r.kernel.org,
	linux-kbuild@...r.kernel.org, linux-perf-users@...r.kernel.org,
	rust-for-linux@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [RFC PATCH 04/28] x86/boot: Permit GOTPCREL relocations for
 x86_64 builds

On Wed, Sep 25, 2024 at 05:01:04PM +0200, Ard Biesheuvel wrote:
> +		if (r_type == R_X86_64_GOTPCREL) {
> +			Elf_Shdr *s = &secs[sec->shdr.sh_info].shdr;
> +			unsigned file_off = offset - s->sh_addr + s->sh_offset;
> +
> +			/*
> +			 * GOTPCREL relocations refer to instructions that load
> +			 * a 64-bit address via a 32-bit relative reference to
> +			 * the GOT.  In this case, it is the GOT entry that
> +			 * needs to be fixed up, not the immediate offset in
> +			 * the opcode. Note that the linker will have applied an
> +			 * addend of -4 to compensate for the delta between the
> +			 * relocation offset and the value of RIP when the
> +			 * instruction executes, and this needs to be backed out
> +			 * again. (Addends other than -4 are permitted in
> +			 * principle, but make no sense in practice so they are
> +			 * not supported.)
> +                         */
> +			if (rel->r_addend != -4) {
> +				die("invalid addend (%ld) for %s relocation: %s\n",
> +				    rel->r_addend, rel_type(r_type), symname);
> +				break;
> +			}

For x86 PC-relative addressing, the addend is <reloc offset> -
<subsequent insn offset>.  So a PC-relative addend can be something
other than -4 when the relocation applies to the middle of an
instruction, e.g.:

   5b381:	66 81 3d 00 00 00 00 01 06 	cmpw   $0x601,0x0(%rip)        # 5b38a <generic_validate_add_page+0x4a>	5b384: R_X86_64_PC32	boot_cpu_data-0x6

   5f283:	81 3d 00 00 00 00 ff ff ff 00 	cmpl   $0xffffff,0x0(%rip)        # 5f28d <x86_acpi_suspend_lowlevel+0x9d>	5f285: R_X86_64_PC32	smpboot_control-0x8

   72f67:       c6 05 00 00 00 00 01    movb   $0x1,0x0(%rip)        # 72f6e <sched_itmt_update_handler+0x6e>   72f69: R_X86_64_PC32    x86_topology_update-0x5

Presumably that could also happen with R_X86_64_GOTPCREL?

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ