linux-kernel - Re: [PATCH RFC 0/2] Add basic tracing support for m68k

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: <CAP4=nvQe0KGxUAQSers9GbvZS0sVptbFzXufgGhuxAzVOyicHA@mail.gmail.com>
Date: Mon, 2 Dec 2024 15:45:21 +0100
From: Tomas Glozar <tglozar@...hat.com>
To: Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, linux-m68k@...ts.linux-m68k.org, 
	linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, 
	Geert Uytterhoeven <geert@...ux-m68k.org>, Greg Ungerer <gerg@...ux-m68k.org>
Subject: Re: [PATCH RFC 0/2] Add basic tracing support for m68k

Hi Jean-Michel,

po 2. 12. 2024 v 13:53 odesílatel Jean-Michel Hautbois
<jeanmichel.hautbois@...eli.org> napsal:
>
> Thanks, I will cook a patch !
>

Thanks!

> > As of the FOPTS changes: are those necessary for rtla to build, or
> > were you just using them for easier debugging? AFAIK rtla shouldn't
> > depend on unwind tables or stack protection for functionality.
>
> Well, my toolchain does not support it, so it fails at link time:
>    LINK    /home/yocto/Projects/wabtec/linux/tools/tracing/rtla/rtla
> /opt/m68k-buildroot-linux-uclibc_sdk-buildroot/bin/../lib/gcc/m68k-buildroot-linux-uclibc/13.3.0/../../../../m68k-buildroot-linux-uclibc/bin/ld:
> /tmp/ccih6k6Z.ltrans0.ltrans.o: in function `err_msg':
> /home/yocto/Projects/wabtec/linux/tools/tracing/rtla/src/utils.c:30:(.text+0x1a0):
> undefined reference to `__stack_chk_guard'
> /opt/m68k-buildroot-linux-uclibc_sdk-buildroot/bin/../lib/gcc/m68k-buildroot-linux-uclibc/13.3.0/../../../../m68k-buildroot-linux-uclibc/bin/ld:
> /home/yocto/Projects/wabtec/linux/tools/tracing/rtla/src/utils.c:39:(.text+0x1e0):
> undefined reference to `__stack_chk_guard'
>   <snip>
>
> That's why I removed this option.
>

Sorry, I misread the diff. I thought you were adding options, but you
are just removing  -fstack-protector-strong, right? I believe rtla
should check for the feature first before adding
-fstack-protector-strong, like perf does in
tools/perf/Makefile.config:

ifeq ($(feature-stackprotector-all), 1)
 CORE_CFLAGS += -fstack-protector-all
endif

The feature-stackprotector-all does a test build, if you have a
toolchain where building with -fstack-protector-all is broken for any
reason, it will return 0. You can try doing something similar for
rtla.

Tomas


> >>
> >> But it is not enough, as executing rtla fails with a segfault.
> >> I can dump a core, but I could not manage to build gdb for my board so I
> >> can't debug it (I don't know how to debug a coredump without gdb !).
> >>
> >> JM
> >>
> >
> > I have seen a similar libtraceevent-related rtla segfault recently on
> > ARM64, which was fixed by updating libtraceevent to a version that
> > includes the fix. Such issues are caused by the files for kernel
> > tracepoint tracefs having different contents on different
> > architectures, exposing bugs. I see Steven has already fixed one of
> > the issues on m68k [2].
>
> I will try to use the very last versions of both libtracefs and
> libtracevent and see if it is still happening !
>
> Thanks !
> JM
>