From: Daniel Borkmann <[email protected]>
commit 71330842ff93ae67a066c1fa68d75672527312fa upstream.
Rename LOCKDOWN_BPF_READ into LOCKDOWN_BPF_READ_KERNEL so we have naming
more consistent with a LOCKDOWN_BPF_WRITE_USER option that we are adding.
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/security.h | 2 +-
kernel/bpf/helpers.c | 4 ++--
kernel/trace/bpf_trace.c | 8 ++++----
security/security.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -123,7 +123,7 @@ enum lockdown_reason {
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_KCORE,
LOCKDOWN_KPROBES,
- LOCKDOWN_BPF_READ,
+ LOCKDOWN_BPF_READ_KERNEL,
LOCKDOWN_PERF,
LOCKDOWN_TRACEFS,
LOCKDOWN_XMON_RW,
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -729,12 +729,12 @@ bpf_base_func_proto(enum bpf_func_id fun
case BPF_FUNC_probe_read_user:
return &bpf_probe_read_user_proto;
case BPF_FUNC_probe_read_kernel:
- return security_locked_down(LOCKDOWN_BPF_READ) < 0 ?
+ return security_locked_down(LOCKDOWN_BPF_READ_KERNEL) < 0 ?
NULL : &bpf_probe_read_kernel_proto;
case BPF_FUNC_probe_read_user_str:
return &bpf_probe_read_user_str_proto;
case BPF_FUNC_probe_read_kernel_str:
- return security_locked_down(LOCKDOWN_BPF_READ) < 0 ?
+ return security_locked_down(LOCKDOWN_BPF_READ_KERNEL) < 0 ?
NULL : &bpf_probe_read_kernel_str_proto;
case BPF_FUNC_snprintf_btf:
return &bpf_snprintf_btf_proto;
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1281,19 +1281,19 @@ bpf_tracing_func_proto(enum bpf_func_id
case BPF_FUNC_probe_read_user:
return &bpf_probe_read_user_proto;
case BPF_FUNC_probe_read_kernel:
- return security_locked_down(LOCKDOWN_BPF_READ) < 0 ?
+ return security_locked_down(LOCKDOWN_BPF_READ_KERNEL) < 0 ?
NULL : &bpf_probe_read_kernel_proto;
case BPF_FUNC_probe_read_user_str:
return &bpf_probe_read_user_str_proto;
case BPF_FUNC_probe_read_kernel_str:
- return security_locked_down(LOCKDOWN_BPF_READ) < 0 ?
+ return security_locked_down(LOCKDOWN_BPF_READ_KERNEL) < 0 ?
NULL : &bpf_probe_read_kernel_str_proto;
#ifdef CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
case BPF_FUNC_probe_read:
- return security_locked_down(LOCKDOWN_BPF_READ) < 0 ?
+ return security_locked_down(LOCKDOWN_BPF_READ_KERNEL) < 0 ?
NULL : &bpf_probe_read_compat_proto;
case BPF_FUNC_probe_read_str:
- return security_locked_down(LOCKDOWN_BPF_READ) < 0 ?
+ return security_locked_down(LOCKDOWN_BPF_READ_KERNEL) < 0 ?
NULL : &bpf_probe_read_compat_str_proto;
#endif
#ifdef CONFIG_CGROUPS
--- a/security/security.c
+++ b/security/security.c
@@ -61,7 +61,7 @@ const char *const lockdown_reasons[LOCKD
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_KCORE] = "/proc/kcore access",
[LOCKDOWN_KPROBES] = "use of kprobes",
- [LOCKDOWN_BPF_READ] = "use of bpf to read kernel RAM",
+ [LOCKDOWN_BPF_READ_KERNEL] = "use of bpf to read kernel RAM",
[LOCKDOWN_PERF] = "unsafe use of perf",
[LOCKDOWN_TRACEFS] = "use of tracefs",
[LOCKDOWN_XMON_RW] = "xmon read and write access",
Hi!
> From: Daniel Borkmann <[email protected]>
>
> commit 71330842ff93ae67a066c1fa68d75672527312fa upstream.
>
> Rename LOCKDOWN_BPF_READ into LOCKDOWN_BPF_READ_KERNEL so we have naming
> more consistent with a LOCKDOWN_BPF_WRITE_USER option that we are
> adding.
As far as I can tell, next bpf patch does not depend on this one and
we don't need it in 5.10. (Likely same situation with 5.13).
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
Hi Pavel,
On 8/13/21 9:55 PM, Pavel Machek wrote:
>> From: Daniel Borkmann <[email protected]>
>>
>> commit 71330842ff93ae67a066c1fa68d75672527312fa upstream.
>>
>> Rename LOCKDOWN_BPF_READ into LOCKDOWN_BPF_READ_KERNEL so we have naming
>> more consistent with a LOCKDOWN_BPF_WRITE_USER option that we are
>> adding.
>
> As far as I can tell, next bpf patch does not depend on this one and
> we don't need it in 5.10. (Likely same situation with 5.13).
Yeah, it's nice to have for consistency given also small as well, but
also fully okay to drop it as there shouldn't be any conflict.
Thanks,
Daniel
On Fri, Aug 13, 2021 at 11:57:58PM +0200, Daniel Borkmann wrote:
> Hi Pavel,
>
> On 8/13/21 9:55 PM, Pavel Machek wrote:
> > > From: Daniel Borkmann <[email protected]>
> > >
> > > commit 71330842ff93ae67a066c1fa68d75672527312fa upstream.
> > >
> > > Rename LOCKDOWN_BPF_READ into LOCKDOWN_BPF_READ_KERNEL so we have naming
> > > more consistent with a LOCKDOWN_BPF_WRITE_USER option that we are
> > > adding.
> >
> > As far as I can tell, next bpf patch does not depend on this one and
> > we don't need it in 5.10. (Likely same situation with 5.13).
>
> Yeah, it's nice to have for consistency given also small as well, but
> also fully okay to drop it as there shouldn't be any conflict.
>
Ok, now dropped, thanks.
greg k-h