Linux KVM/arm64 development list
 help / color / mirror / Atom feed
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

  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