Future directions for the dynamic linker auditing (LD_AUDIT) interface

[Jonathon Anderson]

> > Even the lack of self-monitoring callbacks mentioned in BZ#31992 could
> > pose a challenge.
> 
> Sorry, which aspect of the bug are you referring to?

>From the first comment on the bug (https://sourceware.org/bugzilla/show_bug.cgi?id=31992#c1):

> Auditors are not themselves subject to auditing within their own namespaces. For the case of a single auditor, that prevents itself from observing its own activity binding activity, for example.

Regarding the "challenge," for example PC sampling requires an up-to-date representation of the address space which includes the auditor. If auditors cannot "see" libraries they dlopen() then the address space will slip out-of-date while code (constructors) is running from the newly loaded library. If an asynchronous sample is taken during that delicate time a stack unwind will ultimately fail.

I believe this issue is something the shim can work around (e.g. with an extra dlmopen() namespace), so I'm not too concerned yet, but it's something to be aware of.

-Jonathon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20241127/635ab4ea/attachment-0001.htm>
-------------- next part --------------
An embedded message was scrubbed...
From: Florian Weimer <fweimer@redhat.com>
Subject: Re: Future directions for the dynamic linker auditing (LD_AUDIT) interface
Date: Tue, 26 Nov 2024 11:03:59 +0100
Size: 9687
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20241127/635ab4ea/attachment-0001.eml>