From: Florian Bezdeka <florian.bezdeka@siemens.com>
To: Jan Kiszka <jan.kiszka@siemens.com>, xenomai@lists.linux.dev
Cc: Clara Kowalsky <clara.kowalsky@siemens.com>
Subject: Re: RFC: Improve tooling support, move away from function wrapping
Date: Tue, 09 Apr 2024 14:50:22 +0200 [thread overview]
Message-ID: <6583550933fa564d2ba433387093f10f774af0ef.camel@siemens.com> (raw)
In-Reply-To: <5aa4e1d6-ac3d-43a2-ad51-4986cc224730@siemens.com>
On Mon, 2024-04-08 at 23:54 +0200, Jan Kiszka wrote:
> On 08.04.24 17:56, Florian Bezdeka wrote:
> > Hi all,
> >
> > as mentioned in one of the community talks I'm currently looking into
> > increasing the tooling support of Xenomai. We had that on our internal
> > wish list for some time now. It's time to look at that.
> >
> > The initial feature request was talking about valgrind support, so I
> > started with that but stopped further investigations because a lot of
> > code annotations were necessary. Main pain point was that all memory
> > writes done on the kernel side were not properly detected out of the
> > box and had to be annotated manually to avoid "invalid read" reports.
> >
> > In addition I did not like that we would have to build two versions of
> > each library. One with the annotations inside - useful for debugging -
> > and the prod version, without annotations because of possible side
> > effects or performance issues. (I did never actually measure it...)
> >
> > So I moved on and looked into using the gcc sanitizers.
> >
> > First major pain point: libasan (ther library behind the gcc address
> > sanitizer) intercepts posix services/functions. That does not work in
> > combination with the function wrapping done by libcobalt.
> >
> > To make that work we would have to walk away from function wrapping and
> > implement an interception mechanism that works similar to the libasan
> > implementation. That works - at least technically inside as small test
> > application.
> >
> > Function wrapping (in Xenomai) "defines" the following three
> > symbols/functions for each function that is wrapped. I'm using
> > pthread_create() as example here:
> >
> > __cobalt_pthread_create(): The RT/Xenomai implementation
> > __real_pthread_create(): The libc implementation
> > __wrap_pthread_create(): A weak alias to __cobalt_pthread_create()
> > Can be overwritten by the application.
> > Usage of __RT() and __STD() allows to call
> > the cobalt or libc implementation.
> >
> > For backward compatibility we must keep the interface, especially the
> > possibility to overwrite __wrap_*().
> >
> > The demo library/application (see attachment) shows that moving a way
> > from function wrapping allows to keep this "API" and allow usage of
> > libasan / address sanitizer. Some details:
> >
> > - We could move from function wrapping to our own "interception"
> > mechanism. Highly inspired by the libasan implementation.
> >
> > - We could change the COBALT_IMPL() macro to implement such an
> > mechanism.
> >
> > - Overwriting of __wrap_() still works
> >
> > - For each function we want to intercept we do the following:
> > (see library.c)
> >
> > - Declare (not define!) a weak symbol
> > - Introduce a trampoline function (__cobalt_t_*) that calls (jmp)
> > the __wrap_*(), which is itself a weak alias for the __cobalt_*()
> > implementation
> >
> > With that, most things work already. There is one missing piece: The
> > __STD() macro would no longer work, as there is no __real_*() symbol
> > anymore.
> >
> > To make that work, we have to search for the original symbol using
> > dlsym() in the library init phase, and remember the address of the
> > symbol / function.
> >
> > In case libasan is active, searching for the posix service (like
> > pthread_create) delivers the address of the interceptor. Nice.
> >
> >
> >
> > Before I start the real integration into Xenomai, what do you think?
> > Any feedback is highly appreciated.
> >
> >
> >
> > Topics I will have to look into:
> >
> > - Performance. I have some bad feelings regarding the trampoline
> > function. Maybe there is a better way in libasan already.
> >
> > - I'm looking for a way to get the init stuff (__cobalt_init() of
> > the attached demo) automated.
> >
> > - Architecture support. I don't like the ASM part of the current
> > demo. But I fear there is no other way. At least arm64 and arm
> > should not be a problem. Some bad feelings about i386...
> >
> > - Clarification needed: Is there really an application out there
> > that overwrote one of the services by implementing __wrap_*()?
> > Maybe we can remove that feature?
>
> I'm not aware of any, and I could imagine dropping this "feature" along
> such a change. We would get rid of the trampoline this way?
The trampoline would still be necessary, but we could simplify the
redirection mechanism a bit.
>
> >
> > - Other sanitizers: I only played around with -fsanitize=address
> > so far.
> >
> > Feedback / ideas highly appreciated.
> >
>
> Besides the interesting new feature to have asan support, avoiding all
> those --wrap options for linker and the *.wrappers would be a value as well.
>
> But there is one catch: The linker-based wrapping so far allows to
> assemble a binary where some objects use libcobalt and others remain
> unwrapped. To my understanding, libasan's interception always works for
> all parts of a binary, no fine-grained control possible per object as
> those boundaries are removed during linking. Correct?
Function wrapping is a linker feature, so the redirection happens when
linking the final library or executable. That's the reason why the
xeno-config tool forwards the necessary flags to "users".
I think the situation would regarding granularity would not change. I
will keep an eye on it while playing around with the idea.
>
> Jan
>
prev parent reply other threads:[~2024-04-09 12:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 15:56 RFC: Improve tooling support, move away from function wrapping Florian Bezdeka
2024-04-08 21:54 ` Jan Kiszka
2024-04-09 12:50 ` Florian Bezdeka [this message]
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=6583550933fa564d2ba433387093f10f774af0ef.camel@siemens.com \
--to=florian.bezdeka@siemens.com \
--cc=clara.kowalsky@siemens.com \
--cc=jan.kiszka@siemens.com \
--cc=xenomai@lists.linux.dev \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).