(dbx) check -access
Turns on access checking an instruments at load time all shared libraries that the application uses.
Is there a way to selectively indicate which libraries should/not be instrumented?
I have a large application which uses a lot of shared libraries that take forever to instrument. Most of those shared libraries I'm not concerned about.
It is possible with rtc skippatch:
rtc skippatch lib1 lib2 lib3 lib4...
Related
On Windows, we can register a callback function through LdrDllNotification, so that when any DLL is about to be unloaded, we can get a chance to collect some useful information about that DLL, including its address, size, etc.
I don’t know enough about UNIX-like platforms (including Linux, macOS, iOS, Android, etc.). How can I do the same on these platforms?
On Linux, libraries are loaded and unloaded by the dynamic loader. The loading is usually done automatically when needed by the loader itself, but can also be done manually using the library function dlopen(). The unloading is done manually through dlclose() or automatically at program exit. This is not universally applicable to every Unix system, but only to POSIX compliant ones.
Unfortunately, since (unlike in Windows) the job of loading and unloading libraries is carried out by the dynamic loader (which is just an userspace library), the kernel does not know what is going on and does not provide any mechanism of detecting loading or unloading of dynamic libraries. Even more unfortunately, the loader itself does not provide any such mechanism either. Indeed, there would probably be little-to-no-use for such functionality, apart from usage metrics or similar stuff.
You normally don't even unload libraries at runtime in Linux, unless we are talking about a very complex piece of software that needs to limit its memory footprint when running. The loader loads the libraries when needed at startup (or when the first needed library function is called) and then they are left like any other piece of memory for the kernel to clean up when the program dies.
To my knowlegte, the "best" you could do on Linux to detect unloading of dynamic libraries is:
Create your own shared library implementing dlclose() and preload it when running executables. This is explained here and here.
Continuously watch /proc/self/maps parsing the list of loaded libraries.
Run the program under a debugger like gdb, which can be scripted/automated using Python.
As per other OSes... Android is Linux based, though it has additional security features and apps are sandboxed, unless you root the device or you use a debug shell you can't just "run" other apps hooking them with a custom dlclose() or even a debugger. I can't say much about iOS, but I suspect that implementing such a functionality is not even remotely an option given the very limited abilities of apps (that are also sandboxed). AFAIK macOS also supports dlopen()/dlclose() for manually loading/unloading libraries, however the linker is not the same as the one commonly used on Linux (linked above) so I can't say much about the automatic loading/unloading behavior.
Is it possible to have a completely statically linked GUI app on Linux? I'm aware that some libraries (e.g. Qt5) have the option to be statically compiled and linked into the executable, but even then the resulting executable is dynamically linked to other libraries.
If it is possible, is there a reference project which demonstrates how it's done? If it's not, why is this so?
Note: I'm deliberately leaving out the question of programming languages, gui libraries/frameworks, or GUI architectures (webview/native desktop) to broaden the scope for answers.
Yes it is possible. For wayland and X at least, client and server communicate over unix socket. There usually exists a client-side library (usually dynamically linked), which abstracts this low-level communication. And it can be statically linked.
But clients do not need to be linked with server library. Still you have to run display server (or compositor in wayland terms).
Technically, you don't even need any client-side libraries and could implement low-level communication scheme yourself (similarly, you don't need a browser to use HTTP protocol, but can write it manually).
There is a wayland client library written in pure Go. Go uses dynamic linking only when including C libraries, which this library does not do. You can install the example programs and verify they are statically linked.
I also managed to statically build a simple application, also for wayland.
CONFIG_GCC_PLUGIN_RANDSTRUCT enables a security feature which randomizes data structure layout to raise the attack bar. This feature is implemented as a GCC plugin and the randomization seed file is exposed to users who need to build third-party or out-of-tree kernel modules. Since common users can build kernel modules, an attacker as a common user can read the seed file and thus defeat this randomization.
Why don't we restrict the read access to the seed file to privileged users? Of course, this means we need to compile kernel modules using sudo/root access. But I don't see any reasons to reject it after all installing a kernel module requires sudo/root access.
I build the kernel myself because I fail to find a distros that enables this feature.
If you built the kernel yourself, then you are responsible for the files. Simply restrict the access to the seed file as necessary. If you don't do this, everyone who can read (copy) the file can also build kernel modules on his own computer. It wouldn't make sense to enable this feature in a pre-built kernel because all users would share the same publicly known seed.
I'm working on a very low resources embedded system using linux kernel as OS. There are any distro or POSIX/GNU toolchain, only a kernel loaded on memory and a custom init process.
So far I've been using statically linked binaries, but now I need shared objects too. In order to keep simplicity and save resources I need ld.so functionality statically linked inside every binary.
There exist any portable solution that allow me to statically link a shared object loader inside my application?
You probably need a statically linked libdl.so, i.e. some (hypothetical) libdl.a (which probably would require a shared library loaded ld.so)
But I think that you should consider some other way, e.g. using a small musl-libc which provides its own libdl etc... You probably could customize it (so having a musl libc.so tailored to your needs) to contain only the object files and API that are needed to you.
The code is written in c/c++，may depend some libs in the compiling host;
and it should run in another host without libs depending problems. Both hosts are linux, may have different versions.
Do you have a good strategy?
Pure static linking on Linux is discouraged, it's only really possible if you use an alternative libc (such as dietlibc) which isn't an option with C++, my favoured approach is to build the application on the oldest version of Linux you have to support as the newer libc builds will have backwards compatibility.
This will only cover libc, other requirements, such as gtk, pangom, etc will have to be compiled directly into your binary.
Link the application statically, so that it depends on as few dynamically loaded libraries as possible. This is the general solution to this problem.
Other solutions include:
Ship the required libraries with the application, and override the system's LD_LIBRARY_PATH variable to make the included versions the preferred ones.
Write code to dynamically load the libraries using dlopen() and friends, and handle differences in library versions manually.
Most platforms have a well-defined ABI that covers C code, but ABIs that cover C++ functionality are not yet common.
A program written in c++ using just libc may not run on another platform.
if binary compatibility is an important issue consider using c.
Take all answers for this question into account (static linking, compiling on the oldest Linux, etc.) and then check your final binary by the Linux App Checker to show compatibility issues with other Linux distributions.