Should `dlopen` appear in points-to results for data pointers?

[adriaanjacobs]

Hi!

When running AndersenWaveDiff on something like nginx, calls to dlopen are frequently included in the points-to sets of dereferenced pointers. However, it seems to me like the return value of dlopen is solely meant as an opaque handle that is only to be passed to other libdl functions such as dlsym, and is never to be dereferenced directly.

In SVF's ExtApi.cpp, dlopen is handled as a EFT_NoStruct_Alloc function similar to other allocation functions. I've searched around in the commits but couldn't find the reason why this was treated as such. This leads me to wonder: how come dlopen is treated like any other allocation functions? And could we treat it differently?

Regards Adriaan

[yuleisui]

dlopen needs to point to an object representing the filehandle. The dereference of that object can happen inside a system call as you observed. If you like, you can also change its side-effect to 'EFT_NOOP' for your own purposes in ExtAPI.cpp.

[adriaanjacobs]

Thanks for the quick response.

Changing the effect worked for me, thanks. AFAIK, the loading of dynamic libraries at run-time through mechanisms like dlopen does not involve any special system calls besides file opening/reading/mmap/mprotect etc. (just ELF parsing and loading in userspace). Technically, I believe the return value doesn't even have to be a pointer, but may be any type representing a handle for the loaded ELF object.

This leads me to ask why SVF considers it an EFT_ALLOC function? For reference, dlclose is not considered an EFT_FREE, but simply EFT_NOOP, which is a bit asymmetrical. In my experiments, no issues arose from treating dlopen as EFT_NOOP.

Also, a similar argument can be made for file-handling functions such as fopen and fclose. These are treated as EFT_ALLOC and EFT_FREE respectively, but AFAIK they also represent objects that should never be dereferenced outside of libc. Is there an open-file tracking sanitizers that depends on this behaviour?

Thanks again for responding so quickly.

Regards Adriaan