Support kernel tracing in drcachesim for system calls

[abhinav92003]

This issue is to track the design and implementation for the support to trace kernel instructions and data addresses for system calls in drcachesim.

The current plan is to use Intel-PT to collect system call instruction traces in the drcachesim tracer. We can start kernel tracing by using perf_events_open + ioctl in a pre-syscall event, and end it using ioctl in a post-syscall event.

We can then convert the PT trace to a drcachesim trace using libipt, and interleave it into the user-mode trace gathered by drcachesim, in raw2trace.

An approximation of the data addresses accessed by the kernel can be reconstructed using some heuristics and metadata collected by drcachesim (e.g. system call parameters). There are some interesting research articles that implement similar techniques: https://ieeexplore.ieee.org/document/9065578.

[prasun3]

Purely software based approach (like some prior academic work) not being considered?

https://sorav.compiler.ai/pubs/btkernel.pdf http://www.cs.toronto.edu/~peter/feiner_asplos_2012.pdf

[abhinav92003]

We do not want to assume the capability of modifying the kernel or loading a kernel module at runtime.

[algr]

It ought to be possible to do this on Arm as well using cs_etm events; the equivalent decoder library is https://github.com/Linaro/OpenCSD. Would it be possible for this to be done in a way where the main logic is cross-architecture, and only the bits that are specific to PT (resp ETM) are in the Intel (resp Arm) parts?

[abhinav92003]

Yes, we do plan to use the same hooks in the drmemtrace tracer and raw2trace that we use today for Intel-PT traces to also support ETM traces. We're blocked on getting access to required hardware with ETM capability though.