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  * ::
107
108	void init_watch_list(struct watch_list *wlist,
109			     void (*release_watch)(struct watch *wlist));
110
111    Initialise a watch list.  If ``release_watch`` is not NULL, then this
112    indicates a function that should be called when the watch_list object is
113    destroyed to discard any references the watch list holds on the watched
114    object.
115
116  * ``void remove_watch_list(struct watch_list *wlist);``
117
118    This removes all of the watches subscribed to a watch_list and frees them
119    and then destroys the watch_list object itself.
120
121
122Watch Queue (Notification Output) API
123=====================================
124
125A "watch queue" is the buffer allocated by an application that notification
126records will be written into.  The workings of this are hidden entirely inside
127of the pipe device driver, but it is necessary to gain a reference to it to set
128a watch.  These can be managed with:
129
130  * ``struct watch_queue *get_watch_queue(int fd);``
131
132    Since watch queues are indicated to the kernel by the fd of the pipe that
133    implements the buffer, userspace must hand that fd through a system call.
134    This can be used to look up an opaque pointer to the watch queue from the
135    system call.
136
137  * ``void put_watch_queue(struct watch_queue *wqueue);``
138
139    This discards the reference obtained from ``get_watch_queue()``.
140
141
142Watch Subscription API
143======================
144
145A "watch" is a subscription on a watch list, indicating the watch queue, and
146thus the buffer, into which notification records should be written.  The watch
147queue object may also carry filtering rules for that object, as set by
148userspace.  Some parts of the watch struct can be set by the driver::
149
150	struct watch {
151		union {
152			u32		info_id;	/* ID to be OR'd in to info field */
153			...
154		};
155		void			*private;	/* Private data for the watched object */
156		u64			id;		/* Internal identifier */
157		...
158	};
159
160The ``info_id`` value should be an 8-bit number obtained from userspace and
161shifted by WATCH_INFO_ID__SHIFT.  This is OR'd into the WATCH_INFO_ID field of
162struct watch_notification::info when and if the notification is written into
163the associated watch queue buffer.
164
165The ``private`` field is the driver's data associated with the watch_list and
166is cleaned up by the ``watch_list::release_watch()`` method.
167
168The ``id`` field is the source's ID.  Notifications that are posted with a
169different ID are ignored.
170
171The following functions are provided to manage watches:
172
173  * ``void init_watch(struct watch *watch, struct watch_queue *wqueue);``
174
175    Initialise a watch object, setting its pointer to the watch queue, using
176    appropriate barriering to avoid lockdep complaints.
177
178  * ``int add_watch_to_object(struct watch *watch, struct watch_list *wlist);``
179
180    Subscribe a watch to a watch list (notification source).  The
181    driver-settable fields in the watch struct must have been set before this
182    is called.
183
184  * ::
185
186	int remove_watch_from_object(struct watch_list *wlist,
187				     struct watch_queue *wqueue,
188				     u64 id, false);
189
190    Remove a watch from a watch list, where the watch must match the specified
191    watch queue (``wqueue``) and object identifier (``id``).  A notification
192    (``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue to
193    indicate that the watch got removed.
194
195  * ``int remove_watch_from_object(struct watch_list *wlist, NULL, 0, true);``
196
197    Remove all the watches from a watch list.  It is expected that this will be
198    called preparatory to destruction and that the watch list will be
199    inaccessible to new watches by this point.  A notification
200    (``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue of each
201    subscribed watch to indicate that the watch got removed.
202
203
204Notification Posting API
205========================
206
207To post a notification to watch list so that the subscribed watches can see it,
208the following function should be used::
209
210	void post_watch_notification(struct watch_list *wlist,
211				     struct watch_notification *n,
212				     const struct cred *cred,
213				     u64 id);
214
215The notification should be preformatted and a pointer to the header (``n``)
216should be passed in.  The notification may be larger than this and the size in
217units of buffer slots is noted in ``n->info & WATCH_INFO_LENGTH``.
218
219The ``cred`` struct indicates the credentials of the source (subject) and is
220passed to the LSMs, such as SELinux, to allow or suppress the recording of the
221note in each individual queue according to the credentials of that queue
222(object).
223
224The ``id`` is the ID of the source object (such as the serial number on a key).
225Only watches that have the same ID set in them will see this notification.
226
227
228Watch Sources
229=============
230
231Any particular buffer can be fed from multiple sources.  Sources include:
232
233  * WATCH_TYPE_KEY_NOTIFY
234
235    Notifications of this type indicate changes to keys and keyrings, including
236    the changes of keyring contents or the attributes of keys.
237
238    See Documentation/security/keys/core.rst for more information.
239
240
241Event Filtering
242===============
243
244Once a watch queue has been created, a set of filters can be applied to limit
245the events that are received using::
246
247	struct watch_notification_filter filter = {
248		...
249	};
250	ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter)
251
252The filter description is a variable of type::
253
254	struct watch_notification_filter {
255		__u32	nr_filters;
256		__u32	__reserved;
257		struct watch_notification_type_filter filters[];
258	};
259
260Where "nr_filters" is the number of filters in filters[] and "__reserved"
261should be 0.  The "filters" array has elements of the following type::
262
263	struct watch_notification_type_filter {
264		__u32	type;
265		__u32	info_filter;
266		__u32	info_mask;
267		__u32	subtype_filter[8];
268	};
269
270Where:
271
272  * ``type`` is the event type to filter for and should be something like
273    "WATCH_TYPE_KEY_NOTIFY"
274
275  * ``info_filter`` and ``info_mask`` act as a filter on the info field of the
276    notification record.  The notification is only written into the buffer if::
277
278	(watch.info & info_mask) == info_filter
279
280    This could be used, for example, to ignore events that are not exactly on
281    the watched point in a mount tree.
282
283  * ``subtype_filter`` is a bitmask indicating the subtypes that are of
284    interest.  Bit 0 of subtype_filter[0] corresponds to subtype 0, bit 1 to
285    subtype 1, and so on.
286
287If the argument to the ioctl() is NULL, then the filters will be removed and
288all events from the watched sources will come through.
289
290
291Userspace Code Example
292======================
293
294A buffer is created with something like the following::
295
296	pipe2(fds, O_TMPFILE);
297	ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
298
299It can then be set to receive keyring change notifications::
300
301	keyctl(KEYCTL_WATCH_KEY, KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
302
303The notifications can then be consumed by something like the following::
304
305	static void consumer(int rfd, struct watch_queue_buffer *buf)
306	{
307		unsigned char buffer[128];
308		ssize_t buf_len;
309
310		while (buf_len = read(rfd, buffer, sizeof(buffer)),
311		       buf_len > 0
312		       ) {
313			void *p = buffer;
314			void *end = buffer + buf_len;
315			while (p < end) {
316				union {
317					struct watch_notification n;
318					unsigned char buf1[128];
319				} n;
320				size_t largest, len;
321
322				largest = end - p;
323				if (largest > 128)
324					largest = 128;
325				memcpy(&n, p, largest);
326
327				len = (n->info & WATCH_INFO_LENGTH) >>
328					WATCH_INFO_LENGTH__SHIFT;
329				if (len == 0 || len > largest)
330					return;
331
332				switch (n.n.type) {
333				case WATCH_TYPE_META:
334					got_meta(&n.n);
335				case WATCH_TYPE_KEY_NOTIFY:
336					saw_key_change(&n.n);
337					break;
338				}
339
340				p += len;
341			}
342		}
343	}
344