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] [thread-next>] [day] [month] [year] [list]
Message-ID: <YjiqgPL+pPGkOgCv@hirez.programming.kicks-ass.net>
Date:   Mon, 21 Mar 2022 17:40:32 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        mhiramat@...nel.org, ast@...nel.org, hjl.tools@...il.com,
        rick.p.edgecombe@...el.com, rppt@...nel.org,
        linux-toolchains@...r.kernel.org, Andrew.Cooper3@...rix.com,
        ndesaulniers@...gle.com
Subject: Re: linux-next: build warnings after merge of the tip tree

On Mon, Mar 21, 2022 at 12:15:49PM -0400, Steven Rostedt wrote:
> On Mon, 21 Mar 2022 12:12:09 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > > > funcB:
> > > > 	call __fentry__    
> > > 			push funcB on trace-stack  
> > > > 
> > > > 	[..]    
> > > 	call __fexit__
> > > 			pop trace-stack until empty
> > > 			  'exit funcB'
> > > 			  'exit funcA'  
> > 
> > And what happens if funcC called funcA and it too was on the stack. We pop
> > that too? But it's not done yet, because calling of funcA was not a tail
> > call.

Hmm, yeah, how about we have __ftail__ mark the left function.

func_B()
{
	...
}

func_A()
{
	...
	return func_B();
}

func_C()
{
	func_A();
	...
	return;
}

func_B:
	call __fentry__	/* push func_B */
	...
	call __fexit__	/* pop 1 + tails */
	ret

func_A:
	call __fentry__ /* push func_A */
	...
	call __ftail__  /* mark func_A tail */
	jmp func_B

func_C:
	call __fentry__ /* push func_C */
	call func_A;
	...
	call __fexit__  /* pop 1 + tails */
	ret;


Then the stack at the end of func_B looks something like:

	func_C
	func_A (tail)
	func_B

And it will pop func_B plus all tails (func_A).

> And I just thought of another issue, where even my solution wont fix it.
> What happens if we trace funcA but not funcB? How do we get to trace the
> end of funcA?

Disallow tail calls to notrace?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ