This document gives a brief introduction to Generic Netlink, some simple examples on how to use it and some recommendations on how to make the most of the Generic Netlink communications interface. While this document does not require that the reader has a detailed understanding of what Netlink is and how it works, some basic Netlink knowledge is assumed. As usual, the kernel source code is your best friend here.
While this document talks briefly about Generic Netlink from a userspace point of view, its primary focus is on the kernel's Generic Netlink API. It is recommended that application developers who are interested in using Generic Netlink make use of the libnl library[1].
This section deals with the Generic Netlink subsystem in the Linux kernel and provides a simple example of how in-kernel users can make use of the Generic Netlink API. Don't forget to review section #4, “Recommendations”, before writing any code as it can save you, and the people who review your code, lots of time!
The first section explains how to register a Generic Netlink family which is required for Generic Netlink users who wish to act as servers, listening over the Generic Netlink bus. The second section explains how to send and receive Generic Netlink messages in the kernel. Finally, the third section provides a brief introduction to using Generic Netlink in userspace.
Registering a Generic Netlink family is a simple four step process: define the family, define the operations, register the family, register the operations. In order to help demonstrate these steps below is a simple example broken down and explained in detail.
The first step is to define the family itself, which we do by creating an instance of the genl_family structure. In our simple example we are going to create a new Generic Netlink family named “DOC_EXMPL”.
/* attributes */
enum {
DOC_EXMPL_A_UNSPEC,
DOC_EXMPL_A_MSG,
__DOC_EXMPL_A_MAX,
};
#define DOC_EXMPL_A_MAX (__DOC_EXMPL_A_MAX - 1)
/* attribute policy */
static struct nla_policy doc_exmpl_genl_policy[DOC_EXMPL_A_MAX + 1] = {
[DOC_EXMPL_A_MSG] = { .type = NLA_NUL_STRING },
};
/* family definition */
static struct genl_family doc_exmpl_gnl_family = {
.id = GENL_ID_GENERATE,
.hdrsize = 0,
.name = "DOC_EXMPL",
.version = 1,
.maxattr = DOC_EXMPL_A_MAX,
};
Figure 1: The DOC_EXMPL family, attributes and policy
You can see above that we defined a new family and the family recognizes a single attribute, DOC_EXMPL_A_MSG, which is a NULL terminated string. The GENL_ID_GENERATE macro/constant is really just the value 0x0 and it signifies that we want the Generic Netlink controller to assign the channel number when we register the family.
The second step is to define the operations for the family, which we do by creating at least one instance of the genl_ops structure. In this example we are only going to define one operation but you can define up to 255 unique operations for each family.
/* handler */
static int doc_exmpl_echo(struct sk_buff *skb, struct genl_info *info)
{
/* message handling code goes here; return 0 on success, negative
* values on failure */
}
/* commands */
enum {
DOC_EXMPL_C_UNSPEC,
DOC_EXMPL_C_ECHO,
__DOC_EXMPL_C_MAX,
};
#define DOC_EXMPL_C_MAX (__DOC_EXMPL_C_MAX - 1)
/* operation definition */
static struct genl_ops doc_exmpl_gnl_ops_echo = {
.cmd = DOC_EXMPL_C_ECHO,
.flags = 0,
.policy = doc_exmpl_genl_policy,
.doit = doc_exmpl_echo,
.dumpit = NULL,
};
Figure 2: The DOC_EXMPL_C_ECHO operation
Here we have defined a single operation, DOC_EXMPL_C_ECHO, which uses the Netlink attribute policy we defined above. Once registered, this particular operation would call the doc_exmpl_echo() function whenever a DOC_EXMPL_C_ECHO message is sent to the DOC_EXMPL family over the Generic Netlink bus.
The third step is to register the DOC_EXMPL family with the Generic Netlink operation. We do this with a single function call:
int rc;
rc = genl_register_family(&doc_exmpl_gnl_family);
if (rc != 0)
goto failure;
This call registers the new family name with the Generic Netlink mechanism and requests a new channel number which is stored in the genl_family struct, replacing the GENL_ID_GENERATE value. It is important to remember to unregister Generic Netlink families when done as the kernel does allocate resources for each registered family.
The fourth and final step is to register the operations for the family. Once again this is a simple function call:
int rc;
rc = genl_register_ops(&doc_exmpl_gnl_family, &doc_exmpl_gnl_ops_echo);
if (rc != 0)
goto failure;
NOTE: This function doesn't exist past linux 3.12. Up to linux 4.10, use genl_register_family_with_ops(). On 4.10 and later, include a reference to your genl_ops struct as an element in the genl_family struct (element .ops), as well as the number of commands (element .n_ops).
This call registers the DOC_EXMPL_C_ECHO operation in association with the DOC_EXMPL family. The process is now complete. Other Generic Netlink users can now issue DOC_EXMPL_C_ECHO commands and they will be handled as desired.
The kernel provides two sets of interfaces for sending, receiving and processing Generic Netlink messages. The majority of the API consists of the general purpose Netlink interfaces, however, there are a small number of interfaces specific to Generic Netlink. The following two “include” files define the Netlink and Generic Netlink API for the kernel:
Sending Generic Netlink messages is a three step process: allocate memory for the message buffer, create the message, send the message. In order to help demonstrate these steps, below is a simple example using the DOC_EXMPL family.
The first step is to allocate a Netlink message buffer; the easiest way to do this is with the nlsmsg_new() function.
struct sk_buff *skb;
skb = genlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
if (skb == NULL)
goto failure;
Figure 3: Allocating a Generic Netlink message buffer
The NLMSG_GOODSIZE macro/constant is a good value to use when you do not know the size of the message buffer at the time of allocation. Don't forget that the genlmsg_new() function automatically adds space for the Netlink and Generic Netlink message headers.
The second step is to actually create the message payload. This is obviously something which is very specific to each service, but a simple example is shown below.
int rc;
void *msg_head;
/* create the message headers */
msg_head = genlmsg_put(skb, pid, seq, type, 0, flags, DOC_EXMPL_C_ECHO, 1);
if (msg_head == NULL) {
rc = -ENOMEM;
goto failure;
}
/* add a DOC_EXMPL_A_MSG attribute */
rc = nla_put_string(skb, DOC_EXMPL_A_MSG, "Generic Netlink Rocks");
if (rc != 0)
goto failure;
/* finalize the message */
genlmsg_end(skb, msg_head);
Figure 4: Creating a Generic Netlink message payload
The genlmsg_put() function creates the required Netlink and Generic Netlink message headers, populating them with the given values; see the Generic Netlink header file for a description of the parameters. The nla_put_string() function is a standard Netlink attribute function which adds a string attribute to the end of the Netlink message; see the Netlink header file for a description of the parameters. The genlmsg_end() function updates the Netlink message header once the message payload has been finalized. This function should be called before sending the message.
The third and final step is to send the Generic Netlink message which can be done with a single function call. The example below is for a unicast send, but interfaces exist for doing a multicast send of Generic Netlink message.
int rc;
rc = genlmsg_unicast(skb, pid);
if (rc != 0)
goto failure;
Figure 5: Sending Generic Netlink messages
Typically, kernel modules act as Generic Netlink servers which means that the act of receiving messages is handled automatically by the Generic Netlink bus. Once the bus receives the message and determines the correct routing, the message is passed directly to the family specific operation callback for processing. If the kernel is acting as a Generic Netlink client, server response messages can be received over the Generic Netlink socket using standard kernel socket interfaces.
While Generic Netlink messages can be sent and received using the standard socket API it is recommended that user space applications use the libnl library[1]. The libnl library insulates applications from many of the low level Netlink tasks and uses an API which is very similar to the kernel API shown above.
Figure #6 illustrates the basic Generic Netlink architecture which is composed of five different types of components:
+---------------------+ +---------------------+
| (3) application "A" | | (3) application "B" |
+------+--------------+ +--------------+------+
| |
\ /
\ /
| |
+-------+--------------------------------+-------+
| : : | user-space
=====+ : (5) kernel socket API : +================
| : : | kernel-space
+--------+-------------------------------+-------+
| |
+-----+-------------------------------+----+
| (1) Netlink subsystem |
+---------------------+--------------------+
|
+---------------------+--------------------+
| (2) Generic Netlink bus |
+--+--------------------------+-------+----+
| | |
+-------+---------+ | |
| (4) controller | / \
+-----------------+ / \
| |
+------------------+--+ +--+------------------+
| (3) kernel user "X" | | (3) kernel user "Y" |
+---------------------+ +---------------------+
Figure 6: Generic Netlink Architecture
When looking at figure #6 it is important to note that any Generic Netlink user can communicate with any other user over the bus using the same API regardless of where the user resides in relation to the kernel/userspace boundary.
Generic Netlink communications are essentially a series of different communication channels which are multiplexed on a single Netlink family. Communication channels are uniquely identified by channel numbers which are dynamically allocated by the Generic Netlink controller. The controller is a special Generic Netlink user which listens on a fixed communication channel, number 0x10, which is always present. Kernel or userspace users which provide services over the Generic Netlink bus establish new communication channels by registering their services with the Generic Netlink controller. Users who want to use a service query the controller to see if the service exists and to determine the correct channel number.
This section provides a more in-depth explanation of the Generic Netlink message formats and data structures.
Generic Netlink uses the standard Netlink subsystem as a transport layer which means that the foundation of the Generic Netlink message is the standard Netlink message format - the only difference is the inclusion of a Generic Netlink message header. The format of the message is defined as shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Netlink message header (nlmsghdr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Generic Netlink message header (genlmsghdr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional user specific message header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Generic Netlink message payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Generic Netlink message format
Figure #7 is included only to give you a rough idea of how Generic Netlink messages are formatted and sent “on the wire”. In practice the Netlink and Generic Netlink API should insulate most users from the details of the message format and the Netlink message headers.
This section focuses on the Generic Netlink data structures as they are defined in the kernel. A similar API exists for userspace applications using the libnl library[1].
Generic Netlink families are defined by the genl_family structure, which is shown below:
struct genl_family
{
unsigned int id;
unsigned int hdrsize;
char name[GENL_NAMSIZ];
unsigned int version;
unsigned int maxattr;
struct nlattr ** attrbuf;
struct list_head ops_list;
struct list_head family_list;
};
Figure 8: The genl_family structure
The genl_family structure fields are used in the following manner:
Generic Netlink operations are defined by the genl_ops structure, which is shown below:
struct genl_ops
{
u8 cmd;
unsigned int flags;
struct nla_policy *policy;
int (*doit)(struct sk_buff *skb,
struct genl_info *info);
int (*dumpit)(struct sk_buff *skb,
struct netlink_callback *cb);
struct list_head ops_list;
};
Figure 9: The genl_ops structure
The genl_ops structure fields are used in the following manner:
Generic Netlink message information is passed by the genl_info structure, which is shown below:
struct genl_info
{
u32 snd_seq;
u32 snd_pid;
struct nlmsghdr * nlhdr;
struct genlmsghdr * genlhdr;
void * userhdr;
struct nlattr ** attrs;
};
Figure 10: The genl_info structure
The fields are populated in the following manner:
Generic Netlink attribute policy is defined by the nla_policy structure, which is shown below:
struct nla_policy
{
u16 type;
u16 len;
};
Figure 11: The nla_policy structure
The fields are used in the following manner:
The Generic Netlink mechanism is a very flexible communications mechanism and as a result there are many different ways it can be used. The following recommendations are based on conventions within the Linux kernel and should be followed whenever possible. While not all existing kernel code follows the recommendations outlined here, all new code should consider these recommendations as requirements.
When defining new Generic Netlink message formats you must make use of the Netlink attributes wherever possible. The Netlink attribute mechanism has been carefully designed to allow for future message expansion while preserving backward compatibility. There are also additional benefits from using Netlink attributes which include developer familiarity and basic input checking.
Most common data structures can be represented with Netlink attributes:
It is also important to use unique attributes as much as possible. This helps make the most of the Netlink attribute mechanisms and provides for easy changes to the message format in the future.
While it may be tempting to register a single operation for a Generic Netlink family and multiplex multiple sub-commands on the single operation, this is strongly discouraged for security reasons. Combining multiple behaviors into one operation makes it difficult to restrict the operations using the existing Linux kernel security mechanisms.
It is often necessary for Generic Netlink services to return an ACK or error code to the client. It is not necessary to implement an explicit acknowledgment message as Netlink already provides a flexible acknowledgment and error reporting message type called NLMSG_ERROR. When an error occurs an NLMSG_ERROR message is returned to the client with the error code returned by the Generic Netlink operation handler. Clients can also request the NLMSG_ERROR message when no error has occurred by setting the NLM_F_ACK flag on requests.
NOTE: This link is no longer valid. Try http://www.infradead.org/~tgr/libnl