Re: [PATCH v2 12/17] landlock: Add tracepoints for ptrace and scope denials

Mickaël Salaün
2026-04-07T13:00:34Z

On Mon, Apr 06, 2026 at 11:01:23AM -0400, Steven Rostedt wrote:
> On Mon, 6 Apr 2026 16:37:10 +0200
> Mickaël Salaün <mic@digikod.net> wrote:
>
> > ---
> > include/trace/events/landlock.h | 135 ++++++++++++++++++++++++++++++++
> > security/landlock/log.c | 20 +++++
> > 2 files changed, 155 insertions(+)
> >
> > diff --git a/include/trace/events/landlock.h b/include/trace/events/landlock.h
> > index 1afab091efba..9f96c9897f44 100644
> > --- a/include/trace/events/landlock.h
> > +++ b/include/trace/events/landlock.h
> > @@ -11,6 +11,7 @@
> > #define _TRACE_LANDLOCK_H
> >
> > #include <linux/tracepoint.h>
> > +#include <net/af_unix.h>
> >
> > struct dentry;
> > struct landlock_domain;
> > @@ -19,6 +20,7 @@ struct landlock_rule;
> > struct landlock_ruleset;
> > struct path;
> > struct sock;
> > +struct task_struct;
> >
> > /**
> > * DOC: Landlock trace events
> > @@ -433,6 +435,139 @@ TRACE_EVENT(
> > __entry->log_new_exec, __entry->blockers, __entry->sport,
> > __entry->dport));
> >
> > +/**
> > + * landlock_deny_ptrace - ptrace access denied
> > + * @hierarchy: Hierarchy node that blocked the access (never NULL)
> > + * @same_exec: Whether the current task is the same executable that called
> > + * landlock_restrict_self() for the denying hierarchy node
> > + * @tracee: Target task (never NULL); eBPF can read pid, comm, cred,
> > + * namespaces, and cgroup via BTF
> > + */
> > +TRACE_EVENT(
> > + landlock_deny_ptrace,
> > +
> > + TP_PROTO(const struct landlock_hierarchy *hierarchy, bool same_exec,
> > + const struct task_struct *tracee),
> > +
> > + TP_ARGS(hierarchy, same_exec, tracee),
> > +
> > + TP_STRUCT__entry(
> > + __field(__u64, domain_id) __field(bool, same_exec)
> > + __field(u32, log_same_exec) __field(u32, log_new_exec)
> > + __field(pid_t, tracee_pid)
> > + __string(tracee_comm, tracee->comm)),
>
> Event formats are different than normal macro formatting. Please use the
> event formatting. The above is a defined structure that is being created
> for use. Keep it looking like a structure:
>
> TP_STRUCT__entry(
> __field( __u64, domain_id)
> __field( bool, same_exec)
> __field( u32, log_same_exec)
> __field( u32, log_new_exec)
> __field( pid_t, tracee_pid)
> __string( tracee_comm, tracee->comm)
> ),

I was using clang-format, but it doesn't make sense here, I'll fix it.

>
> See how the above resembles:
>
> struct entry {
> __u64 domain_id;
> bool same_exec;
> u32 log_same_exec;
> u32 log_new_exec;
> pid_t tracee_pid;
> string tracee_comm;
> };
>
> Because that's pretty much what the trace event TP_STRUCT__entry() is going
> to do with it. (The string will obviously be something else).
>
> This way it's also easy to spot wholes in the structure that is written
> into the ring buffer. The "same_exec" being a bool followed by two u32
> types, is going to cause a hole. Move it to between tracee_pid and
> tracee_comm.

Actually, the log_* field should be bool too. Anyway, is it a concern
that the ring buffer leaks (previous event) kernel memory or is the
concern mostly about avoiding wasted space and making easy to spot holes
even if it's OK?

>
> Please fix the other events too.

Sure. Thanks!

>
> -- Steve
>
>
> > +
> > + TP_fast_assign(__entry->domain_id = hierarchy->id;
> > + __entry->same_exec = same_exec;
> > + __entry->log_same_exec = hierarchy->log_same_exec;
> > + __entry->log_new_exec = hierarchy->log_new_exec;
> > + __entry->tracee_pid =
> > + task_tgid_nr((struct task_struct *)tracee);
> > + __assign_str(tracee_comm);),
> > +
> > + TP_printk(
> > + "domain=%llx same_exec=%d log_same_exec=%u log_new_exec=%u tracee_pid=%d comm=%s",
> > + __entry->domain_id, __entry->same_exec, __entry->log_same_exec,
> > + __entry->log_new_exec, __entry->tracee_pid,
> > + __print_untrusted_str(tracee_comm)));

Are you OK with this new helper?

> > +
> >
>