Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Describe BPF helper bpf_map_lookup_elem #5408

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

pchaigno
Copy link
Contributor

WIP

For now, resources are only allowed if their base type is one of
constant, integer, or flag. This is particularly useful when combined
with syz_create_resource (cf. subsequent commits).

Signed-off-by: Paul Chaignon <[email protected]>
The size of BPF map keys (and values) are fixed at map creation time. In
the descriptions, we must therefore ensure that the size declared when
creating the map matches the size used during the map lookup in the BPF
program.

To that end, we create a resource from the map key size with
syz_create_resource$map_key_size. This resource is then used in both
bpf$MAP_CREATE and bpf$PROG_LOAD. More specifically, it is used in two
places in the loaded BPF program, as shown below.

    1: r1 = map[id:10]
    2: r8 = X
    3: *(u64 *)(r10 -8) = r8
    4: r2 = r10
    5: r2 -= 8
    6: call bpf_map_lookup_elem

The key size resource is used on instruction 3 to determine the
size of the store instruction on the stack, and on instruction 5 to set
the corresponding offset to the stack. For instruction 5, the resource
can directly be used. For instruction 3 however, the resource is used in
a conditional fields as the instruction itself will change depending on
the key size.

Note that the description only supports four key sizes currently (8, 16,
32, and 64 bits). Supporting more sizes would be a more complex, with a
variable number of store instructions needed.

In addition, nothing in the description forces the map_key_size used at
map creation to be the same as the map_key_size used in the program.
That being said, in a given generated program, there will likely be only
so many such resources, so the likelihood of the two resources being the
same is high.

Signed-off-by: Paul Chaignon <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant