Open inconstante opened 3 years ago
By the way, if we implement such a verbosity knob, then we could even add debug messages to libpulp.so, and externally control whether they actually get printed or not.
We can also consider to totally refrain from emitting messages onto any file descriptor in the target process, and only emit to a local buffer that can be inspected by tools. That's more work of course because it needs to protect against buffer overflows (you don't want to fill the buffer with gigabytes of messages when noone uses the tool to receive and remove those messages). And it's more cumbersome to test as well, because you always need the tool to retrieve messages from the target. But that could be controlled as well with some flags.
But yeah, I agree that by default libpulp shouldn't print anything onto any file descriptor from the target. Well, at least eventually, for the final thing :-)
I may be mistaken, but I think the proper way to implement verbosity/quiet mode in libpulp is to set it to quiet by default, and then after all threads has been hijacked (i.e. in critical section), write an integer to libpulp memory area (there is write_byte
in ptrace.c) in the variable controlling the verbosity level. Maybe it is not even necessary for it to be in the critical section if the code accessing it is not running, which may be true since only libpulp may be accessing it.
I think it isn't too much trouble to add some sort of circular queue for storing a limited amount of messages (or how many messages can fit in N bytes) and then pooling the message buffer from another tool. If it always have N bytes, we could simply not worry about memory management and cleaning the queue. since all details about memory management goes away :). This approach could be a problem if we want to target embedded systems in the future, but that may be just me overthinking.
On Fri, 27 Aug 2021, Giuliano Belinassi wrote:
I may be mistaken, but I think the proper way to implement verbosity/quiet mode in libpulp is to set it to quiet by default, and then after all threads has been hijacked (i.e. in critical section), write an integer to libpulp memory area (there is
write_byte
in ptrace.c) in the variable controlling the verbosity level.
Something like that, yes.
Maybe it is not even necessary for it to be in the critical section if the code accessing it is not running, which may be true since only libpulp may be accessing it.
I think it isn't too much trouble to add some sort of circular queue for storing a limited amount of messages (or how many messages can fit in N bytes) and then pooling the message buffer from another tool. If it always have N bytes, we could simply not worry about memory management and cleaning the queue. since all details about memory management goes away :). This approach could be a problem if we want to target embedded systems in the future, but that may be just me overthinking.
I wouldn't worry about embedded systems here. But yeah, a circular fixed size buffer came also to my mind. So, if you want to work on that please do.
A message queue system has been added into libpulp.so, removing the need of writing into the target's process file descriptors. However, no verbosity control is implemented yet.
Since commit 8edcd2fd5890, the user can control the amount of information that Libpulp's tools print. For instance:
However, this only applies to the output of the tools themselves, not to the output of libpulp.so in the target process.
Currently, libpulp.so only writes to
stderr
and mostly on error conditions, but it does write a little. For instance, on process startup, it prints a hello message, such as:For the test suite, this output is harmless, however, on actual user applications, it could be undesirable. For instance, suppose we have an ssh service, which has its error output monitored by a tool like fail2ban. If fail2ban recognizes Libpulp's messages as harmful, it could affect the behavior of the service.
Our tools, such as
ulp_check
, should be able to control the verbosity of libpulp.so.