1==============================
  2General notification mechanism
  3==============================
  4
  5The general notification mechanism is built on top of the standard pipe driver
  6whereby it effectively splices notification messages from the kernel into pipes
  7opened by userspace.  This can be used in conjunction with::
  8
  9  * Key/keyring notifications
 10
 11
 12The notifications buffers can be enabled by:
 13
 14	"General setup"/"General notification queue"
 15	(CONFIG_WATCH_QUEUE)
 16
 17This document has the following sections:
 18
 19.. contents:: :local:
 20
 21
 22Overview
 23========
 24
 25This facility appears as a pipe that is opened in a special mode.  The pipe's
 26internal ring buffer is used to hold messages that are generated by the kernel.
 27These messages are then read out by read().  Splice and similar are disabled on
 28such pipes due to them wanting to, under some circumstances, revert their
 29additions to the ring - which might end up interleaved with notification
 30messages.
 31
 32The owner of the pipe has to tell the kernel which sources it would like to
 33watch through that pipe.  Only sources that have been connected to a pipe will
 34insert messages into it.  Note that a source may be bound to multiple pipes and
 35insert messages into all of them simultaneously.
 36
 37Filters may also be emplaced on a pipe so that certain source types and
 38subevents can be ignored if they're not of interest.
 39
 40A message will be discarded if there isn't a slot available in the ring or if
 41no preallocated message buffer is available.  In both of these cases, read()
 42will insert a WATCH_META_LOSS_NOTIFICATION message into the output buffer after
 43the last message currently in the buffer has been read.
 44
 45Note that when producing a notification, the kernel does not wait for the
 46consumers to collect it, but rather just continues on.  This means that
 47notifications can be generated whilst spinlocks are held and also protects the
 48kernel from being held up indefinitely by a userspace malfunction.
 49
 50
 51Message Structure
 52=================
 53
 54Notification messages begin with a short header::
 55
 56	struct watch_notification {
 57		__u32	type:24;
 58		__u32	subtype:8;
 59		__u32	info;
 60	};
 61
 62"type" indicates the source of the notification record and "subtype" indicates
 63the type of record from that source (see the Watch Sources section below).  The
 64type may also be "WATCH_TYPE_META".  This is a special record type generated
 65internally by the watch queue itself.  There are two subtypes:
 66
 67  * WATCH_META_REMOVAL_NOTIFICATION
 68  * WATCH_META_LOSS_NOTIFICATION
 69
 70The first indicates that an object on which a watch was installed was removed
 71or destroyed and the second indicates that some messages have been lost.
 72
 73"info" indicates a bunch of things, including:
 74
 75  * The length of the message in bytes, including the header (mask with
 76    WATCH_INFO_LENGTH and shift by WATCH_INFO_LENGTH__SHIFT).  This indicates
 77    the size of the record, which may be between 8 and 127 bytes.
 78
 79  * The watch ID (mask with WATCH_INFO_ID and shift by WATCH_INFO_ID__SHIFT).
 80    This indicates that caller's ID of the watch, which may be between 0
 81    and 255.  Multiple watches may share a queue, and this provides a means to
 82    distinguish them.
 83
 84  * A type-specific field (WATCH_INFO_TYPE_INFO).  This is set by the
 85    notification producer to indicate some meaning specific to the type and
 86    subtype.
 87
 88Everything in info apart from the length can be used for filtering.
 89
 90The header can be followed by supplementary information.  The format of this is
 91at the discretion is defined by the type and subtype.
 92
 93
 94Watch List (Notification Source) API
 95====================================
 96
 97A "watch list" is a list of watchers that are subscribed to a source of
 98notifications.  A list may be attached to an object (say a key or a superblock)
 99or may be global (say for device events).  From a userspace perspective, a
100non-global watch list is typically referred to by reference to the object it
101belongs to (such as using KEYCTL_NOTIFY and giving it a key serial number to
102watch that specific key).
103
104To manage a watch list, the following functions are provided:
105
106  * ``void init_watch_list(struct watch_list *wlist,
107			   void (*release_watch)(struct watch *wlist));``
108
109    Initialise a watch list.  If ``release_watch`` is not NULL, then this
110    indicates a function that should be called when the watch_list object is
111    destroyed to discard any references the watch list holds on the watched
112    object.
113
114  * ``void remove_watch_list(struct watch_list *wlist);``
115
116    This removes all of the watches subscribed to a watch_list and frees them
117    and then destroys the watch_list object itself.
118
119
120Watch Queue (Notification Output) API
121=====================================
122
123A "watch queue" is the buffer allocated by an application that notification
124records will be written into.  The workings of this are hidden entirely inside
125of the pipe device driver, but it is necessary to gain a reference to it to set
126a watch.  These can be managed with:
127
128  * ``struct watch_queue *get_watch_queue(int fd);``
129
130    Since watch queues are indicated to the kernel by the fd of the pipe that
131    implements the buffer, userspace must hand that fd through a system call.
132    This can be used to look up an opaque pointer to the watch queue from the
133    system call.
134
135  * ``void put_watch_queue(struct watch_queue *wqueue);``
136
137    This discards the reference obtained from ``get_watch_queue()``.
138
139
140Watch Subscription API
141======================
142
143A "watch" is a subscription on a watch list, indicating the watch queue, and
144thus the buffer, into which notification records should be written.  The watch
145queue object may also carry filtering rules for that object, as set by
146userspace.  Some parts of the watch struct can be set by the driver::
147
148	struct watch {
149		union {
150			u32		info_id;	/* ID to be OR'd in to info field */
151			...
152		};
153		void			*private;	/* Private data for the watched object */
154		u64			id;		/* Internal identifier */
155		...
156	};
157
158The ``info_id`` value should be an 8-bit number obtained from userspace and
159shifted by WATCH_INFO_ID__SHIFT.  This is OR'd into the WATCH_INFO_ID field of
160struct watch_notification::info when and if the notification is written into
161the associated watch queue buffer.
162
163The ``private`` field is the driver's data associated with the watch_list and
164is cleaned up by the ``watch_list::release_watch()`` method.
165
166The ``id`` field is the source's ID.  Notifications that are posted with a
167different ID are ignored.
168
169The following functions are provided to manage watches:
170
171  * ``void init_watch(struct watch *watch, struct watch_queue *wqueue);``
172
173    Initialise a watch object, setting its pointer to the watch queue, using
174    appropriate barriering to avoid lockdep complaints.
175
176  * ``int add_watch_to_object(struct watch *watch, struct watch_list *wlist);``
177
178    Subscribe a watch to a watch list (notification source).  The
179    driver-settable fields in the watch struct must have been set before this
180    is called.
181
182  * ``int remove_watch_from_object(struct watch_list *wlist,
183				   struct watch_queue *wqueue,
184				   u64 id, false);``
185
186    Remove a watch from a watch list, where the watch must match the specified
187    watch queue (``wqueue``) and object identifier (``id``).  A notification
188    (``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue to
189    indicate that the watch got removed.
190
191  * ``int remove_watch_from_object(struct watch_list *wlist, NULL, 0, true);``
192
193    Remove all the watches from a watch list.  It is expected that this will be
194    called preparatory to destruction and that the watch list will be
195    inaccessible to new watches by this point.  A notification
196    (``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue of each
197    subscribed watch to indicate that the watch got removed.
198
199
200Notification Posting API
201========================
202
203To post a notification to watch list so that the subscribed watches can see it,
204the following function should be used::
205
206	void post_watch_notification(struct watch_list *wlist,
207				     struct watch_notification *n,
208				     const struct cred *cred,
209				     u64 id);
210
211The notification should be preformatted and a pointer to the header (``n``)
212should be passed in.  The notification may be larger than this and the size in
213units of buffer slots is noted in ``n->info & WATCH_INFO_LENGTH``.
214
215The ``cred`` struct indicates the credentials of the source (subject) and is
216passed to the LSMs, such as SELinux, to allow or suppress the recording of the
217note in each individual queue according to the credentials of that queue
218(object).
219
220The ``id`` is the ID of the source object (such as the serial number on a key).
221Only watches that have the same ID set in them will see this notification.
222
223
224Watch Sources
225=============
226
227Any particular buffer can be fed from multiple sources.  Sources include:
228
229  * WATCH_TYPE_KEY_NOTIFY
230
231    Notifications of this type indicate changes to keys and keyrings, including
232    the changes of keyring contents or the attributes of keys.
233
234    See Documentation/security/keys/core.rst for more information.
235
236
237Event Filtering
238===============
239
240Once a watch queue has been created, a set of filters can be applied to limit
241the events that are received using::
242
243	struct watch_notification_filter filter = {
244		...
245	};
246	ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter)
247
248The filter description is a variable of type::
249
250	struct watch_notification_filter {
251		__u32	nr_filters;
252		__u32	__reserved;
253		struct watch_notification_type_filter filters[];
254	};
255
256Where "nr_filters" is the number of filters in filters[] and "__reserved"
257should be 0.  The "filters" array has elements of the following type::
258
259	struct watch_notification_type_filter {
260		__u32	type;
261		__u32	info_filter;
262		__u32	info_mask;
263		__u32	subtype_filter[8];
264	};
265
266Where:
267
268  * ``type`` is the event type to filter for and should be something like
269    "WATCH_TYPE_KEY_NOTIFY"
270
271  * ``info_filter`` and ``info_mask`` act as a filter on the info field of the
272    notification record.  The notification is only written into the buffer if::
273
274	(watch.info & info_mask) == info_filter
275
276    This could be used, for example, to ignore events that are not exactly on
277    the watched point in a mount tree.
278
279  * ``subtype_filter`` is a bitmask indicating the subtypes that are of
280    interest.  Bit 0 of subtype_filter[0] corresponds to subtype 0, bit 1 to
281    subtype 1, and so on.
282
283If the argument to the ioctl() is NULL, then the filters will be removed and
284all events from the watched sources will come through.
285
286
287Userspace Code Example
288======================
289
290A buffer is created with something like the following::
291
292	pipe2(fds, O_TMPFILE);
293	ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
294
295It can then be set to receive keyring change notifications::
296
297	keyctl(KEYCTL_WATCH_KEY, KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
298
299The notifications can then be consumed by something like the following::
300
301	static void consumer(int rfd, struct watch_queue_buffer *buf)
302	{
303		unsigned char buffer[128];
304		ssize_t buf_len;
305
306		while (buf_len = read(rfd, buffer, sizeof(buffer)),
307		       buf_len > 0
308		       ) {
309			void *p = buffer;
310			void *end = buffer + buf_len;
311			while (p < end) {
312				union {
313					struct watch_notification n;
314					unsigned char buf1[128];
315				} n;
316				size_t largest, len;
317
318				largest = end - p;
319				if (largest > 128)
320					largest = 128;
321				memcpy(&n, p, largest);
322
323				len = (n->info & WATCH_INFO_LENGTH) >>
324					WATCH_INFO_LENGTH__SHIFT;
325				if (len == 0 || len > largest)
326					return;
327
328				switch (n.n.type) {
329				case WATCH_TYPE_META:
330					got_meta(&n.n);
331				case WATCH_TYPE_KEY_NOTIFY:
332					saw_key_change(&n.n);
333					break;
334				}
335
336				p += len;
337			}
338		}
339	}