From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79826C3F68F for ; Thu, 23 Jan 2020 18:00:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 527B420718 for ; Thu, 23 Jan 2020 18:00:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AyFF7cdv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729066AbgAWSAw (ORCPT ); Thu, 23 Jan 2020 13:00:52 -0500 Received: from mail-qk1-f193.google.com ([209.85.222.193]:44406 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727278AbgAWSAw (ORCPT ); Thu, 23 Jan 2020 13:00:52 -0500 Received: by mail-qk1-f193.google.com with SMTP id v195so4280050qkb.11; Thu, 23 Jan 2020 10:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TjajhBuUHgmsUmSOzJHuUV6Zb4Qt2oP329J3QSODkhs=; b=AyFF7cdv99soMyTaRXnu+Z5Db/pAg2xMOJRoJ+y/wzJosfTzilFHht/1w6KWm055qT LBDkFuCMDYC5+zm3ixghCDggrQogGF5D1O4YMLpHNH1/h39nA2v25cPesevzGFwqqnKv bu1SA7hpordVgK/c/xYIr6DQ21oebGyBqQBqnCZ+xr+H/AZHtg4KKiAzgubIUFGESl8f Ok6IGfoTFV+0jwTm5NKJrYb3APGEha2ctps9d0CiEB7dJbXK5Rl4/qwaN/KfuJJesAHO +JDmLXLHFCjA4FCFh0FIltvtPgsPP+VUoPzXd84hQk6nK1ksXlGOSbXSMu5Kxio5Mi2O fpTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TjajhBuUHgmsUmSOzJHuUV6Zb4Qt2oP329J3QSODkhs=; b=Ll/aIywT5t01dipImFSrdSepHlQblt8UvsVRta68PBKp5Z8VWVznkmP4wkcKXOkRI4 zrRN9J+cPJgCCM+EBOnIDthgduCCYrWHh+HEclVWpsSwxYl7sV3UrerH0HaasZqJBpaD 3U/fL4MrfknhogC5jEoUdmCJkEvtmUl7vpgKyUkFY+hK4R+3Yy15/A50Lul4eSgpMYok qBn5Q/lXEFVNLNWQFsx1HK+dtZ9ny4e6BZgqcg2xNwPk5rsSVO36nwwuB0q4eCOdqY95 Mno+EpUxtD8sgbVPh4nntubWSQ5SBRkTNNhdSpU1TYjqy5LDIglxSfUbHoLE/fSc2NAr FAwA== X-Gm-Message-State: APjAAAV2g6Mym+8c08WdDCDPoyoFxgPW0LpbqsqEKTvElojIyU9Znd/v +t+UTau6bPN/sFRekw9VqMaDwNGywKYHMRF5mbY= X-Google-Smtp-Source: APXvYqzTbm7nV2a/ShavuV2TKnmHRmJ7wzGMM3QJ7cfNiA3ZBb4lNlsX9/ki1ngSIWhs23JMSjqg4hOZfHIs3t8qzAI= X-Received: by 2002:a37:a685:: with SMTP id p127mr18070215qke.449.1579802450607; Thu, 23 Jan 2020 10:00:50 -0800 (PST) MIME-Version: 1.0 References: <20200123152440.28956-1-kpsingh@chromium.org> <20200123152440.28956-9-kpsingh@chromium.org> In-Reply-To: <20200123152440.28956-9-kpsingh@chromium.org> From: Andrii Nakryiko Date: Thu, 23 Jan 2020 10:00:39 -0800 Message-ID: Subject: Re: [PATCH bpf-next v3 08/10] tools/libbpf: Add support for BPF_PROG_TYPE_LSM To: KP Singh Cc: open list , bpf , linux-security-module@vger.kernel.org, Brendan Jackman , Florent Revest , Thomas Garnier , Alexei Starovoitov , Daniel Borkmann , James Morris , Kees Cook , Thomas Garnier , Michael Halcrow , Paul Turner , Brendan Gregg , Jann Horn , Matthew Garrett , Christian Brauner , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Florent Revest , Brendan Jackman , Martin KaFai Lau , Song Liu , Yonghong Song , "Serge E. Hallyn" , Mauro Carvalho Chehab , "David S. Miller" , Greg Kroah-Hartman , Nicolas Ferre , Stanislav Fomichev , Quentin Monnet , Andrey Ignatov , Joe Stringer Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 23, 2020 at 7:25 AM KP Singh wrote: > > From: KP Singh > > * Add functionality in libbpf to attach eBPF program to LSM hooks > * Lookup the index of the LSM hook in security_hook_heads and pass it in > attr->lsm_hook_idx > > Signed-off-by: KP Singh > Reviewed-by: Brendan Jackman > Reviewed-by: Florent Revest > Reviewed-by: Thomas Garnier > --- Looks good, but see few nits below. Acked-by: Andrii Nakryiko > tools/lib/bpf/bpf.c | 6 ++- > tools/lib/bpf/bpf.h | 1 + > tools/lib/bpf/libbpf.c | 104 +++++++++++++++++++++++++++++++++++++-- > tools/lib/bpf/libbpf.h | 4 ++ > tools/lib/bpf/libbpf.map | 3 ++ > 5 files changed, 114 insertions(+), 4 deletions(-) > [...] > @@ -5084,6 +5099,8 @@ __bpf_object__open(const char *path, const void *obj_buf, size_t obj_buf_sz, > if (prog->type != BPF_PROG_TYPE_UNSPEC) > continue; > > + > + why these extra lines? > err = libbpf_prog_type_by_name(prog->section_name, &prog_type, > &attach_type); > if (err == -ESRCH) > @@ -6160,6 +6177,7 @@ bool bpf_program__is_##NAME(const struct bpf_program *prog) \ > } \ > > BPF_PROG_TYPE_FNS(socket_filter, BPF_PROG_TYPE_SOCKET_FILTER); > +BPF_PROG_TYPE_FNS(lsm, BPF_PROG_TYPE_LSM); > BPF_PROG_TYPE_FNS(kprobe, BPF_PROG_TYPE_KPROBE); > BPF_PROG_TYPE_FNS(sched_cls, BPF_PROG_TYPE_SCHED_CLS); > BPF_PROG_TYPE_FNS(sched_act, BPF_PROG_TYPE_SCHED_ACT); > @@ -6226,6 +6244,8 @@ static struct bpf_link *attach_raw_tp(const struct bpf_sec_def *sec, > struct bpf_program *prog); > static struct bpf_link *attach_trace(const struct bpf_sec_def *sec, > struct bpf_program *prog); > +static struct bpf_link *attach_lsm(const struct bpf_sec_def *sec, > + struct bpf_program *prog); > > struct bpf_sec_def { > const char *sec; > @@ -6272,6 +6292,9 @@ static const struct bpf_sec_def section_defs[] = { > SEC_DEF("freplace/", EXT, > .is_attach_btf = true, > .attach_fn = attach_trace), > + SEC_DEF("lsm/", LSM, > + .expected_attach_type = BPF_LSM_MAC, curious, will there be non-MAC LSM programs? if yes, how they are going to be different and which prefix will we use then? > + .attach_fn = attach_lsm), > BPF_PROG_SEC("xdp", BPF_PROG_TYPE_XDP), > BPF_PROG_SEC("perf_event", BPF_PROG_TYPE_PERF_EVENT), > BPF_PROG_SEC("lwt_in", BPF_PROG_TYPE_LWT_IN), > @@ -6533,6 +6556,44 @@ static int bpf_object__collect_struct_ops_map_reloc(struct bpf_object *obj, > return -EINVAL; > } > > +static __s32 find_lsm_hook_idx(struct bpf_program *prog) nit: I'd stick to int for return result, we barely ever use __s32 in libbpf.c [...]