bpf2c and eBPF-for-Windows should support global variables in BPF programs (aka platform variables) as defined in 5.4 of BPF ISA

[Alan-Jowett]

The BPF ISA defines additional 64bit immediate load instructions. eBPF-for-Windows should add support for type 3 at a minimum. This support can improve the performance of certain BPF programs by eliminating the need to perform map lookups.

5.4.  64-bit immediate instructions

   Instructions with the IMM 'mode' modifier use the wide instruction
   encoding defined in Instruction encoding (Section 3), and use the
   'src_reg' field of the basic instruction to hold an opcode subtype.

   The following table defines a set of {IMM, DW, LD} instructions with
   opcode subtypes in the 'src_reg' field, using new terms such as "map"
   defined further below:

    +=========+================================+==========+==========+
    | src_reg | pseudocode                     | imm type | dst type |
    +=========+================================+==========+==========+
    | 0x0     | dst = (next_imm << 32) | imm   | integer  | integer  |
    +---------+--------------------------------+----------+----------+
    | 0x1     | dst = map_by_fd(imm)           | map fd   | map      |
    +---------+--------------------------------+----------+----------+
    | 0x2     | dst = map_val(map_by_fd(imm))  | map fd   | data     |
    |         | + next_imm                     |          | address  |
    +---------+--------------------------------+----------+----------+
    | 0x3     | dst = var_addr(imm)            | variable | data     |
    |         |                                | id       | address  |
    +---------+--------------------------------+----------+----------+
    | 0x4     | dst = code_addr(imm)           | integer  | code     |
    |         |                                |          | address  |
    +---------+--------------------------------+----------+----------+
    | 0x5     | dst = map_by_idx(imm)          | map      | map      |
    |         |                                | index    |          |
    +---------+--------------------------------+----------+----------+
    | 0x6     | dst = map_val(map_by_idx(imm)) | map      | data     |
    |         | + next_imm                     | index    | address  |
    +---------+--------------------------------+----------+----------+

                 Table 12: 64-bit immediate instructions

[Alan-Jowett]

iovisor/ubpf#590

[Alan-Jowett]

vbpf/ebpf-verifier#763

[saxena-anurag]

Question: Are these global variables compile time constants?

[lmb]

On Linux, the use case for this feature is to be able to modify a "compile time constant" at load time of a BPF program. For example being able to change ETH_HLEN to accomodate VLAN tagging or similar. The verifier will then inline the constant into the BPF instruction stream before JITing. This makes this essentially free in terms of performance.

Roughly how it works from user space (I think this is type 0x2 in the list above):

1. Compile a program which refers to a volatile const. The compiler turns the reference to the const into a load from the .rodata section at a specific offset
2. Load the ELF and synthesis a single-element array map from the .rodata section
3. User space then has the opportunity to change the contents of the array map via some API
4. Before load, the map is loaded and frozen via BPF_MAP_FREEZE
5. Verifier sees the load, realises that the map is frozen, and replaces the ldimm64 with a constant load

[Alan-Jowett]

More information:
Source program:

// Copyright (c) Prevail Verifier contributors.
// SPDX-License-Identifier: MIT

#include "bpf.h"

static volatile uint32_t global_var = 0;
static volatile uint32_t global_var_2 = 0;


int func(void* ctx) {
    global_var ++;
    global_var_2 += 2;
    return 0;
}

translated BPF byte code:

int func(void * ctx):
; global_var ++;
   0: (18) r1 = map[id:43][0]+0
   2: (61) r2 = *(u32 *)(r1 +0)
   3: (07) r2 += 1
   4: (63) *(u32 *)(r1 +0) = r2
; global_var_2 += 2;
   5: (18) r1 = map[id:43][0]+4
   7: (61) r2 = *(u32 *)(r1 +0)
   8: (07) r2 += 2
   9: (63) *(u32 *)(r1 +0) = r2
; return 0;
  10: (b7) r0 = 0
  11: (95) exit

This shows that all global variables are translated into a single global map.

[shpalani]

As per today's brainstorming discussion in eBPF-for-Windows Office hours, the dependency of order in fixes:

1. Verifier support (Support additional 64bit immediate instruction modes vbpf/ebpf-verifier#763)
2. Bpf2c support in ebpf-for-windows repo
3. Finally, this issue is to support global variables in eBPF programs in ebpf-for-windows.

This issue aims to reduce the number of map lookups (map_lookup_elem) performed by user-mode programs on the same key/value (e.g., Observability: Fields enabled or disabled to track metrics/debugs).
The value in the map can be updated at runtime (dynamically) by the user-mode program, after setting the initial value.