Browse Prior Art Database

Method for disambiguating trace data in a namespace constrained environment

IP.com Disclosure Number: IPCOM000249170D
Publication Date: 2017-Feb-08
Document File: 2 page(s) / 33K

Publishing Venue

The IP.com Prior Art Database

Abstract

In namespace constrained environments, isolation rules and infrastructure mean that access to binaries and their debug data may be restricted. This leads to ambiguities and can result in incorrect or improper interpretation of the trace data. In order to make the trace data consumable, we need access to the relevant binary and its related debug data (symbol table, DWARF information, etc). We disclose here, a method to obtain this information without any security loopholes, wherein the profiler spawns a thread that temporarily joins the appropriate namespace of the target process and collects the necessary information before detaching itself from the target namespace. With this approach, profiling applications within a namespace constrained environment will just work, with minimal enhancements to the profiler.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

1

Method for disambiguating trace data in a namespace constrained environment

Disclosed here is a method to obtain access to binaries and associated debug data (symbol table, DWARF information, etc) of a target process to be profiled, when that target process is being run in a namespace constrained environment. This method works with minimal changes to the system profiler and ensures that the profiler obtains access to the correct binary and debug data, without introducing any security loopholes.

Linux* namespaces enable setting up of different containers on the same system, each with a different view of certain global system resources such as pid, uid, network interface, filesystem and so on. Due to the way they work, namespaces introduce new challenges to many system utilities, including profilers. System profilers depend on the ability to access the target application binary and its related debug data for providing meaningful insights. As an example, in the case of profiling an application, the profiler usually samples the instruction pointer at a certain frequency and provides a summary at the end, indicating the function where the application spent the most time. To do this, the profiler looks at the application binary and debug data, to map a sampled address to a meaningful function name that the user can recognize. In namespace constrained environments (specifically, different mount namespaces which provide different filesystem views), profilers may not have access to the binary and its debug data to generate the address<->symbol mapping. This prevents the profiler from being able to provide meaningful insights into the running of the applications.

Method: While profiling applications, the system profiler first notices if the application being profiled has a mount namespace separate from that of the system. This can be achieved in various ways, including looking at the /proc filesystem. During profiling, the system profiler captures such...