netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
/*
|
|
|
|
|
* NETLINK Policy advertisement to userspace
|
|
|
|
|
*
|
|
|
|
|
* Authors: Johannes Berg <johannes@sipsolutions.net>
|
|
|
|
|
*
|
|
|
|
|
* Copyright 2019 Intel Corporation
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/errno.h>
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
#include <net/netlink.h>
|
|
|
|
|
|
|
|
|
|
#define INITIAL_POLICIES_ALLOC 10
|
|
|
|
|
|
2020-10-03 00:49:55 +03:00
|
|
|
struct netlink_policy_dump_state {
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
unsigned int policy_idx;
|
|
|
|
|
unsigned int attr_idx;
|
|
|
|
|
unsigned int n_alloc;
|
|
|
|
|
struct {
|
|
|
|
|
const struct nla_policy *policy;
|
|
|
|
|
unsigned int maxtype;
|
|
|
|
|
} policies[];
|
|
|
|
|
};
|
|
|
|
|
|
2020-10-03 00:49:55 +03:00
|
|
|
static int add_policy(struct netlink_policy_dump_state **statep,
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
const struct nla_policy *policy,
|
|
|
|
|
unsigned int maxtype)
|
|
|
|
|
{
|
2020-10-03 00:49:55 +03:00
|
|
|
struct netlink_policy_dump_state *state = *statep;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
unsigned int n_alloc, i;
|
|
|
|
|
|
|
|
|
|
if (!policy || !maxtype)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < state->n_alloc; i++) {
|
2020-10-03 11:44:42 +03:00
|
|
|
if (state->policies[i].policy == policy &&
|
|
|
|
|
state->policies[i].maxtype == maxtype)
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
if (!state->policies[i].policy) {
|
|
|
|
|
state->policies[i].policy = policy;
|
|
|
|
|
state->policies[i].maxtype = maxtype;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
n_alloc = state->n_alloc + INITIAL_POLICIES_ALLOC;
|
|
|
|
|
state = krealloc(state, struct_size(state, policies, n_alloc),
|
|
|
|
|
GFP_KERNEL);
|
|
|
|
|
if (!state)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
2020-08-19 22:52:38 +03:00
|
|
|
memset(&state->policies[state->n_alloc], 0,
|
|
|
|
|
flex_array_size(state, policies, n_alloc - state->n_alloc));
|
|
|
|
|
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
state->policies[state->n_alloc].policy = policy;
|
|
|
|
|
state->policies[state->n_alloc].maxtype = maxtype;
|
|
|
|
|
state->n_alloc = n_alloc;
|
|
|
|
|
*statep = state;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-03 11:44:43 +03:00
|
|
|
/**
|
|
|
|
|
* netlink_policy_dump_get_policy_idx - retrieve policy index
|
|
|
|
|
* @state: the policy dump state
|
|
|
|
|
* @policy: the policy to find
|
|
|
|
|
* @maxtype: the policy's maxattr
|
|
|
|
|
*
|
|
|
|
|
* Returns: the index of the given policy in the dump state
|
|
|
|
|
*
|
|
|
|
|
* Call this to find a policy index when you've added multiple and e.g.
|
|
|
|
|
* need to tell userspace which command has which policy (by index).
|
|
|
|
|
*
|
|
|
|
|
* Note: this will WARN and return 0 if the policy isn't found, which
|
|
|
|
|
* means it wasn't added in the first place, which would be an
|
|
|
|
|
* internal consistency bug.
|
|
|
|
|
*/
|
|
|
|
|
int netlink_policy_dump_get_policy_idx(struct netlink_policy_dump_state *state,
|
|
|
|
|
const struct nla_policy *policy,
|
|
|
|
|
unsigned int maxtype)
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
{
|
|
|
|
|
unsigned int i;
|
|
|
|
|
|
2020-10-03 11:44:43 +03:00
|
|
|
if (WARN_ON(!policy || !maxtype))
|
|
|
|
|
return 0;
|
|
|
|
|
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
for (i = 0; i < state->n_alloc; i++) {
|
2020-10-03 11:44:42 +03:00
|
|
|
if (state->policies[i].policy == policy &&
|
|
|
|
|
state->policies[i].maxtype == maxtype)
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
return i;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-03 11:44:43 +03:00
|
|
|
WARN_ON(1);
|
|
|
|
|
return 0;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
}
|
|
|
|
|
|
2020-10-03 11:44:43 +03:00
|
|
|
static struct netlink_policy_dump_state *alloc_state(void)
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
{
|
2020-10-03 00:49:55 +03:00
|
|
|
struct netlink_policy_dump_state *state;
|
2020-10-03 11:44:43 +03:00
|
|
|
|
|
|
|
|
state = kzalloc(struct_size(state, policies, INITIAL_POLICIES_ALLOC),
|
|
|
|
|
GFP_KERNEL);
|
|
|
|
|
if (!state)
|
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
state->n_alloc = INITIAL_POLICIES_ALLOC;
|
|
|
|
|
|
|
|
|
|
return state;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* netlink_policy_dump_add_policy - add a policy to the dump
|
|
|
|
|
* @pstate: state to add to, may be reallocated, must be %NULL the first time
|
|
|
|
|
* @policy: the new policy to add to the dump
|
|
|
|
|
* @maxtype: the new policy's max attr type
|
|
|
|
|
*
|
|
|
|
|
* Returns: 0 on success, a negative error code otherwise.
|
|
|
|
|
*
|
|
|
|
|
* Call this to allocate a policy dump state, and to add policies to it. This
|
|
|
|
|
* should be called from the dump start() callback.
|
|
|
|
|
*
|
|
|
|
|
* Note: on failures, any previously allocated state is freed.
|
|
|
|
|
*/
|
|
|
|
|
int netlink_policy_dump_add_policy(struct netlink_policy_dump_state **pstate,
|
|
|
|
|
const struct nla_policy *policy,
|
|
|
|
|
unsigned int maxtype)
|
|
|
|
|
{
|
|
|
|
|
struct netlink_policy_dump_state *state = *pstate;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
unsigned int policy_idx;
|
|
|
|
|
int err;
|
|
|
|
|
|
2020-10-03 11:44:43 +03:00
|
|
|
if (!state) {
|
|
|
|
|
state = alloc_state();
|
|
|
|
|
if (IS_ERR(state))
|
|
|
|
|
return PTR_ERR(state);
|
|
|
|
|
}
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* walk the policies and nested ones first, and build
|
|
|
|
|
* a linear list of them.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
err = add_policy(&state, policy, maxtype);
|
|
|
|
|
if (err)
|
2022-08-16 19:19:39 +03:00
|
|
|
goto err_try_undo;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
|
|
|
|
|
for (policy_idx = 0;
|
|
|
|
|
policy_idx < state->n_alloc && state->policies[policy_idx].policy;
|
|
|
|
|
policy_idx++) {
|
|
|
|
|
const struct nla_policy *policy;
|
|
|
|
|
unsigned int type;
|
|
|
|
|
|
|
|
|
|
policy = state->policies[policy_idx].policy;
|
|
|
|
|
|
|
|
|
|
for (type = 0;
|
|
|
|
|
type <= state->policies[policy_idx].maxtype;
|
|
|
|
|
type++) {
|
|
|
|
|
switch (policy[type].type) {
|
|
|
|
|
case NLA_NESTED:
|
|
|
|
|
case NLA_NESTED_ARRAY:
|
|
|
|
|
err = add_policy(&state,
|
|
|
|
|
policy[type].nested_policy,
|
|
|
|
|
policy[type].len);
|
|
|
|
|
if (err)
|
2022-08-16 19:19:39 +03:00
|
|
|
goto err_try_undo;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-03 11:44:43 +03:00
|
|
|
*pstate = state;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
return 0;
|
2022-08-16 19:19:39 +03:00
|
|
|
|
|
|
|
|
err_try_undo:
|
|
|
|
|
/* Try to preserve reasonable unwind semantics - if we're starting from
|
|
|
|
|
* scratch clean up fully, otherwise record what we got and caller will.
|
|
|
|
|
*/
|
|
|
|
|
if (!*pstate)
|
|
|
|
|
netlink_policy_dump_free(state);
|
|
|
|
|
else
|
|
|
|
|
*pstate = state;
|
|
|
|
|
return err;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
}
|
|
|
|
|
|
2020-10-03 00:49:55 +03:00
|
|
|
static bool
|
|
|
|
|
netlink_policy_dump_finished(struct netlink_policy_dump_state *state)
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
{
|
|
|
|
|
return state->policy_idx >= state->n_alloc ||
|
|
|
|
|
!state->policies[state->policy_idx].policy;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-03 11:44:43 +03:00
|
|
|
/**
|
|
|
|
|
* netlink_policy_dump_loop - dumping loop indicator
|
|
|
|
|
* @state: the policy dump state
|
|
|
|
|
*
|
|
|
|
|
* Returns: %true if the dump continues, %false otherwise
|
|
|
|
|
*
|
|
|
|
|
* Note: this frees the dump state when finishing
|
|
|
|
|
*/
|
2020-10-03 00:49:55 +03:00
|
|
|
bool netlink_policy_dump_loop(struct netlink_policy_dump_state *state)
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
{
|
2020-10-02 10:46:04 +03:00
|
|
|
return !netlink_policy_dump_finished(state);
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
}
|
|
|
|
|
|
2020-10-08 13:45:17 +03:00
|
|
|
int netlink_policy_dump_attr_size_estimate(const struct nla_policy *pt)
|
|
|
|
|
{
|
|
|
|
|
/* nested + type */
|
|
|
|
|
int common = 2 * nla_attr_size(sizeof(u32));
|
|
|
|
|
|
|
|
|
|
switch (pt->type) {
|
|
|
|
|
case NLA_UNSPEC:
|
|
|
|
|
case NLA_REJECT:
|
|
|
|
|
/* these actually don't need any space */
|
|
|
|
|
return 0;
|
|
|
|
|
case NLA_NESTED:
|
|
|
|
|
case NLA_NESTED_ARRAY:
|
|
|
|
|
/* common, policy idx, policy maxattr */
|
|
|
|
|
return common + 2 * nla_attr_size(sizeof(u32));
|
|
|
|
|
case NLA_U8:
|
|
|
|
|
case NLA_U16:
|
|
|
|
|
case NLA_U32:
|
|
|
|
|
case NLA_U64:
|
|
|
|
|
case NLA_MSECS:
|
|
|
|
|
case NLA_S8:
|
|
|
|
|
case NLA_S16:
|
|
|
|
|
case NLA_S32:
|
|
|
|
|
case NLA_S64:
|
|
|
|
|
/* maximum is common, u64 min/max with padding */
|
|
|
|
|
return common +
|
|
|
|
|
2 * (nla_attr_size(0) + nla_attr_size(sizeof(u64)));
|
|
|
|
|
case NLA_BITFIELD32:
|
|
|
|
|
return common + nla_attr_size(sizeof(u32));
|
|
|
|
|
case NLA_STRING:
|
|
|
|
|
case NLA_NUL_STRING:
|
|
|
|
|
case NLA_BINARY:
|
|
|
|
|
/* maximum is common, u32 min-length/max-length */
|
|
|
|
|
return common + 2 * nla_attr_size(sizeof(u32));
|
|
|
|
|
case NLA_FLAG:
|
|
|
|
|
return common;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* this should then cause a warning later */
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-08 13:45:16 +03:00
|
|
|
static int
|
|
|
|
|
__netlink_policy_dump_write_attr(struct netlink_policy_dump_state *state,
|
|
|
|
|
struct sk_buff *skb,
|
|
|
|
|
const struct nla_policy *pt,
|
|
|
|
|
int nestattr)
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
{
|
2020-10-08 13:45:17 +03:00
|
|
|
int estimate = netlink_policy_dump_attr_size_estimate(pt);
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
enum netlink_attribute_type type;
|
2020-10-08 13:45:16 +03:00
|
|
|
struct nlattr *attr;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
|
2020-10-08 13:45:16 +03:00
|
|
|
attr = nla_nest_start(skb, nestattr);
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
if (!attr)
|
2020-10-08 13:45:16 +03:00
|
|
|
return -ENOBUFS;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
|
|
|
|
|
switch (pt->type) {
|
|
|
|
|
default:
|
|
|
|
|
case NLA_UNSPEC:
|
|
|
|
|
case NLA_REJECT:
|
|
|
|
|
/* skip - use NLA_MIN_LEN to advertise such */
|
2020-10-08 13:45:16 +03:00
|
|
|
nla_nest_cancel(skb, attr);
|
|
|
|
|
return -ENODATA;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
case NLA_NESTED:
|
|
|
|
|
type = NL_ATTR_TYPE_NESTED;
|
2020-08-24 01:36:59 +03:00
|
|
|
fallthrough;
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
case NLA_NESTED_ARRAY:
|
|
|
|
|
if (pt->type == NLA_NESTED_ARRAY)
|
|
|
|
|
type = NL_ATTR_TYPE_NESTED_ARRAY;
|
2020-10-08 13:45:16 +03:00
|
|
|
if (state && pt->nested_policy && pt->len &&
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
(nla_put_u32(skb, NL_POLICY_TYPE_ATTR_POLICY_IDX,
|
2020-10-03 11:44:43 +03:00
|
|
|
netlink_policy_dump_get_policy_idx(state,
|
|
|
|
|
pt->nested_policy,
|
|
|
|
|
pt->len)) ||
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
nla_put_u32(skb, NL_POLICY_TYPE_ATTR_POLICY_MAXTYPE,
|
|
|
|
|
pt->len)))
|
|
|
|
|
goto nla_put_failure;
|
|
|
|
|
break;
|
|
|
|
|
case NLA_U8:
|
|
|
|
|
case NLA_U16:
|
|
|
|
|
case NLA_U32:
|
|
|
|
|
case NLA_U64:
|
|
|
|
|
case NLA_MSECS: {
|
|
|
|
|
struct netlink_range_validation range;
|
|
|
|
|
|
|
|
|
|
if (pt->type == NLA_U8)
|
|
|
|
|
type = NL_ATTR_TYPE_U8;
|
|
|
|
|
else if (pt->type == NLA_U16)
|
|
|
|
|
type = NL_ATTR_TYPE_U16;
|
|
|
|
|
else if (pt->type == NLA_U32)
|
|
|
|
|
type = NL_ATTR_TYPE_U32;
|
|
|
|
|
else
|
|
|
|
|
type = NL_ATTR_TYPE_U64;
|
|
|
|
|
|
2020-10-06 01:07:38 +03:00
|
|
|
if (pt->validation_type == NLA_VALIDATE_MASK) {
|
|
|
|
|
if (nla_put_u64_64bit(skb, NL_POLICY_TYPE_ATTR_MASK,
|
|
|
|
|
pt->mask,
|
|
|
|
|
NL_POLICY_TYPE_ATTR_PAD))
|
|
|
|
|
goto nla_put_failure;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
nla_get_range_unsigned(pt, &range);
|
|
|
|
|
|
|
|
|
|
if (nla_put_u64_64bit(skb, NL_POLICY_TYPE_ATTR_MIN_VALUE_U,
|
|
|
|
|
range.min, NL_POLICY_TYPE_ATTR_PAD) ||
|
|
|
|
|
nla_put_u64_64bit(skb, NL_POLICY_TYPE_ATTR_MAX_VALUE_U,
|
|
|
|
|
range.max, NL_POLICY_TYPE_ATTR_PAD))
|
|
|
|
|
goto nla_put_failure;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case NLA_S8:
|
|
|
|
|
case NLA_S16:
|
|
|
|
|
case NLA_S32:
|
|
|
|
|
case NLA_S64: {
|
|
|
|
|
struct netlink_range_validation_signed range;
|
|
|
|
|
|
|
|
|
|
if (pt->type == NLA_S8)
|
|
|
|
|
type = NL_ATTR_TYPE_S8;
|
|
|
|
|
else if (pt->type == NLA_S16)
|
|
|
|
|
type = NL_ATTR_TYPE_S16;
|
|
|
|
|
else if (pt->type == NLA_S32)
|
|
|
|
|
type = NL_ATTR_TYPE_S32;
|
|
|
|
|
else
|
|
|
|
|
type = NL_ATTR_TYPE_S64;
|
|
|
|
|
|
|
|
|
|
nla_get_range_signed(pt, &range);
|
|
|
|
|
|
|
|
|
|
if (nla_put_s64(skb, NL_POLICY_TYPE_ATTR_MIN_VALUE_S,
|
|
|
|
|
range.min, NL_POLICY_TYPE_ATTR_PAD) ||
|
|
|
|
|
nla_put_s64(skb, NL_POLICY_TYPE_ATTR_MAX_VALUE_S,
|
|
|
|
|
range.max, NL_POLICY_TYPE_ATTR_PAD))
|
|
|
|
|
goto nla_put_failure;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case NLA_BITFIELD32:
|
|
|
|
|
type = NL_ATTR_TYPE_BITFIELD32;
|
|
|
|
|
if (nla_put_u32(skb, NL_POLICY_TYPE_ATTR_BITFIELD32_MASK,
|
|
|
|
|
pt->bitfield32_valid))
|
|
|
|
|
goto nla_put_failure;
|
|
|
|
|
break;
|
|
|
|
|
case NLA_STRING:
|
|
|
|
|
case NLA_NUL_STRING:
|
|
|
|
|
case NLA_BINARY:
|
|
|
|
|
if (pt->type == NLA_STRING)
|
|
|
|
|
type = NL_ATTR_TYPE_STRING;
|
|
|
|
|
else if (pt->type == NLA_NUL_STRING)
|
|
|
|
|
type = NL_ATTR_TYPE_NUL_STRING;
|
|
|
|
|
else
|
|
|
|
|
type = NL_ATTR_TYPE_BINARY;
|
netlink: make NLA_BINARY validation more flexible
Add range validation for NLA_BINARY, allowing validation of any
combination of combination minimum or maximum lengths, using the
existing NLA_POLICY_RANGE()/NLA_POLICY_FULL_RANGE() macros, just
like for integers where the value is checked.
Also make NLA_POLICY_EXACT_LEN(), NLA_POLICY_EXACT_LEN_WARN()
and NLA_POLICY_MIN_LEN() special cases of this, removing the old
types NLA_EXACT_LEN and NLA_MIN_LEN.
This allows us to save some code where both minimum and maximum
lengths are requires, currently the policy only allows maximum
(NLA_BINARY), minimum (NLA_MIN_LEN) or exact (NLA_EXACT_LEN), so
a range of lengths cannot be accepted and must be checked by the
code that consumes the attributes later.
Also, this allows advertising the correct ranges in the policy
export to userspace. Here, NLA_MIN_LEN and NLA_EXACT_LEN already
were special cases of NLA_BINARY with min and min/max length
respectively.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-08-18 11:17:33 +03:00
|
|
|
|
2020-08-31 21:28:05 +03:00
|
|
|
if (pt->validation_type == NLA_VALIDATE_RANGE ||
|
|
|
|
|
pt->validation_type == NLA_VALIDATE_RANGE_WARN_TOO_LONG) {
|
netlink: make NLA_BINARY validation more flexible
Add range validation for NLA_BINARY, allowing validation of any
combination of combination minimum or maximum lengths, using the
existing NLA_POLICY_RANGE()/NLA_POLICY_FULL_RANGE() macros, just
like for integers where the value is checked.
Also make NLA_POLICY_EXACT_LEN(), NLA_POLICY_EXACT_LEN_WARN()
and NLA_POLICY_MIN_LEN() special cases of this, removing the old
types NLA_EXACT_LEN and NLA_MIN_LEN.
This allows us to save some code where both minimum and maximum
lengths are requires, currently the policy only allows maximum
(NLA_BINARY), minimum (NLA_MIN_LEN) or exact (NLA_EXACT_LEN), so
a range of lengths cannot be accepted and must be checked by the
code that consumes the attributes later.
Also, this allows advertising the correct ranges in the policy
export to userspace. Here, NLA_MIN_LEN and NLA_EXACT_LEN already
were special cases of NLA_BINARY with min and min/max length
respectively.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-08-18 11:17:33 +03:00
|
|
|
struct netlink_range_validation range;
|
|
|
|
|
|
|
|
|
|
nla_get_range_unsigned(pt, &range);
|
|
|
|
|
|
|
|
|
|
if (range.min &&
|
|
|
|
|
nla_put_u32(skb, NL_POLICY_TYPE_ATTR_MIN_LENGTH,
|
|
|
|
|
range.min))
|
|
|
|
|
goto nla_put_failure;
|
|
|
|
|
|
|
|
|
|
if (range.max < U16_MAX &&
|
|
|
|
|
nla_put_u32(skb, NL_POLICY_TYPE_ATTR_MAX_LENGTH,
|
|
|
|
|
range.max))
|
|
|
|
|
goto nla_put_failure;
|
|
|
|
|
} else if (pt->len &&
|
|
|
|
|
nla_put_u32(skb, NL_POLICY_TYPE_ATTR_MAX_LENGTH,
|
|
|
|
|
pt->len)) {
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
goto nla_put_failure;
|
netlink: make NLA_BINARY validation more flexible
Add range validation for NLA_BINARY, allowing validation of any
combination of combination minimum or maximum lengths, using the
existing NLA_POLICY_RANGE()/NLA_POLICY_FULL_RANGE() macros, just
like for integers where the value is checked.
Also make NLA_POLICY_EXACT_LEN(), NLA_POLICY_EXACT_LEN_WARN()
and NLA_POLICY_MIN_LEN() special cases of this, removing the old
types NLA_EXACT_LEN and NLA_MIN_LEN.
This allows us to save some code where both minimum and maximum
lengths are requires, currently the policy only allows maximum
(NLA_BINARY), minimum (NLA_MIN_LEN) or exact (NLA_EXACT_LEN), so
a range of lengths cannot be accepted and must be checked by the
code that consumes the attributes later.
Also, this allows advertising the correct ranges in the policy
export to userspace. Here, NLA_MIN_LEN and NLA_EXACT_LEN already
were special cases of NLA_BINARY with min and min/max length
respectively.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-08-18 11:17:33 +03:00
|
|
|
}
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
break;
|
|
|
|
|
case NLA_FLAG:
|
|
|
|
|
type = NL_ATTR_TYPE_FLAG;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (nla_put_u32(skb, NL_POLICY_TYPE_ATTR_TYPE, type))
|
|
|
|
|
goto nla_put_failure;
|
|
|
|
|
|
|
|
|
|
nla_nest_end(skb, attr);
|
2020-10-08 13:45:17 +03:00
|
|
|
WARN_ON(attr->nla_len > estimate);
|
|
|
|
|
|
2020-10-08 13:45:16 +03:00
|
|
|
return 0;
|
|
|
|
|
nla_put_failure:
|
|
|
|
|
nla_nest_cancel(skb, attr);
|
|
|
|
|
return -ENOBUFS;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-08 13:45:17 +03:00
|
|
|
/**
|
|
|
|
|
* netlink_policy_dump_write_attr - write a given attribute policy
|
|
|
|
|
* @skb: the message skb to write to
|
|
|
|
|
* @pt: the attribute's policy
|
|
|
|
|
* @nestattr: the nested attribute ID to use
|
|
|
|
|
*
|
|
|
|
|
* Returns: 0 on success, an error code otherwise; -%ENODATA is
|
|
|
|
|
* special, indicating that there's no policy data and
|
|
|
|
|
* the attribute is generally rejected.
|
|
|
|
|
*/
|
|
|
|
|
int netlink_policy_dump_write_attr(struct sk_buff *skb,
|
|
|
|
|
const struct nla_policy *pt,
|
|
|
|
|
int nestattr)
|
|
|
|
|
{
|
|
|
|
|
return __netlink_policy_dump_write_attr(NULL, skb, pt, nestattr);
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-08 13:45:16 +03:00
|
|
|
/**
|
|
|
|
|
* netlink_policy_dump_write - write current policy dump attributes
|
|
|
|
|
* @skb: the message skb to write to
|
|
|
|
|
* @state: the policy dump state
|
|
|
|
|
*
|
|
|
|
|
* Returns: 0 on success, an error code otherwise
|
|
|
|
|
*/
|
|
|
|
|
int netlink_policy_dump_write(struct sk_buff *skb,
|
|
|
|
|
struct netlink_policy_dump_state *state)
|
|
|
|
|
{
|
|
|
|
|
const struct nla_policy *pt;
|
|
|
|
|
struct nlattr *policy;
|
|
|
|
|
bool again;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
send_attribute:
|
|
|
|
|
again = false;
|
|
|
|
|
|
|
|
|
|
pt = &state->policies[state->policy_idx].policy[state->attr_idx];
|
|
|
|
|
|
|
|
|
|
policy = nla_nest_start(skb, state->policy_idx);
|
|
|
|
|
if (!policy)
|
|
|
|
|
return -ENOBUFS;
|
|
|
|
|
|
|
|
|
|
err = __netlink_policy_dump_write_attr(state, skb, pt, state->attr_idx);
|
|
|
|
|
if (err == -ENODATA) {
|
|
|
|
|
nla_nest_cancel(skb, policy);
|
|
|
|
|
again = true;
|
|
|
|
|
goto next;
|
|
|
|
|
} else if (err) {
|
|
|
|
|
goto nla_put_failure;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* finish and move state to next attribute */
|
netlink: add infrastructure to expose policies to userspace
Add, and use in generic netlink, helpers to dump out a netlink
policy to userspace, including all the range validation data,
nested policies etc.
This lets userspace discover what the kernel understands.
For families/commands other than generic netlink, the helpers
need to be used directly in an appropriate command, or we can
add some infrastructure (a new netlink family) that those can
register their policies with for introspection. I'm not that
familiar with non-generic netlink, so that's left out for now.
The data exposed to userspace also includes min and max length
for binary/string data, I've done that instead of letting the
userspace tools figure out whether min/max is intended based
on the type so that we can extend this later in the kernel, we
might want to just use the range data for example.
Because of this, I opted to not directly expose the NLA_*
values, even if some of them are already exposed via BPF, as
with min/max length we don't need to have different types here
for NLA_BINARY/NLA_MIN_LEN/NLA_EXACT_LEN, we just make them
all NL_ATTR_TYPE_BINARY with min/max length optionally set.
Similarly, we don't really need NLA_MSECS, and perhaps can
remove it in the future - but not if we encode it into the
userspace API now. It gets mapped to NL_ATTR_TYPE_U64 here.
Note that the exposing here corresponds to the strict policy
interpretation, and NLA_UNSPEC items are omitted entirely.
To get those, change them to NLA_MIN_LEN which behaves in
exactly the same way, but is exposed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-30 23:13:12 +03:00
|
|
|
nla_nest_end(skb, policy);
|
|
|
|
|
|
|
|
|
|
next:
|
|
|
|
|
state->attr_idx += 1;
|
|
|
|
|
if (state->attr_idx > state->policies[state->policy_idx].maxtype) {
|
|
|
|
|
state->attr_idx = 0;
|
|
|
|
|
state->policy_idx++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (again) {
|
|
|
|
|
if (netlink_policy_dump_finished(state))
|
|
|
|
|
return -ENODATA;
|
|
|
|
|
goto send_attribute;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
nla_put_failure:
|
|
|
|
|
nla_nest_cancel(skb, policy);
|
|
|
|
|
return -ENOBUFS;
|
|
|
|
|
}
|
2020-10-02 10:46:04 +03:00
|
|
|
|
2020-10-03 11:44:43 +03:00
|
|
|
/**
|
|
|
|
|
* netlink_policy_dump_free - free policy dump state
|
|
|
|
|
* @state: the policy dump state to free
|
|
|
|
|
*
|
|
|
|
|
* Call this from the done() method to ensure dump state is freed.
|
|
|
|
|
*/
|
2020-10-03 00:49:55 +03:00
|
|
|
void netlink_policy_dump_free(struct netlink_policy_dump_state *state)
|
2020-10-02 10:46:04 +03:00
|
|
|
{
|
|
|
|
|
kfree(state);
|
|
|
|
|
}
|
