aboutsummaryrefslogtreecommitdiff
path: root/crypto
diff options
context:
space:
mode:
authorGravatar Stanislav Fomichev <sdf@google.com> 2022-06-28 10:43:09 -0700
committerGravatar Alexei Starovoitov <ast@kernel.org> 2022-06-29 13:21:52 -0700
commit9113d7e48e9128522b9f5a54dfd30dff10509a92 (patch)
treeb49fb1565e0169bc1ddf7a87d20b29446eee694d /crypto
parentbpf: implement BPF_PROG_QUERY for BPF_LSM_CGROUP (diff)
downloadlinux-9113d7e48e9128522b9f5a54dfd30dff10509a92.tar.gz
linux-9113d7e48e9128522b9f5a54dfd30dff10509a92.tar.bz2
linux-9113d7e48e9128522b9f5a54dfd30dff10509a92.zip
bpf: expose bpf_{g,s}etsockopt to lsm cgroup
I don't see how to make it nice without introducing btf id lists for the hooks where these helpers are allowed. Some LSM hooks work on the locked sockets, some are triggering early and don't grab any locks, so have two lists for now: 1. LSM hooks which trigger under socket lock - minority of the hooks, but ideal case for us, we can expose existing BTF-based helpers 2. LSM hooks which trigger without socket lock, but they trigger early in the socket creation path where it should be safe to do setsockopt without any locks 3. The rest are prohibited. I'm thinking that this use-case might be a good gateway to sleeping lsm cgroup hooks in the future. We can either expose lock/unlock operations (and add tracking to the verifier) or have another set of bpf_setsockopt wrapper that grab the locks and might sleep. Reviewed-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/r/20220628174314.1216643-7-sdf@google.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'crypto')
0 files changed, 0 insertions, 0 deletions