Overview¶

This facility appears as a pipe that is opened in a special mode. The pipe’sinternal ring buffer is used to hold messages that are generated by the kernel.These messages are then read out by read(). Splice and similar are disabled onsuch pipes due to them wanting to, under some circumstances, revert theiradditions to the ring - which might end up interleaved with notificationmessages.

The owner of the pipe has to tell the kernel which sources it would like towatch through that pipe. Only sources that have been connected to a pipe willinsert messages into it. Note that a source may be bound to multiple pipes andinsert messages into all of them simultaneously.

Filters may also be emplaced on a pipe so that certain source types andsubevents can be ignored if they’re not of interest.

A message will be discarded if there isn’t a slot available in the ring or ifno preallocated message buffer is available. In both of these cases, read()will insert a WATCH_META_LOSS_NOTIFICATION message into the output buffer afterthe last message currently in the buffer has been read.

Note that when producing a notification, the kernel does not wait for theconsumers to collect it, but rather just continues on. This means thatnotifications can be generated whilst spinlocks are held and also protects thekernel from being held up indefinitely by a userspace malfunction.

Message Structure¶

Notification messages begin with a short header:

struct watch_notification {        __u32   type:24;        __u32   subtype:8;        __u32   info;};

“type” indicates the source of the notification record and “subtype” indicatesthe type of record from that source (see the Watch Sources section below). Thetype may also be “WATCH_TYPE_META”. This is a special record type generatedinternally by the watch queue itself. There are two subtypes:

• WATCH_META_REMOVAL_NOTIFICATION

• WATCH_META_LOSS_NOTIFICATION

The first indicates that an object on which a watch was installed was removedor destroyed and the second indicates that some messages have been lost.

“info” indicates a bunch of things, including:

• The length of the message in bytes, including the header (mask withWATCH_INFO_LENGTH and shift by WATCH_INFO_LENGTH__SHIFT). This indicatesthe size of the record, which may be between 8 and 127 bytes.

• The watch ID (mask with WATCH_INFO_ID and shift by WATCH_INFO_ID__SHIFT).This indicates that caller’s ID of the watch, which may be between 0and 255. Multiple watches may share a queue, and this provides a means todistinguish them.

• A type-specific field (WATCH_INFO_TYPE_INFO). This is set by thenotification producer to indicate some meaning specific to the type andsubtype.

Everything in info apart from the length can be used for filtering.

The header can be followed by supplementary information. The format of this isat the discretion is defined by the type and subtype.

Watch List (Notification Source) API¶

A “watch list” is a list of watchers that are subscribed to a source ofnotifications. A list may be attached to an object (say a key or a superblock)or may be global (say for device events). From a userspace perspective, anon-global watch list is typically referred to by reference to the object itbelongs to (such as using KEYCTL_NOTIFY and giving it a key serial number towatch that specific key).

To manage a watch list, the following functions are provided:

• void init_watch_list(struct watch_list *wlist,                     void (*release_watch)(struct watch *wlist));

  Initialise a watch list. Ifrelease_watch is not NULL, then thisindicates a function that should be called when the watch_list object isdestroyed to discard any references the watch list holds on the watchedobject.

• voidremove_watch_list(structwatch_list*wlist);

  This removes all of the watches subscribed to a watch_list and frees themand then destroys the watch_list object itself.

Watch Queue (Notification Output) API¶

A “watch queue” is the buffer allocated by an application that notificationrecords will be written into. The workings of this are hidden entirely insideof the pipe device driver, but it is necessary to gain a reference to it to seta watch. These can be managed with:

• structwatch_queue*get_watch_queue(intfd);

  Since watch queues are indicated to the kernel by the fd of the pipe thatimplements the buffer, userspace must hand that fd through a system call.This can be used to look up an opaque pointer to the watch queue from thesystem call.

• voidput_watch_queue(structwatch_queue*wqueue);

  This discards the reference obtained fromget_watch_queue().

Watch Subscription API¶

A “watch” is a subscription on a watch list, indicating the watch queue, andthus the buffer, into which notification records should be written. The watchqueue object may also carry filtering rules for that object, as set byuserspace. Some parts of the watchstructcan be set by the driver:

struct watch {        union {                u32             info_id;        /* ID to be OR'd in to info field */                ...        };        void                    *private;       /* Private data for the watched object */        u64                     id;             /* Internal identifier */        ...};

Theinfo_id value should be an 8-bit number obtained from userspace andshifted by WATCH_INFO_ID__SHIFT. This is OR’d into the WATCH_INFO_ID field ofstructwatch_notification::info when and if the notification is written intothe associated watch queue buffer.

Theprivate field is the driver’s data associated with the watch_list andis cleaned up by thewatch_list::release_watch() method.

Theid field is the source’s ID. Notifications that are posted with adifferent ID are ignored.

The following functions are provided to manage watches:

• voidinit_watch(structwatch*watch,structwatch_queue*wqueue);

  Initialise a watch object, setting its pointer to the watch queue, usingappropriate barriering to avoid lockdep complaints.

• intadd_watch_to_object(structwatch*watch,structwatch_list*wlist);

  Subscribe a watch to a watch list (notification source). Thedriver-settable fields in the watchstructmust have been set before thisis called.

• int remove_watch_from_object(struct watch_list *wlist,                             struct watch_queue *wqueue,                             u64 id, false);

  Remove a watch from a watch list, where the watch must match the specifiedwatch queue (wqueue) and object identifier (id). A notification(WATCH_META_REMOVAL_NOTIFICATION) is sent to the watch queue toindicate that the watch got removed.

• intremove_watch_from_object(structwatch_list*wlist,NULL,0,true);

  Remove all the watches from a watch list. It is expected that this will becalled preparatory to destruction and that the watch list will beinaccessible to new watches by this point. A notification(WATCH_META_REMOVAL_NOTIFICATION) is sent to the watch queue of eachsubscribed watch to indicate that the watch got removed.

Notification Posting API¶

To post a notification to watch list so that the subscribed watches can see it,the following function should be used:

void post_watch_notification(struct watch_list *wlist,                             struct watch_notification *n,                             const struct cred *cred,                             u64 id);

The notification should be preformatted and a pointer to the header (n)should be passed in. The notification may be larger than this and the size inunits of buffer slots is noted inn->info&WATCH_INFO_LENGTH.

Thecredstructindicates the credentials of the source (subject) and ispassed to the LSMs, such as SELinux, to allow or suppress the recording of thenote in each individual queue according to the credentials of that queue(object).

Theid is the ID of the source object (such as the serial number on a key).Only watches that have the same ID set in them will see this notification.

Watch Sources¶

Any particular buffer can be fed from multiple sources. Sources include:

• WATCH_TYPE_KEY_NOTIFY

  Notifications of this type indicate changes to keys and keyrings, includingthe changes of keyring contents or the attributes of keys.

  SeeKernel Key Retention Service for more information.

Event Filtering¶

Once a watch queue has been created, a set of filters can be applied to limitthe events that are received using:

struct watch_notification_filter filter = {        ...};ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter)

The filter description is a variable of type:

struct watch_notification_filter {        __u32   nr_filters;        __u32   __reserved;        struct watch_notification_type_filter filters[];};

Where “nr_filters” is the number of filters in filters[] and “__reserved”should be 0. The “filters” array has elements of the following type:

struct watch_notification_type_filter {        __u32   type;        __u32   info_filter;        __u32   info_mask;        __u32   subtype_filter[8];};

Where:

• type is the event type to filter for and should be something like“WATCH_TYPE_KEY_NOTIFY”

• info_filter andinfo_mask act as a filter on the info field of thenotification record. The notification is only written into the buffer if:

  (watch.info & info_mask) == info_filter

  This could be used, for example, to ignore events that are not exactly onthe watched point in a mount tree.

• subtype_filter is a bitmask indicating the subtypes that are ofinterest. Bit 0 of subtype_filter[0] corresponds to subtype 0, bit 1 tosubtype 1, and so on.

If the argument to the ioctl() is NULL, then the filters will be removed andall events from the watched sources will come through.

Userspace Code Example¶

A buffer is created with something like the following:

pipe2(fds, O_TMPFILE);ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);

It can then be set to receive keyring change notifications:

keyctl(KEYCTL_WATCH_KEY, KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);

The notifications can then be consumed by something like the following:

static void consumer(int rfd, struct watch_queue_buffer *buf){        unsigned char buffer[128];        ssize_t buf_len;        while (buf_len = read(rfd, buffer, sizeof(buffer)),               buf_len > 0               ) {                void *p = buffer;                void *end = buffer + buf_len;                while (p < end) {                        union {                                struct watch_notification n;                                unsigned char buf1[128];                        } n;                        size_t largest, len;                        largest = end - p;                        if (largest > 128)                                largest = 128;                        memcpy(&n, p, largest);                        len = (n->info & WATCH_INFO_LENGTH) >>                                WATCH_INFO_LENGTH__SHIFT;                        if (len == 0 || len > largest)                                return;                        switch (n.n.type) {                        case WATCH_TYPE_META:                                got_meta(&n.n);                        case WATCH_TYPE_KEY_NOTIFY:                                saw_key_change(&n.n);                                break;                        }                        p += len;                }        }}