Documentation/watch_queue.rst

   1 ==============================
   2 General notification mechanism
   3 ==============================
   4
   5 The general notification mechanism is built on top of the standard pipe driver
   6 whereby it effectively splices notification messages from the kernel into pipes
   7 opened by userspace.  This can be used in conjunction with::
   8
   9   * Key/keyring notifications
  10
  11
  12 The notifications buffers can be enabled by:
  13
  14         "General setup"/"General notification queue"
  15         (CONFIG_WATCH_QUEUE)
  16
  17 This document has the following sections:
  18
  19 .. contents:: :local:
  20
  21
  22 Overview
  23 ========
  24
  25 This facility appears as a pipe that is opened in a special mode.  The pipe's
  26 internal ring buffer is used to hold messages that are generated by the kernel.
  27 These messages are then read out by read().  Splice and similar are disabled on
  28 such pipes due to them wanting to, under some circumstances, revert their
  29 additions to the ring - which might end up interleaved with notification
  30 messages.
  31
  32 The owner of the pipe has to tell the kernel which sources it would like to
  33 watch through that pipe.  Only sources that have been connected to a pipe will
  34 insert messages into it.  Note that a source may be bound to multiple pipes and
  35 insert messages into all of them simultaneously.
  36
  37 Filters may also be emplaced on a pipe so that certain source types and
  38 subevents can be ignored if they're not of interest.
  39
  40 A message will be discarded if there isn't a slot available in the ring or if
  41 no preallocated message buffer is available.  In both of these cases, read()
  42 will insert a WATCH_META_LOSS_NOTIFICATION message into the output buffer after
  43 the last message currently in the buffer has been read.
  44
  45 Note that when producing a notification, the kernel does not wait for the
  46 consumers to collect it, but rather just continues on.  This means that
  47 notifications can be generated whilst spinlocks are held and also protects the
  48 kernel from being held up indefinitely by a userspace malfunction.
  49
  50
  51 Message Structure
  52 =================
  53
  54 Notification 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
  63 the type of record from that source (see the Watch Sources section below).  The
  64 type may also be "WATCH_TYPE_META".  This is a special record type generated
  65 internally by the watch queue itself.  There are two subtypes:
  66
  67   * WATCH_META_REMOVAL_NOTIFICATION
  68   * WATCH_META_LOSS_NOTIFICATION
  69
  70 The first indicates that an object on which a watch was installed was removed
  71 or 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
  88 Everything in info apart from the length can be used for filtering.
  89
  90 The header can be followed by supplementary information.  The format of this is
  91 at the discretion is defined by the type and subtype.
  92
  93
  94 Watch List (Notification Source) API
  95 ====================================
  96
  97 A "watch list" is a list of watchers that are subscribed to a source of
  98 notifications.  A list may be attached to an object (say a key or a superblock)
  99 or may be global (say for device events).  From a userspace perspective, a
 100 non-global watch list is typically referred to by reference to the object it
 101 belongs to (such as using KEYCTL_NOTIFY and giving it a key serial number to
 102 watch that specific key).
 103
 104 To 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
 120 Watch Queue (Notification Output) API
 121 =====================================
 122
 123 A "watch queue" is the buffer allocated by an application that notification
 124 records will be written into.  The workings of this are hidden entirely inside
 125 of the pipe device driver, but it is necessary to gain a reference to it to set
 126 a 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
 140 Watch Subscription API
 141 ======================
 142
 143 A "watch" is a subscription on a watch list, indicating the watch queue, and
 144 thus the buffer, into which notification records should be written.  The watch
 145 queue object may also carry filtering rules for that object, as set by
 146 userspace.  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
 158 The ``info_id`` value should be an 8-bit number obtained from userspace and
 159 shifted by WATCH_INFO_ID__SHIFT.  This is OR'd into the WATCH_INFO_ID field of
 160 struct watch_notification::info when and if the notification is written into
 161 the associated watch queue buffer.
 162
 163 The ``private`` field is the driver's data associated with the watch_list and
 164 is cleaned up by the ``watch_list::release_watch()`` method.
 165
 166 The ``id`` field is the source's ID.  Notifications that are posted with a
 167 different ID are ignored.
 168
 169 The 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
 200 Notification Posting API
 201 ========================
 202
 203 To post a notification to watch list so that the subscribed watches can see it,
 204 the 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
 211 The notification should be preformatted and a pointer to the header (``n``)
 212 should be passed in.  The notification may be larger than this and the size in
 213 units of buffer slots is noted in ``n->info & WATCH_INFO_LENGTH``.
 214
 215 The ``cred`` struct indicates the credentials of the source (subject) and is
 216 passed to the LSMs, such as SELinux, to allow or suppress the recording of the
 217 note in each individual queue according to the credentials of that queue
 218 (object).
 219
 220 The ``id`` is the ID of the source object (such as the serial number on a key).
 221 Only watches that have the same ID set in them will see this notification.
 222
 223
 224 Watch Sources
 225 =============
 226
 227 Any 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
 237 Event Filtering
 238 ===============
 239
 240 Once a watch queue has been created, a set of filters can be applied to limit
 241 the events that are received using::
 242
 243         struct watch_notification_filter filter = {
 244                 ...
 245         };
 246         ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter)
 247
 248 The 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
 256 Where "nr_filters" is the number of filters in filters[] and "__reserved"
 257 should 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
 266 Where:
 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
 283 If the argument to the ioctl() is NULL, then the filters will be removed and
 284 all events from the watched sources will come through.
 285
 286
 287 Userspace Code Example
 288 ======================
 289
 290 A 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
 295 It can then be set to receive keyring change notifications::
 296
 297         keyctl(KEYCTL_WATCH_KEY, KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
 298
 299 The 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         }