[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2732b46-d4d1-c811-dd6b-ad0ef280513f@fb.com>
Date: Sun, 15 Sep 2019 00:37:29 +0000
From: Yonghong Song <yhs@...com>
To: KP Singh <kpsingh@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>
CC: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
James Morris <jmorris@...ei.org>,
Kees Cook <keescook@...omium.org>,
Thomas Garnier <thgarnie@...omium.org>,
"Michael Halcrow" <mhalcrow@...gle.com>,
Paul Turner <pjt@...gle.com>,
Brendan Gregg <brendan.d.gregg@...il.com>,
Jann Horn <jannh@...gle.com>,
Matthew Garrett <mjg59@...gle.com>,
Christian Brauner <christian@...uner.io>,
Mickaël Salaün <mic@...ikod.net>,
Florent Revest <revest@...omium.org>,
Martin Lau <kafai@...com>, Song Liu <songliubraving@...com>,
"Serge E. Hallyn" <serge@...lyn.com>,
"Mauro Carvalho Chehab" <mchehab+samsung@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Stanislav Fomichev <sdf@...gle.com>,
"Quentin Monnet" <quentin.monnet@...ronome.com>,
Andrey Ignatov <rdna@...com>, "Joe Stringer" <joe@...d.net.nz>
Subject: Re: Re: [RFC v1 06/14] krsi: Implement eBPF operations, attachment
and execution
On 9/14/19 5:56 PM, Yonghong Song wrote:
>
>
> On 9/10/19 12:55 PM, KP Singh wrote:
>> From: KP Singh <kpsingh@...gle.com>
>>
>> A user space program can attach an eBPF program by:
>>
>> hook_fd = open("/sys/kernel/security/krsi/process_execution", O_RDWR)
>> prog_fd = bpf(BPF_PROG_LOAD, ...)
>> bpf(BPF_PROG_ATTACH, hook_fd, prog_fd)
>>
>> When such an attach call is received, the attachment logic looks up the
>> dentry and appends the program to the bpf_prog_array.
>>
>> The BPF programs are stored in a bpf_prog_array and writes to the array
>> are guarded by a mutex. The eBPF programs are executed as a part of the
>> LSM hook they are attached to. If any of the eBPF programs return
>> an error (-ENOPERM) the action represented by the hook is denied.
>>
>> Signed-off-by: KP Singh <kpsingh@...gle.com>
>> ---
>> include/linux/krsi.h | 18 ++++++
>> kernel/bpf/syscall.c | 3 +-
>> security/krsi/include/krsi_init.h | 51 +++++++++++++++
>> security/krsi/krsi.c | 13 +++-
>> security/krsi/krsi_fs.c | 28 ++++++++
>> security/krsi/ops.c | 102 ++++++++++++++++++++++++++++++
>> 6 files changed, 213 insertions(+), 2 deletions(-)
>> create mode 100644 include/linux/krsi.h
>>
[...]
>>
>> +static inline int krsi_run_progs(enum krsi_hook_type t, struct krsi_ctx *ctx)
>> +{
>> + struct bpf_prog_array_item *item;
>> + struct bpf_prog *prog;
>> + struct krsi_hook *h = &krsi_hooks_list[t];
>> + int ret, retval = 0;
>
> Reverse christmas tree style?
>
>> +
>> + preempt_disable();
>
> Do we need preempt_disable() here?
From the following patches, I see perf_event_output() helper
and per-cpu array usage. So, indeed preempt_disable() is needed.
>
>> + rcu_read_lock();
>> +
>> + item = rcu_dereference(h->progs)->items;
>> + while ((prog = READ_ONCE(item->prog))) {
>> + ret = BPF_PROG_RUN(prog, ctx);
>> + if (ret < 0) {
>> + retval = ret;
>> + goto out;
>> + }
>> + item++;
>> + }
>> +
>> +out:
>> + rcu_read_unlock();
>> + preempt_enable();
>> + return IS_ENABLED(CONFIG_SECURITY_KRSI_ENFORCE) ? retval : 0;
>> +}
>> +
[...]
Powered by blists - more mailing lists