Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No verbosity control in libpulp.so #29

Open
inconstante opened this issue Aug 13, 2021 · 5 comments
Open

No verbosity control in libpulp.so #29

inconstante opened this issue Aug 13, 2021 · 5 comments

Comments

@inconstante
Copy link
Contributor

Since commit 8edcd2f, the user can control the amount of information that Libpulp's tools print. For instance:

$ tools/ulp_trigger --help
<snip>
  -q, --quiet                Don't produce any output
  -v, --verbose              Produce verbose output

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:

$ LD_PRELOAD=/libpulp.so.0 application 
libpulp loaded...

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.

@inconstante
Copy link
Contributor Author

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.

@susematz
Copy link
Collaborator

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 :-)

@giulianobelinassi
Copy link
Collaborator

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.

@susematz
Copy link
Collaborator

susematz commented Aug 30, 2021 via email

@giulianobelinassi
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants