Summary
pkg/ebpf/c/vmlinux_missing.h defines kernel-style VM_READ / VM_WRITE / VM_EXEC / VM_SHARED (145:149:pkg/ebpf/c/vmlinux_missing.h), matching include/linux/mm.h / struct vm_area_struct->vm_flags.
Some call sites also handle values that are not vm_flags but userland protection requests from mmap(2) / mprotect(2) (uapi PROT_*, same numeric bits for R/W/X on typical Linux, different meaning).
The issue is to review every use of those VM_* symbols in the tree (below), decide where the code should use PROT_* names (and optional PROT_* #defines in vmlinux_missing.h for BPF) so readers and future diffs match kernel semantics, and where VM_* must stay because the value is really vma->vm_flags.
Scope: current VM_{READ,WRITE,EXEC} uses (excluding syscall name noise)
| File |
Program / function |
Value being tested |
Related events / signals |
tracee.bpf.c |
trace_mmap_alert |
prot = mmap syscall 3rd arg |
mem_prot_alert (mmap W|X) |
tracee.bpf.c |
trace_security_mmap_file |
PARM2 prot (mmap request on hook) |
shared_object_loaded, security_mmap_file |
tracee.bpf.c |
trace_security_file_mprotect |
PARM2 reqprot |
security_file_mprotect, mem_prot_alert (mprotect heuristics) |
tracee.bpf.c |
same |
prev_prot = get_vma_flags(vma) |
same — expected to stay VM_* |
SYSCALL_PROCESS_VM_WRITEV in arch.h is unrelated; ignore for this review.
User space (out of vmlinux_missing.h but part of the same story)
-
pkg/events/parse_args.go: which fields are parsed with ParseMmapProt vs ParseVmFlags for security_file_mprotect, mem_prot_alert, etc. (prot / reqprot vs prev_prot).
-
common/parsers/data_parsers.go: ParseMmapProt vs ParseVmFlags already encode the uapi vs kernel split; align naming in docs/comments with BPF once nomenclature is decided.
Acceptance criteria
Notes
This is a naming / review item; same bit masks, behaviour unchanged unless a bug is found in classification.
Summary
pkg/ebpf/c/vmlinux_missing.hdefines kernel-styleVM_READ/VM_WRITE/VM_EXEC/ VM_SHARED (145:149:pkg/ebpf/c/vmlinux_missing.h), matchinginclude/linux/mm.h/struct vm_area_struct->vm_flags.Some call sites also handle values that are not
vm_flagsbut userland protection requests frommmap(2)/mprotect(2)(uapiPROT_*, same numeric bits for R/W/X on typical Linux, different meaning).The issue is to review every use of those
VM_*symbols in the tree (below), decide where the code should usePROT_*names (and optionalPROT_*#definesinvmlinux_missing.hfor BPF) so readers and future diffs match kernel semantics, and whereVM_*must stay because the value is reallyvma->vm_flags.Scope: current
VM_{READ,WRITE,EXEC}uses (excluding syscall name noise)tracee.bpf.ctrace_mmap_alertprot= mmap syscall 3rd argmem_prot_alert(mmap W|X)tracee.bpf.ctrace_security_mmap_fileprot(mmap request on hook)shared_object_loaded,security_mmap_filetracee.bpf.ctrace_security_file_mprotectreqprotsecurity_file_mprotect,mem_prot_alert(mprotect heuristics)tracee.bpf.cprev_prot=get_vma_flags(vma)VM_*SYSCALL_PROCESS_VM_WRITEVinarch.his unrelated; ignore for this review.User space (out of
vmlinux_missing.hbut part of the same story)pkg/events/parse_args.go: which fields are parsed withParseMmapProtvsParseVmFlagsforsecurity_file_mprotect,mem_prot_alert, etc. (prot / reqprot vs prev_prot).common/parsers/data_parsers.go:ParseMmapProtvsParseVmFlagsalready encode the uapi vs kernel split; align naming in docs/comments with BPF once nomenclature is decided.Acceptance criteria
Each row above has an explicit decision: keep
VM_*, or usePROT_*in code/comments (and add minimalPROT_*invmlinux_missing.hfor BPF if needed, without redefinition clashes with BTF headers).Mixed comparisons (e.g.
reqprotvsprev_prot) are documented where both layers appear:PROT_*vsVM_*in the same if is intentional and obvious.Optional: short dev note in
vmlinux_missing.hnext to theVM_*or newPROT_*block pointing to this issue.Notes
This is a naming / review item; same bit masks, behaviour unchanged unless a bug is found in classification.