Netronome's half-day tutorial on host data plane acceleration at ACM SIGCOMM 2018 introduced attendees to models for host data plane acceleration and provided an in-depth understanding of SmartNIC deployment models at hyperscale cloud vendors and telecom service providers.
Presenter Bios
Jakub Kicinski is a long term Linux kernel contributor, who has been leading the kernel team at Netronome for the last two years. Jakub’s major contributions include the creation of BPF hardware offload mechanisms in the kernel and bpftool user space utility, as well as work on the Linux kernel side of OVS offload.
David Beckett is a Software Engineer at Netronome with a strong technical background of computer networks including academic research with DDoS. David has expertise in the areas of Linux architecture and computer programming. David has a Masters Degree in Electrical, Electronic Engineering at Queen’s University Belfast and continues as a PhD student studying Emerging Application Layer DDoS threats.
Linux 4.x Tracing: Performance Analysis with bcc/BPFBrendan Gregg
Talk about bcc/eBPF for SCALE15x (2017) by Brendan Gregg. "BPF (Berkeley Packet Filter) has been enhanced in the Linux 4.x series and now powers a large collection of performance analysis and observability tools ready for you to use, included in the bcc (BPF Complier Collection) open source project. BPF nowadays can do system tracing, software defined networks, and kernel fast path: much more than just filtering packets! This talk will focus on the bcc/BPF tools for performance analysis, which make use of other built in Linux capabilities: dynamic tracing (kprobes and uprobes) and static tracing (tracepoints and USDT). There are now bcc tools for measuring latency distributions for file system I/O and run queue latency, printing details of storage device I/O and TCP retransmits, investigating blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. Tracing superpowers have finally arrived, built in to Linux."
The Linux Block Layer - Built for Fast StorageKernel TLV
The arrival of flash storage introduced a radical change in performance profiles of direct attached devices. At the time, it was obvious that Linux I/O stack needed to be redesigned in order to support devices capable of millions of IOPs, and with extremely low latency.
In this talk we revisit the changes the Linux block layer in the
last decade or so, that made it what it is today - a performant, scalable, robust and NUMA-aware subsystem. In addition, we cover the new NVMe over Fabrics support in Linux.
Sagi Grimberg
Sagi is Principal Architect and co-founder at LightBits Labs.
USENIX LISA2021 talk by Brendan Gregg (https://www.youtube.com/watch?v=_5Z2AU7QTH4). This talk is a deep dive that describes how BPF (eBPF) works internally on Linux, and dissects some modern performance observability tools. Details covered include the kernel BPF implementation: the verifier, JIT compilation, and the BPF execution environment; the BPF instruction set; different event sources; and how BPF is used by user space, using bpftrace programs as an example. This includes showing how bpftrace is compiled to LLVM IR and then BPF bytecode, and how per-event data and aggregated map data are fetched from the kernel.
DockerCon 2017 - Cilium - Network and Application Security with BPF and XDPThomas Graf
This talk will start with a deep dive and hands on examples of BPF, possibly the most promising low level technology to address challenges in application and network security, tracing, and visibility. We will discuss how BPF evolved from a simple bytecode language to filter raw sockets for tcpdump to the a JITable virtual machine capable of universally extending and instrumenting both the Linux kernel and user space applications. The introduction is followed by a concrete example of how the Cilium open source project applies BPF to solve networking, security, and load balancing for highly distributed applications. We will discuss and demonstrate how Cilium with the help of BPF can be combined with distributed system orchestration such as Docker to simplify security, operations, and troubleshooting of distributed applications.
Netronome's half-day tutorial on host data plane acceleration at ACM SIGCOMM 2018 introduced attendees to models for host data plane acceleration and provided an in-depth understanding of SmartNIC deployment models at hyperscale cloud vendors and telecom service providers.
Presenter Bios
Jakub Kicinski is a long term Linux kernel contributor, who has been leading the kernel team at Netronome for the last two years. Jakub’s major contributions include the creation of BPF hardware offload mechanisms in the kernel and bpftool user space utility, as well as work on the Linux kernel side of OVS offload.
David Beckett is a Software Engineer at Netronome with a strong technical background of computer networks including academic research with DDoS. David has expertise in the areas of Linux architecture and computer programming. David has a Masters Degree in Electrical, Electronic Engineering at Queen’s University Belfast and continues as a PhD student studying Emerging Application Layer DDoS threats.
Linux 4.x Tracing: Performance Analysis with bcc/BPFBrendan Gregg
Talk about bcc/eBPF for SCALE15x (2017) by Brendan Gregg. "BPF (Berkeley Packet Filter) has been enhanced in the Linux 4.x series and now powers a large collection of performance analysis and observability tools ready for you to use, included in the bcc (BPF Complier Collection) open source project. BPF nowadays can do system tracing, software defined networks, and kernel fast path: much more than just filtering packets! This talk will focus on the bcc/BPF tools for performance analysis, which make use of other built in Linux capabilities: dynamic tracing (kprobes and uprobes) and static tracing (tracepoints and USDT). There are now bcc tools for measuring latency distributions for file system I/O and run queue latency, printing details of storage device I/O and TCP retransmits, investigating blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. Tracing superpowers have finally arrived, built in to Linux."
The Linux Block Layer - Built for Fast StorageKernel TLV
The arrival of flash storage introduced a radical change in performance profiles of direct attached devices. At the time, it was obvious that Linux I/O stack needed to be redesigned in order to support devices capable of millions of IOPs, and with extremely low latency.
In this talk we revisit the changes the Linux block layer in the
last decade or so, that made it what it is today - a performant, scalable, robust and NUMA-aware subsystem. In addition, we cover the new NVMe over Fabrics support in Linux.
Sagi Grimberg
Sagi is Principal Architect and co-founder at LightBits Labs.
USENIX LISA2021 talk by Brendan Gregg (https://www.youtube.com/watch?v=_5Z2AU7QTH4). This talk is a deep dive that describes how BPF (eBPF) works internally on Linux, and dissects some modern performance observability tools. Details covered include the kernel BPF implementation: the verifier, JIT compilation, and the BPF execution environment; the BPF instruction set; different event sources; and how BPF is used by user space, using bpftrace programs as an example. This includes showing how bpftrace is compiled to LLVM IR and then BPF bytecode, and how per-event data and aggregated map data are fetched from the kernel.
DockerCon 2017 - Cilium - Network and Application Security with BPF and XDPThomas Graf
This talk will start with a deep dive and hands on examples of BPF, possibly the most promising low level technology to address challenges in application and network security, tracing, and visibility. We will discuss how BPF evolved from a simple bytecode language to filter raw sockets for tcpdump to the a JITable virtual machine capable of universally extending and instrumenting both the Linux kernel and user space applications. The introduction is followed by a concrete example of how the Cilium open source project applies BPF to solve networking, security, and load balancing for highly distributed applications. We will discuss and demonstrate how Cilium with the help of BPF can be combined with distributed system orchestration such as Docker to simplify security, operations, and troubleshooting of distributed applications.
UM2019 Extended BPF: A New Type of SoftwareBrendan Gregg
Keynote for Ubuntu Masters 2019 by Brendan Gregg, Netflix. Video https://www.youtube.com/watch?v=7pmXdG8-7WU&feature=youtu.be . "Extended BPF is a new type of software, and the first fundamental change to how kernels are used in 50 years. This new type of software is already in use by major companies: Netflix has 14 BPF programs running by default on all of its cloud servers, which run Ubuntu Linux. Facebook has 40 BPF programs running by default. Extended BPF is composed of an in-kernel runtime for executing a virtual BPF instruction set through a safety verifier and with JIT compilation. So far it has been used for software defined networking, performance tools, security policies, and device drivers, with more uses planned and more we have yet to think of. It is changing how we use and think about systems. This talk explores the past, present, and future of BPF, with BPF performance tools as a use case."
BPF of Berkeley Packet Filter mechanism was first introduced in linux in 1997 in version 2.1.75. It has seen a number of extensions of the years. Recently in versions 3.15 - 3.19 it received a major overhaul which drastically expanded it's applicability. This talk will cover how the instruction set looks today and why. It's architecture, capabilities, interface, just-in-time compilers. We will also talk about how it's being used in different areas of the kernel like tracing and networking and future plans.
The Linux kernel is undergoing the most fundamental architecture evolution in history and is becoming a microkernel. Why is the Linux kernel evolving into a microkernel? The potentially biggest fundamental change ever happening to the Linux kernel. This talk covers how companies like Facebook and Google use BPF to patch 0-day exploits, how BPF will change the way features are added to the kernel forever, and how BPF is introducing a new type of application deployment method for the Linux kernel.
An Introduction to eBPF (and cBPF). Topics covered include history, implementation, program types & maps. Also gives a brief introduction to XDP and DPDK
eBPF is an exciting new technology that is poised to transform Linux performance engineering. eBPF enables users to dynamically and programatically trace any kernel or user space code path, safely and efficiently. However, understanding eBPF is not so simple. The goal of this talk is to give audiences a fundamental understanding of eBPF, how it interconnects existing Linux tracing technologies, and provides a powerful aplatform to solve any Linux performance problem.
Memory Mapping Implementation (mmap) in Linux KernelAdrian Huang
Note: When you view the the slide deck via web browser, the screenshots may be blurred. You can download and view them offline (Screenshots are clear).
SOSCON 2019.10.17
What are the methods for packet processing on Linux? And how fast are each packet processing methods? In this presentation, we will learn how to handle packets on Linux (User space, socket filter, netfilter, tc), and compare performance with analysis of where each packet processing is done in the network stack (hook point). Also, we will discuss packet processing using XDP, an in-kernel fast-path recently added to the Linux kernel. eXpress Data Path (XDP) is a high-performance programmable network data-path within the Linux kernel. The XDP is located at the lowest level of access through SW in the network stack, the point at which driver receives the packet. By using the eBPF infrastructure at this hook point, the network stack can be expanded without modifying the kernel.
Daniel T. Lee (Hoyeon Lee)
@danieltimlee
Daniel T. Lee currently works as Software Engineer at Kosslab and contributing to Linux kernel BPF project. He has interest in cloud, Linux networking, and tracing technologies, and likes to analyze the kernel's internal using BPF technology.
BPF & Cilium - Turning Linux into a Microservices-aware Operating SystemThomas Graf
Container runtimes cause Linux to return to its original purpose: to serve applications interacting directly with the kernel. At the same time, the Linux kernel is traditionally difficult to change and its development process is full of myths. A new efficient in-kernel programming language called eBPF is changing this and allows everyone to extend existing kernel components or glue them together in new forms without requiring to change the kernel itself.
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all startedAnne Nicolas
Ftrace’s most powerful feature is the function tracer (and function graph tracer which is built from it). But to have this enabled on production systems, it had to have its overhead be negligible when disabled. As the function tracer uses gcc’s profiling mechanism, which adds a call to “mcount” (or more recently fentry, don’t worry if you don’t know what this is, it will all be explained) at the start of almost all functions, it had to do something about the overhead that causes. The solution was to turn those calls into “nops” (an instruction that the CPU simply ignores). But this was no easy feat. It took a lot to come up with a solution (and also turning a few network cards into bricks). This talk will explain the history of how ftrace came about implementing the function tracer, and brought with it the possibility of static branches and soon static calls!
Steven Rostedt
Delivered as plenary at USENIX LISA 2013. video here: https://www.youtube.com/watch?v=nZfNehCzGdw and https://www.usenix.org/conference/lisa13/technical-sessions/plenary/gregg . "How did we ever analyze performance before Flame Graphs?" This new visualization invented by Brendan can help you quickly understand application and kernel performance, especially CPU usage, where stacks (call graphs) can be sampled and then visualized as an interactive flame graph. Flame Graphs are now used for a growing variety of targets: for applications and kernels on Linux, SmartOS, Mac OS X, and Windows; for languages including C, C++, node.js, ruby, and Lua; and in WebKit Web Inspector. This talk will explain them and provide use cases and new visualizations for other event types, including I/O, memory usage, and latency.
Virtual File System in Linux Kernel
Note: When you view the the slide deck via web browser, the screenshots may be blurred. You can download and view them offline (Screenshots are clear).
eBPF (extended Berkeley Packet Filters) is a modern kernel technology that can be used to introduce dynamic tracing into a system that wasn't prepared or instrumented in any way. The tracing programs run in the kernel, are guaranteed to never crash or hang your system, and can probe every module and function -- from the kernel to user-space frameworks such as Node and Ruby.
In this workshop, you will experiment with Linux dynamic tracing first-hand. First, you will explore BCC, the BPF Compiler Collection, which is a set of tools and libraries for dynamic tracing. Many of your tracing needs will be answered by BCC, and you will experiment with memory leak analysis, generic function tracing, kernel tracepoints, static tracepoints in user-space programs, and the "baked" tools for file I/O, network, and CPU analysis. You'll be able to choose between working on a set of hands-on labs prepared by the instructors, or trying the tools out on your own test system.
Next, you will hack on some of the bleeding edge tools in the BCC toolkit, and build a couple of simple tools of your own. You'll be able to pick from a curated list of GitHub issues for the BCC project, a set of hands-on labs with known "school solutions", and an open-ended list of problems that need tools for effective analysis. At the end of this workshop, you will be equipped with a toolbox for diagnosing issues in the field, as well as a framework for building your own tools when the generic ones do not suffice.
It's been three years since Netflix's Brendan Gregg described the Berkeley Packet Filter as "Superpowers for Linux". Since then there has been an explosion of capabilities and tools based on eBPF, so you've probably heard the term, but do you know what it is and how to use it? In this demo-rich talk we'll explore some of the powerful things we can do with this technology, especially in the context of containers.
This talk is all about the Berkeley Packet Filters (BPF) and their uses in Linux.
Agenda:
* What is a BPF and why do we need it?
* Writing custom BPFs
* Notes on BPF implementation in the kernel
* Usage examples: SOCKET_FILTER & seccomp
Speaker:
Kfir Gollan, senior embedded software developer, Linux kernel hacker and software team leader.
UM2019 Extended BPF: A New Type of SoftwareBrendan Gregg
Keynote for Ubuntu Masters 2019 by Brendan Gregg, Netflix. Video https://www.youtube.com/watch?v=7pmXdG8-7WU&feature=youtu.be . "Extended BPF is a new type of software, and the first fundamental change to how kernels are used in 50 years. This new type of software is already in use by major companies: Netflix has 14 BPF programs running by default on all of its cloud servers, which run Ubuntu Linux. Facebook has 40 BPF programs running by default. Extended BPF is composed of an in-kernel runtime for executing a virtual BPF instruction set through a safety verifier and with JIT compilation. So far it has been used for software defined networking, performance tools, security policies, and device drivers, with more uses planned and more we have yet to think of. It is changing how we use and think about systems. This talk explores the past, present, and future of BPF, with BPF performance tools as a use case."
BPF of Berkeley Packet Filter mechanism was first introduced in linux in 1997 in version 2.1.75. It has seen a number of extensions of the years. Recently in versions 3.15 - 3.19 it received a major overhaul which drastically expanded it's applicability. This talk will cover how the instruction set looks today and why. It's architecture, capabilities, interface, just-in-time compilers. We will also talk about how it's being used in different areas of the kernel like tracing and networking and future plans.
The Linux kernel is undergoing the most fundamental architecture evolution in history and is becoming a microkernel. Why is the Linux kernel evolving into a microkernel? The potentially biggest fundamental change ever happening to the Linux kernel. This talk covers how companies like Facebook and Google use BPF to patch 0-day exploits, how BPF will change the way features are added to the kernel forever, and how BPF is introducing a new type of application deployment method for the Linux kernel.
An Introduction to eBPF (and cBPF). Topics covered include history, implementation, program types & maps. Also gives a brief introduction to XDP and DPDK
eBPF is an exciting new technology that is poised to transform Linux performance engineering. eBPF enables users to dynamically and programatically trace any kernel or user space code path, safely and efficiently. However, understanding eBPF is not so simple. The goal of this talk is to give audiences a fundamental understanding of eBPF, how it interconnects existing Linux tracing technologies, and provides a powerful aplatform to solve any Linux performance problem.
Memory Mapping Implementation (mmap) in Linux KernelAdrian Huang
Note: When you view the the slide deck via web browser, the screenshots may be blurred. You can download and view them offline (Screenshots are clear).
SOSCON 2019.10.17
What are the methods for packet processing on Linux? And how fast are each packet processing methods? In this presentation, we will learn how to handle packets on Linux (User space, socket filter, netfilter, tc), and compare performance with analysis of where each packet processing is done in the network stack (hook point). Also, we will discuss packet processing using XDP, an in-kernel fast-path recently added to the Linux kernel. eXpress Data Path (XDP) is a high-performance programmable network data-path within the Linux kernel. The XDP is located at the lowest level of access through SW in the network stack, the point at which driver receives the packet. By using the eBPF infrastructure at this hook point, the network stack can be expanded without modifying the kernel.
Daniel T. Lee (Hoyeon Lee)
@danieltimlee
Daniel T. Lee currently works as Software Engineer at Kosslab and contributing to Linux kernel BPF project. He has interest in cloud, Linux networking, and tracing technologies, and likes to analyze the kernel's internal using BPF technology.
BPF & Cilium - Turning Linux into a Microservices-aware Operating SystemThomas Graf
Container runtimes cause Linux to return to its original purpose: to serve applications interacting directly with the kernel. At the same time, the Linux kernel is traditionally difficult to change and its development process is full of myths. A new efficient in-kernel programming language called eBPF is changing this and allows everyone to extend existing kernel components or glue them together in new forms without requiring to change the kernel itself.
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all startedAnne Nicolas
Ftrace’s most powerful feature is the function tracer (and function graph tracer which is built from it). But to have this enabled on production systems, it had to have its overhead be negligible when disabled. As the function tracer uses gcc’s profiling mechanism, which adds a call to “mcount” (or more recently fentry, don’t worry if you don’t know what this is, it will all be explained) at the start of almost all functions, it had to do something about the overhead that causes. The solution was to turn those calls into “nops” (an instruction that the CPU simply ignores). But this was no easy feat. It took a lot to come up with a solution (and also turning a few network cards into bricks). This talk will explain the history of how ftrace came about implementing the function tracer, and brought with it the possibility of static branches and soon static calls!
Steven Rostedt
Delivered as plenary at USENIX LISA 2013. video here: https://www.youtube.com/watch?v=nZfNehCzGdw and https://www.usenix.org/conference/lisa13/technical-sessions/plenary/gregg . "How did we ever analyze performance before Flame Graphs?" This new visualization invented by Brendan can help you quickly understand application and kernel performance, especially CPU usage, where stacks (call graphs) can be sampled and then visualized as an interactive flame graph. Flame Graphs are now used for a growing variety of targets: for applications and kernels on Linux, SmartOS, Mac OS X, and Windows; for languages including C, C++, node.js, ruby, and Lua; and in WebKit Web Inspector. This talk will explain them and provide use cases and new visualizations for other event types, including I/O, memory usage, and latency.
Virtual File System in Linux Kernel
Note: When you view the the slide deck via web browser, the screenshots may be blurred. You can download and view them offline (Screenshots are clear).
eBPF (extended Berkeley Packet Filters) is a modern kernel technology that can be used to introduce dynamic tracing into a system that wasn't prepared or instrumented in any way. The tracing programs run in the kernel, are guaranteed to never crash or hang your system, and can probe every module and function -- from the kernel to user-space frameworks such as Node and Ruby.
In this workshop, you will experiment with Linux dynamic tracing first-hand. First, you will explore BCC, the BPF Compiler Collection, which is a set of tools and libraries for dynamic tracing. Many of your tracing needs will be answered by BCC, and you will experiment with memory leak analysis, generic function tracing, kernel tracepoints, static tracepoints in user-space programs, and the "baked" tools for file I/O, network, and CPU analysis. You'll be able to choose between working on a set of hands-on labs prepared by the instructors, or trying the tools out on your own test system.
Next, you will hack on some of the bleeding edge tools in the BCC toolkit, and build a couple of simple tools of your own. You'll be able to pick from a curated list of GitHub issues for the BCC project, a set of hands-on labs with known "school solutions", and an open-ended list of problems that need tools for effective analysis. At the end of this workshop, you will be equipped with a toolbox for diagnosing issues in the field, as well as a framework for building your own tools when the generic ones do not suffice.
It's been three years since Netflix's Brendan Gregg described the Berkeley Packet Filter as "Superpowers for Linux". Since then there has been an explosion of capabilities and tools based on eBPF, so you've probably heard the term, but do you know what it is and how to use it? In this demo-rich talk we'll explore some of the powerful things we can do with this technology, especially in the context of containers.
This talk is all about the Berkeley Packet Filters (BPF) and their uses in Linux.
Agenda:
* What is a BPF and why do we need it?
* Writing custom BPFs
* Notes on BPF implementation in the kernel
* Usage examples: SOCKET_FILTER & seccomp
Speaker:
Kfir Gollan, senior embedded software developer, Linux kernel hacker and software team leader.
eBPF Tooling and Debugging InfrastructureNetronome
eBPF, in particular with its driver-level hook XDP, has increased in importance over the past few years. As a result, the ability to rapidly debug and diagnose problems is becoming more relevant. This session will cover common issues faced and techniques to diagnose them, including the use of bpftool for map and program introspection, the disassembling of programs to inspect generated eBPF instructions and other methods such as using debug prints and how to apply these techniques when eBPF programs are offloaded to the hardware.
Using the new extended Berkley Packet Filter capabilities in Linux to the improve performance of auditing security relevant kernel events around network, file and process actions.
Comprehensive XDP Offload-handling the Edge CasesNetronome
While XDP is less complex to offload than other forms of kernel functionality due to the fact that it sits at the bottom of the stack, there are a number of items that lead to complexity when dealing with XDP offload. This talk will explore some of the ideas around how to implement these concepts as well as share some of the results we have seen while implementing offload on a 32 bit architecture.
DISTRIBUTED PERFORMANCE ANALYSIS USING INFLUXDB AND THE LINUX EBPF VIRTUAL MA...InfluxData
Since the release of the Linux kernel 4.x series, a lot of enhancements have reached mainline to the eBPF ecosystem giving us the capability to do a lot more than just network stuff. The purpose of this talk is to provide an initial understanding on what eBPF programs are and how to hook the output of eBPF programs to InfluxDB in order to answer targeted questions at the cluster level and very specific fine-grained situations happening in our programs
Building Network Functions with eBPF & BCCKernel TLV
eBPF (Extended Berkeley Packet Filter) is an in-kernel virtual machine that allows running user-supplied sandboxed programs inside of the kernel. It is especially well-suited to network programs and it's possible to write programs that filter traffic, classify traffic and perform high-performance custom packet processing.
BCC (BPF Compiler Collection) is a toolkit for creating efficient kernel tracing and manipulation programs. It makes use of eBPF.
BCC provides an end-to-end workflow for developing eBPF programs and supplies Python bindings, making eBPF programs much easier to write.
Together, eBPF and BCC allow you to develop and deploy network functions safely and easily, focusing on your application logic (instead of kernel datapath integration).
In this session, we will introduce eBPF and BCC, explain how to implement a network function using BCC, discuss some real-life use-cases and show a live demonstration of the technology.
About the speaker
Shmulik Ladkani, Chief Technology Officer at Meta Networks,
Long time network veteran and kernel geek.
Shmulik started his career at Jungo (acquired by NDS/Cisco) implementing residential gateway software, focusing on embedded Linux, Linux kernel, networking and hardware/software integration.
Some billions of forwarded packets later, Shmulik left his position as Jungo's lead architect and joined Ravello Systems (acquired by Oracle) as tech lead, developing a virtual data center as a cloud-based service, focusing around virtualization systems, network virtualization and SDN.
Recently he co-founded Meta Networks where he's been busy architecting secure, multi-tenant, large-scale network infrastructure as a cloud-based service.
Video: https://www.facebook.com/atscaleevents/videos/1693888610884236/ . Talk by Brendan Gregg from Facebook's Performance @Scale: "Linux performance analysis has been the domain of ancient tools and metrics, but that's now changing in the Linux 4.x series. A new tracer is available in the mainline kernel, built from dynamic tracing (kprobes, uprobes) and enhanced BPF (Berkeley Packet Filter), aka, eBPF. It allows us to measure latency distributions for file system I/O and run queue latency, print details of storage device I/O and TCP retransmits, investigate blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. This talk will summarize this new technology and some long-standing issues that it can solve, and how we intend to use it at Netflix."
Not breaking userspace: the evolving Linux ABIAlison Chaiken
Don't break userspace" is famously one of the core tenets of Linux kernel development. The rule makes it possible for distros to upgrade the kernel independently of userspace applications. But what does the phrase actually mean in 2022? What portions of the kernel's interface are guaranteed stable and are safe for applications to rely on?
Kernel contributors try to make only backward-compatible changes to the procfs and sysfs filesystems. These virtual filesystems (VFS) constitute the primary applications binary interface (ABI). System calls in a C library like glibc send commands to and receive information from the kernel via the VFS. Linux userspace applications can then rely on the syscalls to interact with the OS or access the VFS directly.
Linux OS's have many artifacts besides procfs and sysfs, however. Which of them are part of the stable ABI? The kernel's documentation calls out the fact that kernel configuration parameters are not stable, but what about devicetree formats, the dmesg log, the BPF validator interface, /dev files, kernel command-line parameters, tracepoints and filesystem metadata? Changes to not explicitly stable parameters have often been the source of controversy.
The difficulty of adding features and fixing bugs without changing the stable ABI is universal in software development. Sometimes there is a stark choice between implementing an upstream fix and "breaking" the library's users. When inevitably the kernel ABI is modified for bug fixes, C-library developers try to balance support for the changes with customer stability expectations. For example, a recent fork of libpthread with an ABI break was created by the realtime Linux community in order to fix problems in time-critical systems like robotics. In 2021, the kernel added a "printk indexing" feature that will make it easier for applications to parse error messages in the dmesg log. The presentation should equip attendees to better understand the Linux ABI and feel better prepared to deal with changes to them that affect their own projects.
Debugging is an essential part of Linux kernel development. In
user-space we have the support of the kernel and many debugging tools, tracking down a kernel bug, instead, can be very difficult if you don't know the proper methodologies. This talk will cover some techniques to understand how the kernel works, hunt down and fix kernel bugs in order to become a better kernel developer.
eBPF Debugging Infrastructure - Current TechniquesNetronome
eBPF (extended Berkeley Packet Filter), in particular with its driver-level hook XDP (eXpress Data Path), has increased in importance over the past few years. As a result, the ability to rapidly debug and diagnose problems is becoming more relevant. This talk will cover common issues faced and techniques to diagnose them, including the use of bpftool for map and program introspection, the use of disassembly to inspect generated assembly code and other methods such as using debug prints and how to apply these techniques when eBPF programs are offloaded to the hardware.
The talk will also explore where the current gaps in debugging infrastructure are and suggest some of the next steps to improve this, for example, integrations with tools such as strace, valgrind or even the LLDB debugger.
O'Reilly Velocity New York 2016 presentation on modern Linux tracing tools and technology. Highlights the available tracing data sources on Linux (ftrace, perf_events, BPF) and demonstrates some tools that can be used to obtain traces, including DebugFS, the perf front-end, and most importantly, the BCC/BPF tool collection.
This talk will provide several examples of how Facebook engineers use BPF to scale the networking, prevent denial of service, secure containers, analyze performance. It’s suitable for BPF newbies and experts.
Alexei Starovoitov, Facebook
Similar to USENIX Vault'19: Performance analysis in Linux storage stack with BPF (20)
Overview of the fundamental roles in Hydropower generation and the components involved in wider Electrical Engineering.
This paper presents the design and construction of hydroelectric dams from the hydrologist’s survey of the valley before construction, all aspects and involved disciplines, fluid dynamics, structural engineering, generation and mains frequency regulation to the very transmission of power through the network in the United Kingdom.
Author: Robbie Edward Sayers
Collaborators and co editors: Charlie Sims and Connor Healey.
(C) 2024 Robbie E. Sayers
Immunizing Image Classifiers Against Localized Adversary Attacksgerogepatton
This paper addresses the vulnerability of deep learning models, particularly convolutional neural networks
(CNN)s, to adversarial attacks and presents a proactive training technique designed to counter them. We
introduce a novel volumization algorithm, which transforms 2D images into 3D volumetric representations.
When combined with 3D convolution and deep curriculum learning optimization (CLO), itsignificantly improves
the immunity of models against localized universal attacks by up to 40%. We evaluate our proposed approach
using contemporary CNN architectures and the modified Canadian Institute for Advanced Research (CIFAR-10
and CIFAR-100) and ImageNet Large Scale Visual Recognition Challenge (ILSVRC12) datasets, showcasing
accuracy improvements over previous techniques. The results indicate that the combination of the volumetric
input and curriculum learning holds significant promise for mitigating adversarial attacks without necessitating
adversary training.
6th International Conference on Machine Learning & Applications (CMLA 2024)ClaraZara1
6th International Conference on Machine Learning & Applications (CMLA 2024) will provide an excellent international forum for sharing knowledge and results in theory, methodology and applications of on Machine Learning & Applications.
Using recycled concrete aggregates (RCA) for pavements is crucial to achieving sustainability. Implementing RCA for new pavement can minimize carbon footprint, conserve natural resources, reduce harmful emissions, and lower life cycle costs. Compared to natural aggregate (NA), RCA pavement has fewer comprehensive studies and sustainability assessments.
Cosmetic shop management system project report.pdfKamal Acharya
Buying new cosmetic products is difficult. It can even be scary for those who have sensitive skin and are prone to skin trouble. The information needed to alleviate this problem is on the back of each product, but it's thought to interpret those ingredient lists unless you have a background in chemistry.
Instead of buying and hoping for the best, we can use data science to help us predict which products may be good fits for us. It includes various function programs to do the above mentioned tasks.
Data file handling has been effectively used in the program.
The automated cosmetic shop management system should deal with the automation of general workflow and administration process of the shop. The main processes of the system focus on customer's request where the system is able to search the most appropriate products and deliver it to the customers. It should help the employees to quickly identify the list of cosmetic product that have reached the minimum quantity and also keep a track of expired date for each cosmetic product. It should help the employees to find the rack number in which the product is placed.It is also Faster and more efficient way.
We have compiled the most important slides from each speaker's presentation. This year’s compilation, available for free, captures the key insights and contributions shared during the DfMAy 2024 conference.
About
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
• Remote control: Parallel or serial interface.
• Compatible with MAFI CCR system.
• Compatible with IDM8000 CCR.
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
• Easy in configuration using DIP switches.
Technical Specifications
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
Key Features
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
• Remote control: Parallel or serial interface
• Compatible with MAFI CCR system
• Copatiable with IDM8000 CCR
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
Application
• Remote control: Parallel or serial interface.
• Compatible with MAFI CCR system.
• Compatible with IDM8000 CCR.
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
• Easy in configuration using DIP switches.
USENIX Vault'19: Performance analysis in Linux storage stack with BPF
1. Performance Analysis in
Linux Storage Stack with BPF
Taeung Song
KossLab
Daniel T. Lee
The University of Soongsil
BPF programming hands-on tutorials
6. “Run code in the kernel”
$ readelf -h bpf-prog.o | grep Machine
Machine: Linux BPF
What is BPF ?
7. “Run code in the kernel”
$ readelf -h bpf-prog.o | grep Machine
Machine: Linux BPF
Machine: Advanced Micro Devices X86-64
What is BPF ?
8. “Run code in the kernel”
$ readelf -h bpf-prog.o | grep Machine
Machine: Linux BPF
Machine: Advanced Micro Devices X86-64
What is BPF ?
writing C program
clang / llc
BPF instruction
9. “Run code in the kernel”
$ readelf -h bpf-prog.o | grep Machine
Machine: Linux BPF
Machine: Advanced Micro Devices X86-64
What is BPF ?
writing C program
clang / llc
BPF instruction
but, restricted
10. “Run BPF code in the kernel”
$ readelf -h bpf-prog.o | grep Machine
Machine: Linux BPF
Machine: Advanced Micro Devices X86-64
What is BPF ?
writing C program
clang / llc
BPF instruction
but, restricted
11. Is it safe ?
the image from http://www.tunisiaonline.com/travel-to-tunisia-in-2017/
12. Is it safe ?
“BPF verifier(in-kernel) guarantees”
13. Is it safe ?
“BPF verifier(in-kernel) guarantees”
Check BPF program & Prevent problems
before the injection
49. VFS Layer
Individual Filesystem Layer
Block Layer
System call Interface
GNU C Library
User Applications
user space
kernel space
BPF hands-on tutorials:
50. VFS Layer
Individual Filesystem Layer
Block Layer
System call Interface
GNU C Library
User Applications
user space
kernel spaceFocus on Linux Storage Stack
BPF hands-on tutorials:
52. But,
BPF contains not only those advantages
(blktrace, tracepoints, ...)
but also + 𝜶
53. But,
BPF contains not only those advantages
(blktrace, tracepoints, ...)
but also + 𝜶: low-overhead profiling and tracing,
rich introspection,
detailedly tracking kernel data,
...
54. Before BPF hands-on tutorials:
Stage 00: Traces the latency between
blk_mq_start_request()
-> blk_account_io_completion()
$ cd ~/git/linux/samples/bpf
$ sudo ./tracex3
failed to create kprobe 'blk_start_request' error 'No such file or directory'
# blk_start_request() don’t exist anymore in latest kernel version
# Edit tracex3_kern.c to replace ‘blk_start_request’ to ‘blk_mq_start_request’
$ vim tracex3_kern.c
$ make
# Retry to run it
$ sudo ./tracex3
55. Before BPF hands-on tutorials:
Stage 00: Traces the latency between
blk_mq_start_request()
-> blk_account_io_completion()
$ ls tracex3*
tracex3 tracex3_kern.c tracex3_kern.o tracex3_user.c tracex3_user.o
$ ls bpf_load.o
bpf_load.o
$ readelf -h tracex3_kern.o | grep Machine
Machine: Linux BPF
$ readelf -h tracex3_user.o | grep Machine
Machine: Advanced Micro Devices X86-64
$ readelf -h tracex3 | grep Machine
Machine: Advanced Micro Devices X86-64
56. Before BPF hands-on tutorials:
Stage 00: Traces the latency between
blk_mq_start_request()
-> blk_account_io_completion()
$ ls tracex3*
tracex3 tracex3_kern.c tracex3_kern.o tracex3_user.c tracex3_user.o
$ ls bpf_load.o
bpf_load.o
$ readelf -h tracex3_kern.o | grep Machine
Machine: Linux BPF
$ readelf -h tracex3_user.o | grep Machine
Machine: Advanced Micro Devices X86-64
$ readelf -h tracex3 | grep Machine
Machine: Advanced Micro Devices X86-64
57. Before BPF hands-on tutorials:
Stage 00: Traces the latency between
blk_mq_start_request()
-> blk_account_io_completion()
$ ls tracex3*
tracex3 tracex3_kern.c tracex3_kern.o tracex3_user.c tracex3_user.o
$ ls bpf_load.o
bpf_load.o
$ readelf -h tracex3_kern.o | grep Machine
Machine: Linux BPF
$ readelf -h tracex3_user.o | grep Machine
Machine: Advanced Micro Devices X86-64
$ readelf -h tracex3 | grep Machine
Machine: Advanced Micro Devices X86-64
58. Before BPF hands-on tutorials:
Stage 00: Traces the latency between
blk_mq_start_request()
-> blk_account_io_completion()
$ ls tracex3*
tracex3 tracex3_kern.c tracex3_kern.o tracex3_user.c tracex3_user.o
$ ls bpf_load.o
bpf_load.o
$ readelf -h tracex3_kern.o | grep Machine
Machine: Linux BPF
$ readelf -h tracex3_user.o | grep Machine
Machine: Advanced Micro Devices X86-64
$ readelf -h tracex3 | grep Machine
Machine: Advanced Micro Devices X86-64
79. # For parsing debug info of ‘vmlinux’
#
$ sudo apt-get install dwarves
# Download BPF examples ‘vault19_bpf_tutorial’
#
$ git clone https://github.com/kernel-digging/vault19_bpf_tutorial.git
BPF hands-on tutorials:
Installations: This BPF tutorial environment
80. BPF hands-on tutorials:
Examples: see ‘vault19_bpf_tutorial’
$ cd ~/git/vault19-bpf-tutorial
$ ls
linux-samples-bpf-Makfile.patch stage06_max_latency_stacktrace
stage01_submit_bio_call_time stage07_latency_other_section
stage02_bio_endio_call_time stage08_pagecache_miss_counts
stage03_bio_latency_map stage09_pagecache_miss_pid_filter
stage04_max_latency stage10_ctracer-data+func_tracing
stage05_max_latency_sector
81. BPF hands-on tutorials:
Preparation: modify samples/bpf/Makefile
# just check the diff of Makefile
# see both BPF agents(user) and programs(kernel)
$ cat ~/git/vault19-bpf-tutorial/linux-samples-bpf-Makfile.patch
# The Makefile is already modified in given vbox image
$ cd ~/git/linux/samples/bpf
$ vim Makefile
87. BPF hands-on tutorials:
$ cd ~/git/vault19_bpf_tutorial/stage01_submit_bio_call_time
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ cp ./vault19_bio_trace_kern.c ~/git/linux/samples/bpf/
$ cp ./vault19_bio_trace_user.c ~/git/linux/samples/bpf/
$ cd ~/git/linux/samples/bpf/
$ make
$ sudo ./vault19_bio_trace
Stage 01: Record the time submit_bio() is called
Just run it !!
(copy & make & run)
88. BPF hands-on tutorials:
$ cd ~/git/vault19_bpf_tutorial/stage01_submit_bio_call_time
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ less vault19_bio_trace_kern.c
$ less vault19_bio_trace_user.c
Stage 01: Record the time submit_bio() is called
Check the src files !!
(How does it work ?)
106. $ cd ~/git/vault19_bpf_tutorial/stage02_bio_endio_call_time
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ cp ./vault19_bio_trace_kern.c ~/git/linux/samples/bpf/
$ cd ~/git/linux/samples/bpf/
$ make
$ sudo ./vault19_bio_trace
Stage 02: Record the time bio_endio() is called
BPF hands-on tutorials:
Just run it !!
(copy & make & run)
107. $ cd ~/git/vault19_bpf_tutorial/stage02_bio_endio_call_time
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ diff stage01_submit_bio_call_time/vault19_bio_trace_kern.c
./vault19_bio_trace_kern.c
Stage 02: Record the time bio_endio() is called
BPF hands-on tutorials:
Check the src files !!
(How does it work ?)
117. $ cd ~/git/vault19_bpf_tutorial/stage03_bio_latency_map
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ cp ./vault19_bio_trace_kern.c ~/git/linux/samples/bpf/
$ cd ~/git/linux/samples/bpf/
$ make
$ sudo ./vault19_bio_trace
Stage 03: Calculate the bio latency between
submit_bio() -> bio_endio()
BPF hands-on tutorials:
Just run it !!
(copy & make & run)
118. $ cd ~/git/vault19_bpf_tutorial/stage03_bio_latency_map
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ diff stage02_bio_endio_call_time/vault19_bio_trace_kern.c
./vault19_bio_trace_kern.c
Stage 03: Calculate the bio latency between
submit_bio() -> bio_endio()
BPF hands-on tutorials:
Check the src files !!
(How does it work ?)
132. $ cd ~/git/vault19_bpf_tutorial/stage04_max_latency
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ cp ./vault19_bio_trace_kern.c ~/git/linux/samples/bpf/
$ cp ./vault19_bio_trace_user.c ~/git/linux/samples/bpf/
$ cd ~/git/linux/samples/bpf/
$ make
$ sudo ./vault19_bio_trace
Stage 04: Get the max latency between
submit_bio() -> bio_endio()
BPF hands-on tutorials:
Just run it !!
(copy & make & run)
133. $ cd ~/git/vault19_bpf_tutorial/stage04_max_latency
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ diff stage03_bio_latency_map/vault19_bio_trace_kern.c
./vault19_bio_trace_kern.c
$ diff stage03_bio_latency_map/vault19_bio_trace_user.c
./vault19_bio_trace_user.c
Stage 04: Get the max latency between
submit_bio() -> bio_endio()
BPF hands-on tutorials:
Check the src files !!
(How does it work ?)
147. $ cd ~/git/vault19_bpf_tutorial/stage05_max_latency_sector
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ cp ./vault19_bio_trace_kern.c ~/git/linux/samples/bpf/
$ cp ./vault19_bio_trace_user.c ~/git/linux/samples/bpf/
$ cd ~/git/linux/samples/bpf/
$ make
Stage 05: Getting sector of the max latency
submit_bio() -> bio_endio()
BPF hands-on tutorials:
Just run it !!
(copy & make & run)
148. $ cd ~/git/vault19_bpf_tutorial/stage05_max_latency_sector
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ diff stage04_max_latency/vault19_bio_trace_kern.c
./vault19_bio_trace_kern.c
$ diff stage04_max_latency/vault19_bio_trace_user.c
./vault19_bio_trace_user.c
Stage 05: Getting sector of the max latency
submit_bio() -> bio_endio()
BPF hands-on tutorials:
Check the src files !!
(How does it work ?)
156. $ cd ~/git/vault19_bpf_tutorial/stage06_max_latency_stacktrace
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ cp ./vault19_bio_trace_kern.c ~/git/linux/samples/bpf/
$ cp ./vault19_bio_trace_user.c ~/git/linux/samples/bpf/
$ cd ~/git/linux/samples/bpf/
$ make
$ sudo ./vault19_bio_trace
Stage 06: Getting stacktrace of the max latency
submit_bio() -> bio_endio()
BPF hands-on tutorials:
Just run it !!
(copy & make & run)
157. $ cd ~/git/vault19_bpf_tutorial/stage06_max_latency_stacktrace
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ diff stage05_max_latency_sector/vault19_bio_trace_kern.c
./vault19_bio_trace_kern.c
$ diff stage05_max_latency_sector/vault19_bio_trace_user.c
./vault19_bio_trace_user.c
Stage 06: Getting stacktrace of the max latency
submit_bio() -> bio_endio()
BPF hands-on tutorials:
Check the src files !!
(How does it work ?)
174. # Stage 07: latency other section
$
$ sudo ./vault19_bio_trace
...
kworker/0:2-975 [000] ....6981879095488: 0: blk_mq_start_request(rq=0xffff9f8af7054000) is called!
sshd-1824 [000] ..s.6981879829511: 0: blk_account_io_completion(rq=0xffff9f8af7054000) is called!
sshd-1824 [000] ..s.6981879882239: 0: blk_mq_start_request() -> blk_account_io_completion() time
duration: 737423 ns
kworker/0:2-975 [000] ....6981942334663: 0: blk_mq_start_request(rq=0xffff9f8b3aef12c0) is called!
vault19_bio_tra-19703 [000] ..s.6981942888506: 0: blk_account_io_completion(rq=0xffff9f8b3aef12c0) is called!
vault19_bio_tra-19703 [000] ..s.6981942932035: 0: blk_mq_start_request() -> blk_account_io_completion() time
duration: 559523 ns
kworker/0:2-975 [000] ....6983927192671: 0: blk_mq_start_request(rq=0xffff9f8af70552c0) is called!
sshd-1824 [000] ..s.6983927893060: 0: blk_account_io_completion(rq=0xffff9f8af70552c0) is called!
sshd-1824 [000] ..s.6983927947056: 0: blk_mq_start_request() -> blk_account_io_completion() time
duration: 703701 ns
kworker/0:2-975 [000] ....6983990342270: 0: blk_mq_start_request(rq=0xffff9f8b3aef0000) is called!
vault19_bio_tra-19703 [000] ..s.6983991154089: 0: blk_account_io_completion(rq=0xffff9f8b3aef0000) is called!
vault19_bio_tra-19703 [000] ..s.6983991205574: 0: blk_mq_start_request() -> blk_account_io_completion() time
duration: 815129 ns
175. $ cd ~/git/vault19_bpf_tutorial/stage07_latency_other_section
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ cp ./vault19_bio_trace_kern.c ~/git/linux/samples/bpf/
$ cp ./vault19_bio_trace_user.c ~/git/linux/samples/bpf/
$ cd ~/git/linux/samples/bpf/
$ make
$ sudo ./vault19_bio_trace
Stage 07: Calculate the request latency between
blk_mq_start_request() -> blk_account_io_completion()
BPF hands-on tutorials:
Just run it !!
(copy & make & run)
176. $ cd ~/git/vault19_bpf_tutorial/stage07_latency_other_section
$ ls
vault19_bio_trace_kern.c vault19_bio_trace_user.c
$ diff stage03_bio_latency_map/vault19_bio_trace_kern.c
./vault19_bio_trace_kern.c
$ diff stage03_bio_latency_map/vault19_bio_trace_user.c
./vault19_bio_trace_user.c
Stage 07: Calculate the request latency between
blk_mq_start_request() -> blk_account_io_completion()
BPF hands-on tutorials:
Check the src files !!
(How does it work ?)