linux-kernel - Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

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]

Date:	Wed, 27 Jul 2016 21:58:25 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

On Wed, 27 Jul 2016 16:00:54 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> I can just add a
> 
>   KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)

I like this solution.

> 
> in the main Makefile, and that is indeed what I have in my tree right
> now and will likely commit soon. The warning isn't actually helpful
> for us, and there doesn't seem to be any other way to turn it off. At
> the same time, there is a somewhat valid reason for that warning
> existing, so I'm wondering if the tracing code could perhaps try to
> change.
> 
> I detest having lots of warnings when doing my test builds, because
> the uninteresting warnings often hide real ones that might actually
> matter.
> 
> Comments?

We are well aware of the danger of using __builtin_return_address() of
 > 0. In fact that's part of the reason for having the "thunk" code in
x86 (See arch/x86/entry/thunk_{64,32}.S). Because it adds extra frames
when tracking irqs off sections, to prevent the
__builtin_return_address() from accessing bad areas. In fact the
thunk_32.S states: "Trampoline to trace irqs off. (otherwise
CALLER_ADDR1 might crash)".

Now if we can get a better fast arch generic way of getting the same
information, we could switch to that. Perhaps the wakeup tracing could
use part of stacktrace, as that's not as high volume as the irq tracing
is. But the irq tracing does this at every instance interrupts are
disabled and enabled. A bit too much impact on the system to be calling
into the stack trace code every time interrupts are disable or enabled.

I can still look to see if that information is even useful, as we do a
stack dump when we find a new max latency.

-- Steve