From: Mathias Krause <minipli@grsecurity.net>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Andrew Jones <andrew.jones@linux.dev>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Eric Auger <eric.auger@redhat.com>,
Thomas Huth <thuth@redhat.com>,
kvm@vger.kernel.org, kvmarm@lists.linux.dev
Subject: Re: [kvm-unit-tests PATCH v2 2/4] x86: Better backtraces for leaf functions
Date: Fri, 10 Oct 2025 08:03:58 +0200 [thread overview]
Message-ID: <47d87ba2-83c1-4a0d-ba8a-cc7adc2b105c@grsecurity.net> (raw)
In-Reply-To: <20250915215432.362444-3-minipli@grsecurity.net>
On 9/15/25 23:54, Mathias Krause wrote:
> Leaf functions are problematic for backtraces as they lack the frame
> pointer setup epilogue. If such a function causes a fault, the original
> caller won't be part of the backtrace. That's problematic if, for
> example, memcpy() is failing because it got passed a bad pointer. The
> generated backtrace will look like this, providing no clue what the
> issue may be:
>
> STACK: @401b31 4001ad
> 0x0000000000401b31: memcpy at lib/string.c:136 (discriminator 3)
> for (i = 0; i < n; ++i)
> > a[i] = b[i];
>
> 0x00000000004001ac: gdt32_end at x86/cstart64.S:127
> lea __environ(%rip), %rdx
> > call main
> mov %eax, %edi
>
> By abusing profiling, we can force the compiler to emit a frame pointer
> setup epilogue even for leaf functions, making the above backtrace
> change like this:
>
> STACK: @401c21 400512 4001ad
> 0x0000000000401c21: memcpy at lib/string.c:136 (discriminator 3)
> for (i = 0; i < n; ++i)
> > a[i] = b[i];
>
> 0x0000000000400511: main at x86/hypercall.c:91 (discriminator 24)
>
> > memcpy((void *)~0xbadc0de, (void *)0xdeadbeef, 42);
>
> 0x00000000004001ac: gdt32_end at x86/cstart64.S:127
> lea __environ(%rip), %rdx
> > call main
> mov %eax, %edi
>
> Above backtrace includes the failing memcpy() call, making it much
> easier to spot the bug.
>
> Enable "fake profiling" if supported by the compiler to get better
> backtraces. The runtime overhead should be negligible for the gained
> debugability as the profiling call is actually a NOP.
>
> Signed-off-by: Mathias Krause <minipli@grsecurity.net>
> ---
> One may argure that the "ifneq ($(KEEP_FRAME_POINTER),) ... endif"
> wrapping isn't needed, and that's true. However, it simplifies toggling
> that variable, if there'll ever be a need for it.
>
> x86/Makefile.common | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/x86/Makefile.common b/x86/Makefile.common
> index 5663a65d3df4..be18a77a779e 100644
> --- a/x86/Makefile.common
> +++ b/x86/Makefile.common
> @@ -43,6 +43,17 @@ COMMON_CFLAGS += -O1
> # stack.o relies on frame pointers.
> KEEP_FRAME_POINTER := y
>
> +ifneq ($(KEEP_FRAME_POINTER),)
> +# Fake profiling to force the compiler to emit a frame pointer setup also in
> +# leaf function (-mno-omit-leaf-frame-pointer doesn't work, unfortunately).
> +#
> +# Note:
> +# We need to defer the cc-option test until -fno-pic or -no-pie have been
> +# added to CFLAGS as -mnop-mcount needs it. The lazy evaluation of CFLAGS
> +# during compilation makes this do "The Right Thing."
> +LATE_CFLAGS += $(call cc-option, -pg -mnop-mcount, "")
> +endif
> +
> FLATLIBS = lib/libcflat.a
>
> ifeq ($(CONFIG_EFI),y)
Paolo, can you please comment on this one, so the fixes for ARM and
AArch64 are no longer blocked and, ideally, this series can be merged?
Thanks,
Mathias
next prev parent reply other threads:[~2025-10-10 6:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 21:54 [kvm-unit-tests PATCH v2 0/4] Better backtraces for leaf functions Mathias Krause
2025-09-15 21:54 ` [kvm-unit-tests PATCH v2 1/4] Makefile: Provide a concept of late CFLAGS Mathias Krause
2025-09-15 21:54 ` [kvm-unit-tests PATCH v2 2/4] x86: Better backtraces for leaf functions Mathias Krause
2025-10-10 6:03 ` Mathias Krause [this message]
2025-09-15 21:54 ` [kvm-unit-tests PATCH v2 3/4] arm64: " Mathias Krause
2025-09-15 21:54 ` [kvm-unit-tests PATCH v2 4/4] arm: Fix backtraces involving " Mathias Krause
2025-09-16 13:04 ` [kvm-unit-tests PATCH v2 0/4] Better backtraces for " Andrew Jones
2025-11-14 15:58 ` Mathias Krause
2025-11-14 16:39 ` Sean Christopherson
2025-11-14 18:25 ` Sean Christopherson
2025-11-15 4:56 ` Mathias Krause
2025-11-17 22:19 ` Sean Christopherson
2025-11-18 1:33 ` Mathias Krause
2025-11-18 1:47 ` Mathias Krause
2025-11-18 4:04 ` Mathias Krause
2025-11-18 11:56 ` Mathias Krause
2025-11-18 12:10 ` Mathias Krause
2025-11-21 16:44 ` Mathias Krause
2025-12-18 1:44 ` Sean Christopherson
2025-12-18 10:07 ` Mathias Krause
2025-12-18 18:26 ` Sean Christopherson
2025-12-19 13:19 ` Mathias Krause
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47d87ba2-83c1-4a0d-ba8a-cc7adc2b105c@grsecurity.net \
--to=minipli@grsecurity.net \
--cc=alexandru.elisei@arm.com \
--cc=andrew.jones@linux.dev \
--cc=eric.auger@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=pbonzini@redhat.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox