From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Olsa Subject: Re: [RFC] bpf: Emit audit messages upon successful prog load and unload Date: Tue, 3 Dec 2019 09:46:26 +0100 Message-ID: <20191203084626.GB17468@krava> References: <20191128091633.29275-1-jolsa@kernel.org> <1915471.OmxkCOUsnW@x2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1915471.OmxkCOUsnW@x2> Content-Disposition: inline Sender: netdev-owner@vger.kernel.org To: Steve Grubb Cc: Paul Moore , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-audit@redhat.com, Andrii Nakryiko , Yonghong Song , Martin KaFai Lau , Jakub Kicinski , David Miller , Eric Paris , Jiri Benc List-Id: linux-audit@redhat.com On Mon, Dec 02, 2019 at 11:57:22PM -0500, Steve Grubb wrote: > On Monday, December 2, 2019 6:00:14 PM EST Paul Moore wrote: > > On Thu, Nov 28, 2019 at 4:16 AM Jiri Olsa wrote: > > > From: Daniel Borkmann > > >=20 > > > Allow for audit messages to be emitted upon BPF program load and > > > unload for having a timeline of events. The load itself is in > > > syscall context, so additional info about the process initiating > > > the BPF prog creation can be logged and later directly correlated > > > to the unload event. > > >=20 > > > The only info really needed from BPF side is the globally unique > > > prog ID where then audit user space tooling can query / dump all > > > info needed about the specific BPF program right upon load event > > > and enrich the record, thus these changes needed here can be kept > > > small and non-intrusive to the core. SNIP > > I think you would probably also want to check the results of > > audit_dummy_context() here as well, see all the various audit_XXX() > > functions in include/linux/audit.h as an example. You'll see a > > pattern similar to the following: > >=20 > > static inline void audit_foo(...) > > { > > if (unlikely(!audit_dummy_context())) > > __audit_foo(...) > > } > >=20 > > > + ab =3D audit_log_start(audit_context(), GFP_ATOMIC, AUDIT_BPF= ); > > > + if (unlikely(!ab)) > > > + return; > > > + audit_log_format(ab, "prog-id=3D%u op=3D%s", > > > + prog->aux->id, bpf_audit_str[op]); > >=20 > > Is it worth putting some checks in here to make sure that you don't > > blow past the end of the bpf_audit_str array? >=20 > I am wondering if prog-id was really the only information that was needed= ? Is=20 > it meaningful to other tools? Does that correlate to anything in /proc? I= n=20 > earlier discussion, it sounded like more information was needed to be sur= e=20 > what was happening. yep, as David mentions in the changelog the global ID is enough, because you can get all the other bpf program info based on that jirka