core/logging: don't log plain pointer value from nm_log_ptr()

Logging pointer values might reveal information that can be used to defeat
ASLR. We should avoid that.

On the other hand, it's useful to tag a logging message with the pointer
value of the "source" of the message. It helps to correlate messages and
search for relevant messages in the log.

As a compromise, use NM_HASH_OBFUSCATE_PTR(), like we do at several places
already. For example, we also log

  <debug> [1566550899.7901] setup NMPlatform singleton (29a6af9867f2e5d0)

This obfuscated value is a 64 bit unsigned integer with the siphash24
hash of the raw value with a randomized seed. Of course, contrary to the
pointer value, there is a tiny chance that two different pointers hash
to the same identifier. However, that seems unlikely enough to be of no
concern. Note that this pointer value is only logged to aid debugging.
It is sufficiently unlikely that this causes confusion.

One other downside of printed the obfuscated value, is that you can no
longer read the pointer from the log and use it in gdb directly. That
might be sometimes convenient, but making this impossible is kinda the
purpose of this change.

As such, nm_log_ptr() becomes a bit of a misnomer. But not too bad, it
still is a good name. For example, if we wanted we could redefine the
NM_HASH_OBFUSCATE_PTR* macros when building "--with-more-asserts".
This commit is contained in:
Thomas Haller 2019-08-23 11:13:33 +02:00
parent 505208a448
commit aa100d89a4

View file

@ -84,9 +84,10 @@ LOGD_IP_from_af (int addr_family)
(domain), \
(ifname), \
(con_uuid), \
"%s[%p] " _NM_UTILS_MACRO_FIRST(__VA_ARGS__), \
"%s["NM_HASH_OBFUSCATE_PTR_FMT"] " _NM_UTILS_MACRO_FIRST(__VA_ARGS__), \
(prefix) ?: "", \
self _NM_UTILS_MACRO_REST(__VA_ARGS__))
NM_HASH_OBFUSCATE_PTR (self) \
_NM_UTILS_MACRO_REST(__VA_ARGS__))
static inline gboolean
_nm_log_ptr_is_debug (NMLogLevel level)