kernel/linux.git/security/device_cgroup.c, branch v6.6.132

device_cgroup: Fix kernel-doc warnings in device_cgroup

2023-06-21T13:30:49+00:00

Fix kernel-doc warnings in device_cgroup: security/device_cgroup.c:835: warning: Excess function parameter 'dev_cgroup' description in 'devcgroup_legacy_check_permission'. Signed-off-by: Gaosheng Cui Signed-off-by: Paul Moore

lsm: fix a number of misspellings

2023-05-25T21:52:15+00:00

A random collection of spelling fixes for source files in the LSM layer. Reviewed-by: Casey Schaufler Signed-off-by: Paul Moore

device_cgroup: Fix typo in devcgroup_css_alloc description

2023-03-08T22:06:06+00:00

Fix the stale cgroup.c path in the devcgroup_css_alloc() description. Signed-off-by: Kamalesh Babulal Signed-off-by: Paul Moore

device_cgroup: Roll back to original exceptions after copy failure

2022-11-16T23:28:55+00:00

When add the 'a *:* rwm' entry to devcgroup A's whitelist, at first A's exceptions will be cleaned and A's behavior is changed to DEVCG_DEFAULT_ALLOW. Then parent's exceptions will be copyed to A's whitelist. If copy failure occurs, just return leaving A to grant permissions to all devices. And A may grant more permissions than parent. Backup A's whitelist and recover original exceptions after copy failure. Cc: stable@vger.kernel.org Fixes: 4cef7299b478 ("device_cgroup: add proper checking when changing default behavior") Signed-off-by: Wang Weiyang Reviewed-by: Aristeu Rozanski Signed-off-by: Paul Moore

bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean

2022-01-19T20:51:30+00:00

Right now BPF_PROG_RUN_ARRAY and related macros return 1 or 0 for whether the prog array allows or rejects whatever is being hooked. The caller of these macros then return -EPERM or continue processing based on thw macro's return value. Unforunately this is inflexible, since -EPERM is the only err that can be returned. This patch should be a no-op; it prepares for the next patch. The returning of the -EPERM is moved to inside the macros, so the outer functions are directly returning what the macros returned if they are non-zero. Signed-off-by: YiFei Zhu Reviewed-by: Stanislav Fomichev Link: https://lore.kernel.org/r/788abcdca55886d1f43274c918eaa9f792a9f33b.1639619851.git.zhuyifei@google.com Signed-off-by: Alexei Starovoitov

add missing bpf-cgroup.h includes

2021-12-16T22:57:09+00:00

We're about to break the cgroup-defs.h -> bpf-cgroup.h dependency, make sure those who actually need more than the definition of struct cgroup_bpf include bpf-cgroup.h explicitly. Signed-off-by: Jakub Kicinski Signed-off-by: Alexei Starovoitov Acked-by: Tejun Heo Link: https://lore.kernel.org/bpf/20211216025538.1649516-3-kuba@kernel.org

device_cgroup: Fix RCU list debugging warning

2020-08-20T18:25:03+00:00

exceptions may be traversed using list_for_each_entry_rcu() outside of an RCU read side critical section BUT under the protection of decgroup_mutex. Hence add the corresponding lockdep expression to fix the following false-positive warning: [ 2.304417] ============================= [ 2.304418] WARNING: suspicious RCU usage [ 2.304420] 5.5.4-stable #17 Tainted: G E [ 2.304422] ----------------------------- [ 2.304424] security/device_cgroup.c:355 RCU-list traversed in non-reader section!! Signed-off-by: Amol Grover Signed-off-by: James Morris

device_cgroup: Cleanup cgroup eBPF device filter code

2020-04-13T18:41:54+00:00

Original cgroup v2 eBPF code for filtering device access made it possible to compile with CONFIG_CGROUP_DEVICE=n and still use the eBPF filtering. Change commit 4b7d4d453fc4 ("device_cgroup: Export devcgroup_check_permission") reverted this, making it required to set it to y. Since the device filtering (and all the docs) for cgroup v2 is no longer a "device controller" like it was in v1, someone might compile their kernel with CONFIG_CGROUP_DEVICE=n. Then (for linux 5.5+) the eBPF filter will not be invoked, and all processes will be allowed access to all devices, no matter what the eBPF filter says. Signed-off-by: Odin Ugedal Acked-by: Roman Gushchin Signed-off-by: Tejun Heo

device_cgroup: Export devcgroup_check_permission

2019-10-07T20:11:38+00:00

For AMD compute (amdkfd) driver. All AMD compute devices are exported via single device node /dev/kfd. As a result devices cannot be controlled individually using device cgroup. AMD compute devices will rely on its graphics counterpart that exposes /dev/dri/renderN node for each device. For each task (based on its cgroup), KFD driver will check if /dev/dri/renderN node is accessible before exposing it. Signed-off-by: Harish Kasiviswanathan Acked-by: Tejun Heo Acked-by: Felix Kuehling Reviewed-by: Roman Gushchin Signed-off-by: Alex Deucher

docs: cgroup-v1: add it to the admin-guide book

2019-07-15T14:03:02+00:00

Those files belong to the admin guide, so add them. Signed-off-by: Mauro Carvalho Chehab