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:   Mon, 18 Jul 2022 10:57:31 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Li Huafei <lihuafei1@...wei.com>
Cc:     linux@...linux.org.uk, rmk+kernel@...linux.org.uk, ardb@...nel.org,
        will@...nel.org, mark.rutland@....com, broonie@...nel.org,
        peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
        alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
        namhyung@...nel.org, arnd@...db.de, rostedt@...dmis.org,
        nick.hawkins@....com, john@...ozen.org, mhiramat@...nel.org,
        ast@...nel.org, linyujun809@...wei.com, ndesaulniers@...gle.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 1/5] ARM: stacktrace: Skip frame pointer boundary check
 for call_with_stack()

On Tue, Jul 12, 2022 at 4:18 AM Li Huafei <lihuafei1@...wei.com> wrote:

> When using the frame pointer unwinder, it was found that the stack trace
> output of stack_trace_save() is incomplete if the stack contains
> call_with_stack():
>
>  [0x7f00002c] dump_stack_task+0x2c/0x90 [hrtimer]
>  [0x7f0000a0] hrtimer_hander+0x10/0x18 [hrtimer]
>  [0x801a67f0] __hrtimer_run_queues+0x1b0/0x3b4
>  [0x801a7350] hrtimer_run_queues+0xc4/0xd8
>  [0x801a597c] update_process_times+0x3c/0x88
>  [0x801b5a98] tick_periodic+0x50/0xd8
>  [0x801b5bf4] tick_handle_periodic+0x24/0x84
>  [0x8010ffc4] twd_handler+0x38/0x48
>  [0x8017d220] handle_percpu_devid_irq+0xa8/0x244
>  [0x80176e9c] generic_handle_domain_irq+0x2c/0x3c
>  [0x8052e3a8] gic_handle_irq+0x7c/0x90
>  [0x808ab15c] generic_handle_arch_irq+0x60/0x80
>  [0x8051191c] call_with_stack+0x1c/0x20
>
> For the frame pointer unwinder, unwind_frame() checks stackframe::fp by
> stackframe::sp. Since call_with_stack() switches the SP from one stack
> to another, stackframe::fp and stackframe: :sp will point to different
> stacks, so we can no longer check stackframe::fp by stackframe::sp. Skip
> checking stackframe::fp at this point to avoid this problem.
>
> Signed-off-by: Li Huafei <lihuafei1@...wei.com>

Very nice catch! Took me some time to realize what was
going on here.

Reviewed-by: Linus Walleij <linus.walleij@...aro.org>

Nitpick below:

> +       /*
> +        * call_with_stack() is the only place we allow SP to jump from one
> +        * stack to another, with FP and SP pointing to different stacks,
> +        * skipping the FP boundary check at this point.
> +        */
> +       if (pc >= (unsigned long)&call_with_stack &&
> +                       pc < (unsigned long)&call_with_stack_end)
> +               return 0;

Can we create a local helper macro to do this, if it needs to happen
some other time?

#define ARM_PC_IN_FUNCTION(pc, func) (pc >=. ...)

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ