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