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 40C13C33CA2 for ; Thu, 9 Jan 2020 17:59:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 151F22067D for ; Thu, 9 Jan 2020 17:59:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rqb+UPXB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732040AbgAIR7t (ORCPT ); Thu, 9 Jan 2020 12:59:49 -0500 Received: from mail-qk1-f196.google.com ([209.85.222.196]:36254 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728653AbgAIR7t (ORCPT ); Thu, 9 Jan 2020 12:59:49 -0500 Received: by mail-qk1-f196.google.com with SMTP id a203so6843009qkc.3; Thu, 09 Jan 2020 09:59:48 -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=8PkSoGPOiy4o4DnP2NNYtjoXFAX8iabjQVoKoqIqz5c=; b=rqb+UPXBmbt9LxqHLWb2wQkjHE/m7Zrgy3kUrI+o7jFU+3/M3dfv69Wzsn4wrpWbYy zUHOy33yGGfU4PoO72twqpbkFq0KLL4V7csznzM287joigW0bMkLi/aqxGH9yaCKvf/w upqYKRrZSPc6e3khXFG+KxdZHeQ5gfJEmKxQJ4WaF/1hWuZgICoVSZb8aazY6XvLPsPj Ddf0NIvw/o5BsSfIq+PRt0D/R+bTzwWR+3qbIcpRZfnrnj4Nb7tnoZ2LILoyKq0eTYBb ryN78osR5tE0T0Veu21LPfmqW4WPVaHWB1sWGdfwrgBdeQ5izrHS31ZUitUE2RijpKrC J/uw== 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=8PkSoGPOiy4o4DnP2NNYtjoXFAX8iabjQVoKoqIqz5c=; b=Rbrj0jn1pXT/xqwoyqKaPaYK9sQ8caaC7aijtdYpCC9UiU502+6embF5889syEWc2s cnZT/gBFfmPxidQwwfyf0FiPA8MKhqgyUDcMp/OORw2YEWp3BwWT9WcdSXHZOVuTOBTt St1LTGv1Y8jh59B3cEtnezTMeZA6Vz5GpVWMWVxdsypM6wcIY86jatXyVYStpVffmImd w+KA+PdpazdHLxprRcnVmEhvopdvw64hQ6uLlOfWRSdm3tQeLsqnGXUc/8ZQn8oo49V9 4eAS830B9ZZXjT9TnF5MGtYZVciIJDNxbLtP6cuOQ6GK8lAPHWg2yZynvsDh1K2sHnR6 T2jg== X-Gm-Message-State: APjAAAVTZ2MctjBDGQ59VSGwZoNrvCR3MiEUwHt7kcd9R/R7u/SDbASp gnvXdeqHFk33opqaQLWUTebYMmQaujhL/qUycDE= X-Google-Smtp-Source: APXvYqwRSsDCOH2S2S4sv60fEnTRBs947fHi9e247NVahrgq8MxV2kgGpalTMfJ5tYF7+Kk+WnPM2QEv6CIOPhJJzh8= X-Received: by 2002:ae9:e809:: with SMTP id a9mr10590771qkg.92.1578592787759; Thu, 09 Jan 2020 09:59:47 -0800 (PST) MIME-Version: 1.0 References: <20191220154208.15895-1-kpsingh@chromium.org> <20191220154208.15895-13-kpsingh@chromium.org> <20200104000955.GB23487@chromium.org> In-Reply-To: <20200104000955.GB23487@chromium.org> From: Andrii Nakryiko Date: Thu, 9 Jan 2020 09:59:35 -0800 Message-ID: Subject: Re: [PATCH bpf-next v1 12/13] bpf: lsm: Add selftests for BPF_PROG_TYPE_LSM To: KP Singh Cc: open list , bpf , linux-security-module@vger.kernel.org, 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: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Fri, Jan 3, 2020 at 4:09 PM KP Singh wrote: > > On 23-Dez 22:49, Andrii Nakryiko wrote: > > On Fri, Dec 20, 2019 at 7:42 AM KP Singh wrote: > > > > > > From: KP Singh > > > > > > * Load a BPF program that audits mprotect calls > > > * Attach the program to the "file_mprotect" LSM hook > > > * Verify if the program is actually loading by reading > > > securityfs > > > * Initialize the perf events buffer and poll for audit events > > > * Do an mprotect on some memory allocated on the heap > > > * Verify if the audit event was received > > > > > > Signed-off-by: KP Singh > > > --- > > > MAINTAINERS | 2 + > > > .../bpf/prog_tests/lsm_mprotect_audit.c | 129 ++++++++++++++++++ > > > .../selftests/bpf/progs/lsm_mprotect_audit.c | 58 ++++++++ > > > 3 files changed, 189 insertions(+) > > > create mode 100644 tools/testing/selftests/bpf/prog_tests/lsm_mprotect_audit.c > > > create mode 100644 tools/testing/selftests/bpf/progs/lsm_mprotect_audit.c > > > > > > > [...] > > > > > +/* > > > + * Define some of the structs used in the BPF program. > > > + * Only the field names and their sizes need to be the > > > + * same as the kernel type, the order is irrelevant. > > > + */ > > > +struct mm_struct { > > > + unsigned long start_brk, brk, start_stack; > > > +}; > > > + > > > +struct vm_area_struct { > > > + unsigned long start_brk, brk, start_stack; > > > + unsigned long vm_start, vm_end; > > > + struct mm_struct *vm_mm; > > > + unsigned long vm_flags; > > > +}; > > > + > > > +BPF_TRACE_3("lsm/file_mprotect", mprotect_audit, > > > + struct vm_area_struct *, vma, > > > + unsigned long, reqprot, unsigned long, prot) > > > +{ > > > + struct mprotect_audit_log audit_log = {}; > > > + int is_heap = 0; > > > + > > > + __builtin_preserve_access_index(({ > > > > you don't need __builtin_preserve_access_index, if you mark > > vm_area_struct and mm_struct with > > __attribute__((preserve_access_index) > > Cool, updated! > > > > > > + is_heap = (vma->vm_start >= vma->vm_mm->start_brk && > > > + vma->vm_end <= vma->vm_mm->brk); > > > + })); > > > + > > > + audit_log.magic = MPROTECT_AUDIT_MAGIC; > > > + audit_log.is_heap = is_heap; > > > + bpf_lsm_event_output(&perf_buf_map, BPF_F_CURRENT_CPU, &audit_log, > > > + sizeof(audit_log)); > > > > You test would be much simpler if you use global variables to pass > > data back to userspace, instead of using perf buffer. > > > > Also please see fentry_fexit.c test for example of using BPF skeleton > > to shorten and simpify userspace part of test. > > Thanks for the skeleton work! > > This makes using global variables easier and the tests are indeed much > simpler, I have updated it for the next revision. > > One follow up question regarding global variables, let's say I have > the following global variable defined in the BPF program: > > struct result_info { > __u32 count; > }; > > struct result_info result = { > .count = 0, > }; > > The defintion of result_info needs to be included before the .skel.h > as it's not automatically generated or maybe I am missing a > trick here? > > For now, I have defined this in a header which gets included both in > the program and the test. Yes, ideally all common types should be shared in a common header. My initial implementation actually supported dumping out all the types in a generated skeleton, but that was inconvenient in a lot of cases, so I dropped that. > > - KP > > > > > > + return 0; > > > +} > > > -- > > > 2.20.1 > > >