Back to home page

OSCL-LXR

 
 

    


0001 ==============================
0002 General notification mechanism
0003 ==============================
0004 
0005 The general notification mechanism is built on top of the standard pipe driver
0006 whereby it effectively splices notification messages from the kernel into pipes
0007 opened by userspace.  This can be used in conjunction with::
0008 
0009   * Key/keyring notifications
0010 
0011 
0012 The notifications buffers can be enabled by:
0013 
0014         "General setup"/"General notification queue"
0015         (CONFIG_WATCH_QUEUE)
0016 
0017 This document has the following sections:
0018 
0019 .. contents:: :local:
0020 
0021 
0022 Overview
0023 ========
0024 
0025 This facility appears as a pipe that is opened in a special mode.  The pipe's
0026 internal ring buffer is used to hold messages that are generated by the kernel.
0027 These messages are then read out by read().  Splice and similar are disabled on
0028 such pipes due to them wanting to, under some circumstances, revert their
0029 additions to the ring - which might end up interleaved with notification
0030 messages.
0031 
0032 The owner of the pipe has to tell the kernel which sources it would like to
0033 watch through that pipe.  Only sources that have been connected to a pipe will
0034 insert messages into it.  Note that a source may be bound to multiple pipes and
0035 insert messages into all of them simultaneously.
0036 
0037 Filters may also be emplaced on a pipe so that certain source types and
0038 subevents can be ignored if they're not of interest.
0039 
0040 A message will be discarded if there isn't a slot available in the ring or if
0041 no preallocated message buffer is available.  In both of these cases, read()
0042 will insert a WATCH_META_LOSS_NOTIFICATION message into the output buffer after
0043 the last message currently in the buffer has been read.
0044 
0045 Note that when producing a notification, the kernel does not wait for the
0046 consumers to collect it, but rather just continues on.  This means that
0047 notifications can be generated whilst spinlocks are held and also protects the
0048 kernel from being held up indefinitely by a userspace malfunction.
0049 
0050 
0051 Message Structure
0052 =================
0053 
0054 Notification messages begin with a short header::
0055 
0056         struct watch_notification {
0057                 __u32   type:24;
0058                 __u32   subtype:8;
0059                 __u32   info;
0060         };
0061 
0062 "type" indicates the source of the notification record and "subtype" indicates
0063 the type of record from that source (see the Watch Sources section below).  The
0064 type may also be "WATCH_TYPE_META".  This is a special record type generated
0065 internally by the watch queue itself.  There are two subtypes:
0066 
0067   * WATCH_META_REMOVAL_NOTIFICATION
0068   * WATCH_META_LOSS_NOTIFICATION
0069 
0070 The first indicates that an object on which a watch was installed was removed
0071 or destroyed and the second indicates that some messages have been lost.
0072 
0073 "info" indicates a bunch of things, including:
0074 
0075   * The length of the message in bytes, including the header (mask with
0076     WATCH_INFO_LENGTH and shift by WATCH_INFO_LENGTH__SHIFT).  This indicates
0077     the size of the record, which may be between 8 and 127 bytes.
0078 
0079   * The watch ID (mask with WATCH_INFO_ID and shift by WATCH_INFO_ID__SHIFT).
0080     This indicates that caller's ID of the watch, which may be between 0
0081     and 255.  Multiple watches may share a queue, and this provides a means to
0082     distinguish them.
0083 
0084   * A type-specific field (WATCH_INFO_TYPE_INFO).  This is set by the
0085     notification producer to indicate some meaning specific to the type and
0086     subtype.
0087 
0088 Everything in info apart from the length can be used for filtering.
0089 
0090 The header can be followed by supplementary information.  The format of this is
0091 at the discretion is defined by the type and subtype.
0092 
0093 
0094 Watch List (Notification Source) API
0095 ====================================
0096 
0097 A "watch list" is a list of watchers that are subscribed to a source of
0098 notifications.  A list may be attached to an object (say a key or a superblock)
0099 or may be global (say for device events).  From a userspace perspective, a
0100 non-global watch list is typically referred to by reference to the object it
0101 belongs to (such as using KEYCTL_NOTIFY and giving it a key serial number to
0102 watch that specific key).
0103 
0104 To manage a watch list, the following functions are provided:
0105 
0106   * ::
0107 
0108         void init_watch_list(struct watch_list *wlist,
0109                              void (*release_watch)(struct watch *wlist));
0110 
0111     Initialise a watch list.  If ``release_watch`` is not NULL, then this
0112     indicates a function that should be called when the watch_list object is
0113     destroyed to discard any references the watch list holds on the watched
0114     object.
0115 
0116   * ``void remove_watch_list(struct watch_list *wlist);``
0117 
0118     This removes all of the watches subscribed to a watch_list and frees them
0119     and then destroys the watch_list object itself.
0120 
0121 
0122 Watch Queue (Notification Output) API
0123 =====================================
0124 
0125 A "watch queue" is the buffer allocated by an application that notification
0126 records will be written into.  The workings of this are hidden entirely inside
0127 of the pipe device driver, but it is necessary to gain a reference to it to set
0128 a watch.  These can be managed with:
0129 
0130   * ``struct watch_queue *get_watch_queue(int fd);``
0131 
0132     Since watch queues are indicated to the kernel by the fd of the pipe that
0133     implements the buffer, userspace must hand that fd through a system call.
0134     This can be used to look up an opaque pointer to the watch queue from the
0135     system call.
0136 
0137   * ``void put_watch_queue(struct watch_queue *wqueue);``
0138 
0139     This discards the reference obtained from ``get_watch_queue()``.
0140 
0141 
0142 Watch Subscription API
0143 ======================
0144 
0145 A "watch" is a subscription on a watch list, indicating the watch queue, and
0146 thus the buffer, into which notification records should be written.  The watch
0147 queue object may also carry filtering rules for that object, as set by
0148 userspace.  Some parts of the watch struct can be set by the driver::
0149 
0150         struct watch {
0151                 union {
0152                         u32             info_id;        /* ID to be OR'd in to info field */
0153                         ...
0154                 };
0155                 void                    *private;       /* Private data for the watched object */
0156                 u64                     id;             /* Internal identifier */
0157                 ...
0158         };
0159 
0160 The ``info_id`` value should be an 8-bit number obtained from userspace and
0161 shifted by WATCH_INFO_ID__SHIFT.  This is OR'd into the WATCH_INFO_ID field of
0162 struct watch_notification::info when and if the notification is written into
0163 the associated watch queue buffer.
0164 
0165 The ``private`` field is the driver's data associated with the watch_list and
0166 is cleaned up by the ``watch_list::release_watch()`` method.
0167 
0168 The ``id`` field is the source's ID.  Notifications that are posted with a
0169 different ID are ignored.
0170 
0171 The following functions are provided to manage watches:
0172 
0173   * ``void init_watch(struct watch *watch, struct watch_queue *wqueue);``
0174 
0175     Initialise a watch object, setting its pointer to the watch queue, using
0176     appropriate barriering to avoid lockdep complaints.
0177 
0178   * ``int add_watch_to_object(struct watch *watch, struct watch_list *wlist);``
0179 
0180     Subscribe a watch to a watch list (notification source).  The
0181     driver-settable fields in the watch struct must have been set before this
0182     is called.
0183 
0184   * ::
0185 
0186         int remove_watch_from_object(struct watch_list *wlist,
0187                                      struct watch_queue *wqueue,
0188                                      u64 id, false);
0189 
0190     Remove a watch from a watch list, where the watch must match the specified
0191     watch queue (``wqueue``) and object identifier (``id``).  A notification
0192     (``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue to
0193     indicate that the watch got removed.
0194 
0195   * ``int remove_watch_from_object(struct watch_list *wlist, NULL, 0, true);``
0196 
0197     Remove all the watches from a watch list.  It is expected that this will be
0198     called preparatory to destruction and that the watch list will be
0199     inaccessible to new watches by this point.  A notification
0200     (``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue of each
0201     subscribed watch to indicate that the watch got removed.
0202 
0203 
0204 Notification Posting API
0205 ========================
0206 
0207 To post a notification to watch list so that the subscribed watches can see it,
0208 the following function should be used::
0209 
0210         void post_watch_notification(struct watch_list *wlist,
0211                                      struct watch_notification *n,
0212                                      const struct cred *cred,
0213                                      u64 id);
0214 
0215 The notification should be preformatted and a pointer to the header (``n``)
0216 should be passed in.  The notification may be larger than this and the size in
0217 units of buffer slots is noted in ``n->info & WATCH_INFO_LENGTH``.
0218 
0219 The ``cred`` struct indicates the credentials of the source (subject) and is
0220 passed to the LSMs, such as SELinux, to allow or suppress the recording of the
0221 note in each individual queue according to the credentials of that queue
0222 (object).
0223 
0224 The ``id`` is the ID of the source object (such as the serial number on a key).
0225 Only watches that have the same ID set in them will see this notification.
0226 
0227 
0228 Watch Sources
0229 =============
0230 
0231 Any particular buffer can be fed from multiple sources.  Sources include:
0232 
0233   * WATCH_TYPE_KEY_NOTIFY
0234 
0235     Notifications of this type indicate changes to keys and keyrings, including
0236     the changes of keyring contents or the attributes of keys.
0237 
0238     See Documentation/security/keys/core.rst for more information.
0239 
0240 
0241 Event Filtering
0242 ===============
0243 
0244 Once a watch queue has been created, a set of filters can be applied to limit
0245 the events that are received using::
0246 
0247         struct watch_notification_filter filter = {
0248                 ...
0249         };
0250         ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter)
0251 
0252 The filter description is a variable of type::
0253 
0254         struct watch_notification_filter {
0255                 __u32   nr_filters;
0256                 __u32   __reserved;
0257                 struct watch_notification_type_filter filters[];
0258         };
0259 
0260 Where "nr_filters" is the number of filters in filters[] and "__reserved"
0261 should be 0.  The "filters" array has elements of the following type::
0262 
0263         struct watch_notification_type_filter {
0264                 __u32   type;
0265                 __u32   info_filter;
0266                 __u32   info_mask;
0267                 __u32   subtype_filter[8];
0268         };
0269 
0270 Where:
0271 
0272   * ``type`` is the event type to filter for and should be something like
0273     "WATCH_TYPE_KEY_NOTIFY"
0274 
0275   * ``info_filter`` and ``info_mask`` act as a filter on the info field of the
0276     notification record.  The notification is only written into the buffer if::
0277 
0278         (watch.info & info_mask) == info_filter
0279 
0280     This could be used, for example, to ignore events that are not exactly on
0281     the watched point in a mount tree.
0282 
0283   * ``subtype_filter`` is a bitmask indicating the subtypes that are of
0284     interest.  Bit 0 of subtype_filter[0] corresponds to subtype 0, bit 1 to
0285     subtype 1, and so on.
0286 
0287 If the argument to the ioctl() is NULL, then the filters will be removed and
0288 all events from the watched sources will come through.
0289 
0290 
0291 Userspace Code Example
0292 ======================
0293 
0294 A buffer is created with something like the following::
0295 
0296         pipe2(fds, O_TMPFILE);
0297         ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
0298 
0299 It can then be set to receive keyring change notifications::
0300 
0301         keyctl(KEYCTL_WATCH_KEY, KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
0302 
0303 The notifications can then be consumed by something like the following::
0304 
0305         static void consumer(int rfd, struct watch_queue_buffer *buf)
0306         {
0307                 unsigned char buffer[128];
0308                 ssize_t buf_len;
0309 
0310                 while (buf_len = read(rfd, buffer, sizeof(buffer)),
0311                        buf_len > 0
0312                        ) {
0313                         void *p = buffer;
0314                         void *end = buffer + buf_len;
0315                         while (p < end) {
0316                                 union {
0317                                         struct watch_notification n;
0318                                         unsigned char buf1[128];
0319                                 } n;
0320                                 size_t largest, len;
0321 
0322                                 largest = end - p;
0323                                 if (largest > 128)
0324                                         largest = 128;
0325                                 memcpy(&n, p, largest);
0326 
0327                                 len = (n->info & WATCH_INFO_LENGTH) >>
0328                                         WATCH_INFO_LENGTH__SHIFT;
0329                                 if (len == 0 || len > largest)
0330                                         return;
0331 
0332                                 switch (n.n.type) {
0333                                 case WATCH_TYPE_META:
0334                                         got_meta(&n.n);
0335                                 case WATCH_TYPE_KEY_NOTIFY:
0336                                         saw_key_change(&n.n);
0337                                         break;
0338                                 }
0339 
0340                                 p += len;
0341                         }
0342                 }
0343         }