Homepage abstracts

[miloc23]

I think we should have a list of our current projects along with an abstract of what the project is about right on the homepage. We could discuss if we want this somewhere else, but I think right now we have a ton of really cool projects which should serve as an introduction to what the group's research focus is.

[miloc23]

Egor's Abstract: BPF is a crucial tool for tracing on production servers. However, without intimate knowledge of the application and its potential tracepoints on critical paths, gauging the performance repercussions of BPF programs remains challenging. Even more so when multiple bpf programs are being run in conjunction with multiple processes, resulting in a myriad of tracepoints that have unknown impact on each other and the system. This study offers a methodology to assess these effects and underline the importance of careful tracepoint selection in minimizing operational disruptions. Using the ftrace framework, we cataloged frequently accessed kernel functions. By linking a BPF function to each of these tracepoints and subsequently running the redis-benchmark, we quantified their performance impacts. For example, the results indicated a 16% performance decrease when we attached a hello_world BPF program to the most frequented tracepoint in redis-benchmark. Given the known inefficiency of the printk function within BPF, its broader implications on the kernel—especially for extensive applications like network logging—merit further exploration. We believe this motivates the implementation of a throttling mechanism or program policy that helps limit unintentional slowdown in a live server.

[rjsu26]

Raj's Abstract :

Due to increasing use-case, complexity and interference between BPF programs in production systems, we found an emerging need for safely cancelling BPF programs in case of unexpectedly long runtime. In this work, we are exploring the design space to instrument a runtime mechanism using which any BPF program can be terminated without losing any of the safety properties provided by the BPF infrastructure. Some aspects of the design like code complexity, runtime overhead for no-termination case, correctness, etc are crucial when choosing one mechanism over the other. We are working on a solution that can leverage properties which are unique to the BPF world using which we can avoid the complexity of industry standard approaches to deal with task cancellation in JVM, Rust or other modern programming languages.

[sidchintamaneni]

Stackoverflow Project:

Verifier implicitly makes assumptions about the runtime execution environment, which must hold for safety to be upheld. One such component of the execution environment is the availability of stack space for use by the BPF program. we showed two fundamental problems in the setup of the BPF runtime environment that allowed us to overflow the kernel stack. First, the BPF program, when attached to the kernel, often inherits or reuses the kernel stack, which is limited in size. Depending on the attachment point, the kernel stack may already be approaching the limit, and a BPF program can overflow the stack, despite being verified to use less than 8KB of stack space. The verifier makes an incorrect assumption about the runtime execution environment: that the kernel stack will always have 8KB stack space available. Second, while in most cases the BPF execution environment restricts nesting of BPF programs to limit the resultant stack depth, it is incomplete. We find that, by hooking BPF programs on helper functions, we can nest multiple BPF programs in the kernel in a way that inherits the same stack state, ultimately exhausting the stack. The verifier once again makes an incorrect assumption about the runtime execution environment: that BPF program nesting is disallowed or carefully controlled in all cases. Now we are working on a solution to prevent stackoverflow issues from happening.