summaryrefslogtreecommitdiff
path: root/COPYING
diff options
context:
space:
mode:
authorAlexei Starovoitov <ast@kernel.org>2020-03-05 00:41:06 +0300
committerAlexei Starovoitov <ast@kernel.org>2020-03-05 00:47:16 +0300
commit9ce6010290587f4b0c57e2819481bd5ba9668349 (patch)
tree7e9836d1926fce0e65362a47474fed446ea75f8c /COPYING
parentcc6fa771024ffdb428bdf25a94309cf21e8ef1b9 (diff)
parent3d08b6f29cf33aeaf301553d8d3805f0aa609df7 (diff)
downloadlinux-9ce6010290587f4b0c57e2819481bd5ba9668349.tar.xz
Merge branch 'bpf_modify_ret'
KP Singh says: ==================== v3 -> v4: * Fix a memory leak noticed by Daniel. v2 -> v3: * bpf_trampoline_update_progs -> bpf_trampoline_get_progs + const qualification. * Typos in commit messages. * Added Andrii's Acks. v1 -> v2: * Adressed Andrii's feedback. * Fixed a bug that Alexei noticed about nop generation. * Rebase. This was brought up in the KRSI v4 discussion and found to be useful both for security and tracing programs. https://lore.kernel.org/bpf/20200225193108.GB22391@chromium.org/ The modify_return programs are allowed for security hooks (with an extra CAP_MAC_ADMIN check) and functions whitelisted for error injection (ALLOW_ERROR_INJECTION). The "security_" check is expected to be cleaned up with the KRSI patch series. Here is an example of how a fmod_ret program behaves: int func_to_be_attached(int a, int b) { <--- do_fentry do_fmod_ret: <update ret by calling fmod_ret> if (ret != 0) goto do_fexit; original_function: <side_effects_happen_here> } <--- do_fexit ALLOW_ERROR_INJECTION(func_to_be_attached, ERRNO) The fmod_ret program attached to this function can be defined as: SEC("fmod_ret/func_to_be_attached") int BPF_PROG(func_name, int a, int b, int ret) { // This will skip the original function logic. return -1; } ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions