linux-kernel - Re: [tip:x86/urgent] x86/boot/64: Use 'push' instead of 'call' in start

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 14 Dec 2016 14:13:20 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     hpa@...or.com
Cc:     linux-tip-commits@...r.kernel.org,
        tip-bot for Josh Poimboeuf <tipbot@...or.com>,
        linux-kernel@...r.kernel.org, bp@...en8.de, tglx@...utronix.de,
        torvalds@...ux-foundation.org, peterz@...radead.org,
        luto@...nel.org, mingo@...nel.org, brgerst@...il.com,
        dvlasenk@...hat.com
Subject: Re: [tip:x86/urgent] x86/boot/64: Use 'push' instead of 'call' in
 start_cpu()

On Wed, Dec 14, 2016 at 11:24:19AM -0800, hpa@...or.com wrote:
> On December 14, 2016 12:36:58 AM PST, tip-bot for Josh Poimboeuf <tipbot@...or.com> wrote:
> >diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> >index 90de288..1facaf4 100644
> >--- a/arch/x86/kernel/head_64.S
> >+++ b/arch/x86/kernel/head_64.S
> >@@ -298,7 +298,7 @@ ENTRY(start_cpu)
> > 	 *	REX.W + FF /5 JMP m16:64 Jump far, absolute indirect,
> > 	 *		address given in m16:64.
> > 	 */
> >-	call	1f		# put return address on stack for unwinder
> >+	pushq	$1f		# put return address on stack for unwinder
> > 1:	xorq	%rbp, %rbp	# clear frame pointer
> > 	movq	initial_code(%rip), %rax
> > 	pushq	$__KERNEL_CS	# set correct cs
> 
> This adds another relocation to the kernel.  I hope this is safe at this point in the code?

AFAIK, it should be fine.  All relocations were either applied at build
time, or for KASLR, in the compressed boot code which extracts and
copies this code.

Also there are already a bunch of relocations in the rest of the code in
this file, all of which runs before this code does.

(And even if that weren't the case, this address is only used for
displaying stack traces, so pushing a zero or some garbage here wouldn't
really break anything.)

-- 
Josh