commit | d1791f0b06ee3e7234fec407b9df847e5275e002 | [log] [tgz] |
---|---|---|
author | Marek Vavruša <marek@vavrusa.com> | Wed Oct 03 08:43:06 2018 -0700 |
committer | yonghong-song <ys114321@gmail.com> | Wed Oct 03 08:43:06 2018 -0700 |
tree | bfdc885eff03a8779cf4ad0cef0bd4ab53ac5ce8 | |
parent | 9252a8d03cccfae64a772bb71d431b52017b4121 [diff] |
lua: codegen tests, tracking inverse form of null guards, IPv6 header builtins (#1991) * lua: eliding repetitive NULL checks, fixes for read types, luacheck This fixes verifier failures in some kernel versions that track whether a possible NULL pointer has been check (and shouldn't be checked twice). It also fixes accessing memory from maps with composite keys. It fixes a case when temporary variable is used in condition, and the body of the condition contains just an assignment from immediate value to a variable that existed before the condition, e.g.: ``` local x = 1 -- Assign constant to 'x', it will be materialized here if skb.len > 0 then -- New BB, not possible to fold as condition isn't const x = 2 -- Assign constant, it failed to materialize here end -- End of BB -- Value of x is always 1 ``` The `bpf.socket()` support ljsyscall socket as first parameter, and fixes compatibility with newer ljsyscall (type name has changed). * reverse BPF_LD ntohl() semantics for <= 32bit loads as well The loads using traditional instructions always do ntohl(): https://www.kernel.org/doc/Documentation/networking/filter.txt They are however needed to support reads not using `skb`, e.g. NET_OFF * proto: add builtins for traversing IPv6 header and extension headers The IPv6 header is fixed size (40B), but it may contain either extension header, or transport protocol after it, so the caller must check the `next_header` field before traversing to determine which dissector to use to traverse it, e.g.: ``` if ip6.next_header == 44 then ip6 = ip6.ip6_opt -- Skip fragment header end if ip6.next_header == c.ip.proto_tcp then local tcp = ip6.tcp -- Finally, TCP end ``` * reverse ntohl() for indirect BPF_LD as well * lua: started codegen tests, direct skb support, bugfixes This starts adding compiler correctness tests for basic expressions, variable source tracking, and control flow. Added: * direct skb->data access (in addition to BPF_LDABS, BPF_LDIND) * loads and stores from skb->data and map value backed memory * unified variable source tracking (ptr_to_ctx, ptr_to_map[_or_null], ptr_to_skb, ptr_to_pkt, ptr_to_stack) * BPF constants introduced between 4.10-4.15 * bpf.dump_string() to dump generated assembly (text) to string Fixes: * pointer nil check tracking * dissectors for map value backed memory * ljsyscall extensions when the version is too old * KPRI nil variables used in conditions * wrongly elided constant materialization on condition-less jumps * loads/stores from stack memory using variable offset * lua: track inverse null guards (if x ~= nil) The verifier prohibits pointer comparisons except the first NULL check, so both forms must be tracked, otherwise it will check for NULL twice and verifier will reject it. * lua: support cdata and constants larger than i32, fix shadowed variables This adds support for numeric cdata constants (either in program, or retrieved with GGET/UGET). Values larger than i32 are coerced into i64. This also fixes shadowing of variables, and fixes materialization of result of variable copy at the end of basic block.
BCC is a toolkit for creating efficient kernel tracing and manipulation programs, and includes several useful tools and examples. It makes use of extended BPF (Berkeley Packet Filters), formally known as eBPF, a new feature that was first added to Linux 3.15. Much of what BCC uses requires Linux 4.1 and above.
eBPF was described by Ingo Molnár as:
One of the more interesting features in this cycle is the ability to attach eBPF programs (user-defined, sandboxed bytecode executed by the kernel) to kprobes. This allows user-defined instrumentation on a live kernel image that can never crash, hang or interfere with the kernel negatively.
BCC makes BPF programs easier to write, with kernel instrumentation in C (and includes a C wrapper around LLVM), and front-ends in Python and lua. It is suited for many tasks, including performance analysis and network traffic control.
This example traces a disk I/O kernel function, and populates an in-kernel power-of-2 histogram of the I/O size. For efficiency, only the histogram summary is returned to user-level.
# ./bitehist.py Tracing... Hit Ctrl-C to end. ^C kbytes : count distribution 0 -> 1 : 3 | | 2 -> 3 : 0 | | 4 -> 7 : 211 |********** | 8 -> 15 : 0 | | 16 -> 31 : 0 | | 32 -> 63 : 0 | | 64 -> 127 : 1 | | 128 -> 255 : 800 |**************************************|
The above output shows a bimodal distribution, where the largest mode of 800 I/O was between 128 and 255 Kbytes in size.
See the source: bitehist.py. What this traces, what this stores, and how the data is presented, can be entirely customized. This shows only some of many possible capabilities.
See INSTALL.md for installation steps on your platform.
See FAQ.txt for the most common troubleshoot questions.
See docs/reference_guide.md for the reference guide to the bcc and bcc/BPF APIs.
Some of these are single files that contain both C and Python, others have a pair of .c and .py files, and some are directories of files.
Examples:
Tools that help to introspect BPF programs.
BPF guarantees that the programs loaded into the kernel cannot crash, and cannot run forever, but yet BPF is general purpose enough to perform many arbitrary types of computation. Currently, it is possible to write a program in C that will compile into a valid BPF program, yet it is vastly easier to write a C program that will compile into invalid BPF (C is like that). The user won't know until trying to run the program whether it was valid or not.
With a BPF-specific frontend, one should be able to write in a language and receive feedback from the compiler on the validity as it pertains to a BPF backend. This toolkit aims to provide a frontend that can only create valid BPF programs while still harnessing its full flexibility.
Furthermore, current integrations with BPF have a kludgy workflow, sometimes involving compiling directly in a linux kernel source tree. This toolchain aims to minimize the time that a developer spends getting BPF compiled, and instead focus on the applications that can be written and the problems that can be solved with BPF.
The features of this toolkit include:
In the future, more bindings besides python will likely be supported. Feel free to add support for the language of your choice and send a pull request!
At Red Hat Summit 2015, BCC was presented as part of a session on BPF. A multi-host vxlan environment is simulated and a BPF program used to monitor one of the physical interfaces. The BPF program keeps statistics on the inner and outer IP addresses traversing the interface, and the userspace component turns those statistics into a graph showing the traffic distribution at multiple granularities. See the code here.
Already pumped up to commit some code? Here are some resources to join the discussions in the IOVisor community and see what you want to work on.
Looking for more information on BCC and how it's being used? You can find links to other BCC content on the web in LINKS.md.