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

Steven Rostedt
2026-04-06T15:00:17Z

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)
),

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.

Please fix the other events too.

-- 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)));
> +
>