From: Eyal Birger <redacted>
The following patchset introduces a new tc ematch for matching IPSec
traffic from a tc context.
This allows early classification as well as mirroning/redirecting IPSec
traffic based on decapsulation criteria.
The matching functionality is based on the netfilter xt_policy match, and
shares code and data structures.
Eyal Birger (2):
net: netfilter: export xt_policy match_policy_in() as
xt_policy_match_policy_in()
net: sched: add xfrm policy ematch
include/net/netfilter/xt_policy.h | 12 ++++
include/uapi/linux/pkt_cls.h | 3 +-
net/netfilter/xt_policy.c | 18 +++---
net/sched/Kconfig | 10 ++++
net/sched/Makefile | 1 +
net/sched/em_policy.c | 117 ++++++++++++++++++++++++++++++++++++++
6 files changed, 152 insertions(+), 9 deletions(-)
create mode 100644 include/net/netfilter/xt_policy.h
create mode 100644 net/sched/em_policy.c
--
2.7.4
From: Eyal Birger <redacted>
Expose this functionality so it could be usable from a tc classifier.
The rename of match_policy_out() is done for consistency though it is not
exported.
Signed-off-by: Eyal Birger <redacted>
---
include/net/netfilter/xt_policy.h | 12 ++++++++++++
net/netfilter/xt_policy.c | 18 ++++++++++--------
2 files changed, 22 insertions(+), 8 deletions(-)
create mode 100644 include/net/netfilter/xt_policy.h
From: Eyal Birger <redacted>
Allows classification based on the incoming IPSec policy used during
decpsulation.
This allows similar matching capabilities to those provided by netfilter
xt_policy module, and uses the same data strcuture - but from a tc entry
point.
Signed-off-by: Eyal Birger <redacted>
---
include/uapi/linux/pkt_cls.h | 3 +-
net/sched/Kconfig | 10 ++++
net/sched/Makefile | 1 +
net/sched/em_policy.c | 117 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 130 insertions(+), 1 deletion(-)
create mode 100644 net/sched/em_policy.c
@@ -0,0 +1,117 @@+/*+*net/sched/em_policy.cIPSecPolicyEmatch+*+*(c)2018EyalBirger<eyal.birger@gmail.com>+*+*Partstakenfromnetfilter/xt_policy.h:+*Copyright(c)2004,2005PatrickMcHardy,<kaber@trash.net>+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion+*2oftheLicense,or(atyouroption)anylaterversion.+*/++#include<linux/gfp.h>+#include<linux/module.h>+#include<linux/types.h>+#include<linux/kernel.h>+#include<linux/string.h>+#include<linux/skbuff.h>+#include<linux/netfilter.h>+#include<linux/netfilter/xt_policy.h>+#include<net/pkt_cls.h>+#include<net/netfilter/xt_policy.h>++staticintem_policy_change(structnet*net,void*data,intdata_len,+structtcf_ematch*em)+{+conststructxt_policy_info*info=(constvoid*)data;+__u16dir_flags;++if(data_len!=sizeof(*info))+return-EINVAL;++if(info->len>XT_POLICY_MAX_ELEM){+pr_info("too many policy elements\n");+return-EINVAL;+}++dir_flags=info->flags&(XT_POLICY_MATCH_IN|XT_POLICY_MATCH_OUT);+if(dir_flags!=XT_POLICY_MATCH_IN){+pr_info("Only incoming policy can be matched\n");+return-EINVAL;+}++em->datalen=sizeof(*info);+em->data=(unsignedlong)kmemdup(data,em->datalen,GFP_KERNEL);+if(!em->data)+return-ENOMEM;++return0;+}++staticvoidem_policy_destroy(structtcf_ematch*em)+{+conststructxt_policy_info*info=(constvoid*)em->data;++if(!info)+return;++kfree((void*)em->data);+}++staticintem_policy_match(structsk_buff*skb,structtcf_ematch*em,+structtcf_pkt_info*info)+{+conststructxt_policy_info*pol=(constvoid*)em->data;+unsignedshortpf;+intret;++switch(tc_skb_protocol(skb)){+casehtons(ETH_P_IP):+pf=NFPROTO_IPV4;+break;+casehtons(ETH_P_IPV6):+pf=NFPROTO_IPV6;+break;+default:+returnfalse;+}++ret=xt_policy_match_policy_in(skb,pol,pf);+if(ret<0)+ret=pol->flags&XT_POLICY_MATCH_NONE?true:false;+elseif(pol->flags&XT_POLICY_MATCH_NONE)+ret=false;++returnret;+}++staticstructtcf_ematch_opsem_policy_ops={+.kind=TCF_EM_POLICY,+.change=em_policy_change,+.destroy=em_policy_destroy,+.match=em_policy_match,+.owner=THIS_MODULE,+.link=LIST_HEAD_INIT(em_policy_ops.link)+};++staticint__initinit_em_policy(void)+{+returntcf_em_register(&em_policy_ops);+}++staticvoid__exitexit_em_policy(void)+{+tcf_em_unregister(&em_policy_ops);+}++MODULE_LICENSE("GPL");+MODULE_AUTHOR("Eyal Birger <eyal.birger@gmail.com>");+MODULE_DESCRIPTION("TC extended match for IPSec policies");++module_init(init_em_policy);+module_exit(exit_em_policy);++MODULE_ALIAS_TCF_EMATCH(TCF_EM_POLICY);
If you just want to call xt_policy_match from tc, then you could use
tc ipt infrastructure instead.
Thanks for the suggestion -
Are you referring to act_ipt? it looks like it allows calling targets;
I couldn't
find a classifier calling a netfilter matcher.
Eyal.
If you just want to call xt_policy_match from tc, then you could use
tc ipt infrastructure instead.
Thanks for the suggestion -
Are you referring to act_ipt? it looks like it allows calling targets;
I couldn't find a classifier calling a netfilter matcher.
Then, I'd suggest you extend that infrastructure to alllow to call
matches, so we reduce the number of interdepencies between different
subsystems.
If you just want to call xt_policy_match from tc, then you could use
tc ipt infrastructure instead.
Thanks for the suggestion -
Are you referring to act_ipt? it looks like it allows calling targets;
I couldn't find a classifier calling a netfilter matcher.
Then, I'd suggest you extend that infrastructure to alllow to call
matches, so we reduce the number of interdepencies between different
subsystems.
This appears very versatile. though in this case the use of the xtables code and
structures was done in order to avoid introducing new uapi structures
and supporting
match code, not necessarily to expose the full capabilities of extended matches,
similar in spirit to what was done in the em_ipset ematch.
Perhaps in order to avoid the direct export of xt_policy code, I could call
xt_request_find_match() from the em_policy module, requesting the
xt_policy match?
this way api exposure is minimized while not overly complicating the
scope of this feature.
What do you think?
Eyal.
If you just want to call xt_policy_match from tc, then you could use
tc ipt infrastructure instead.
Thanks for the suggestion -
Are you referring to act_ipt? it looks like it allows calling targets;
I couldn't find a classifier calling a netfilter matcher.
Then, I'd suggest you extend that infrastructure to alllow to call
matches, so we reduce the number of interdepencies between different
subsystems.
This appears very versatile. though in this case the use of the xtables code and
structures was done in order to avoid introducing new uapi structures
and supporting
match code, not necessarily to expose the full capabilities of extended matches,
similar in spirit to what was done in the em_ipset ematch.
Perhaps in order to avoid the direct export of xt_policy code, I could call
xt_request_find_match() from the em_policy module, requesting the
xt_policy match?
this way api exposure is minimized while not overly complicating the
scope of this feature.
What do you think?
That would look better indeed.
But once you call xt_request_find_match() from there, how far is to
allow any arbitrary match? I think you only have to specify the match
name, family and the binary layout structure that represents
xt_policy, right?
I'm telling this, because I think it would be fair enough to me if you
add the generic infrastructure to the kernel to allow arbitrary load
of xt matches, and then from userspace you just add the code to
support this which is what you need.
Probably someone else - not you - may follow up later on to generalize
the userspace codebase to support other matches, by when that happens,
the right bits will be in the kernel already.
If you just want to call xt_policy_match from tc, then you could use
tc ipt infrastructure instead.
Thanks for the suggestion -
Are you referring to act_ipt? it looks like it allows calling targets;
I couldn't find a classifier calling a netfilter matcher.
Then, I'd suggest you extend that infrastructure to alllow to call
matches, so we reduce the number of interdepencies between different
subsystems.
This appears very versatile. though in this case the use of the xtables code and
structures was done in order to avoid introducing new uapi structures
and supporting
match code, not necessarily to expose the full capabilities of extended matches,
similar in spirit to what was done in the em_ipset ematch.
Perhaps in order to avoid the direct export of xt_policy code, I could call
xt_request_find_match() from the em_policy module, requesting the
xt_policy match?
this way api exposure is minimized while not overly complicating the
scope of this feature.
What do you think?
That would look better indeed.
But once you call xt_request_find_match() from there, how far is to
allow any arbitrary match? I think you only have to specify the match
name, family and the binary layout structure that represents
xt_policy, right?
I don't think that should be a problem. I'd need to pass the protocol onto
the ematches .change() callbacks and get the appropriate match from there.
I'm telling this, because I think it would be fair enough to me if you
add the generic infrastructure to the kernel to allow arbitrary load
of xt matches, and then from userspace you just add the code to
support this which is what you need.
Probably someone else - not you - may follow up later on to generalize
the userspace codebase to support other matches, by when that happens,
the right bits will be in the kernel already.
I'm fine with submitting the more generic infrastructure.
Will follow up with a new series.
Thanks again!
Eyal.
Thanks Cong! I later realized I could use the default ematch destructor,
so this function could be removed entirely. However, as I plan to resubmit this
as a more generic ematch without a direct netfilter dependency, this
code will change significantly.
Thanks again,
Eyal.
If you just want to call xt_policy_match from tc, then you
could use tc ipt infrastructure instead.
Thanks for the suggestion -
Are you referring to act_ipt? it looks like it allows calling
targets; I couldn't find a classifier calling a netfilter
matcher.
Then, I'd suggest you extend that infrastructure to alllow to
call matches, so we reduce the number of interdepencies between
different subsystems.
This appears very versatile. though in this case the use of the
xtables code and structures was done in order to avoid introducing
new uapi structures and supporting
match code, not necessarily to expose the full capabilities of
extended matches, similar in spirit to what was done in the
em_ipset ematch.
Perhaps in order to avoid the direct export of xt_policy code, I
could call xt_request_find_match() from the em_policy module,
requesting the xt_policy match?
this way api exposure is minimized while not overly complicating
the scope of this feature.
What do you think?
That would look better indeed.
But once you call xt_request_find_match() from there, how far is to
allow any arbitrary match? I think you only have to specify the
match name, family and the binary layout structure that represents
xt_policy, right?
I don't think that should be a problem. I'd need to pass the protocol
onto the ematches .change() callbacks and get the appropriate match
from there.
quoted
I'm telling this, because I think it would be fair enough to me if
you add the generic infrastructure to the kernel to allow arbitrary
load of xt matches, and then from userspace you just add the code to
support this which is what you need.
Probably someone else - not you - may follow up later on to
generalize the userspace codebase to support other matches, by when
that happens, the right bits will be in the kernel already.
I'm fine with submitting the more generic infrastructure.
Will follow up with a new series.
Following up on this thread, I think this feature would better be
implemented utilizing xt_policy from tc instead of supporting arbitrary
xt matches.
Feedback on the generic framework ([1], [2]) revolved around the ability
to create the skb environment for running matches accessing the
skb->data.
My concern is that it would be difficult to maintain the correct
environment for any xt match, whereas it is simple to create a
designated ematch for a specific xt match - as done for ipset - which
can validate the necessary prerequisites for that xt match.
It is also simple to dynamically fetch the xt_policy match function
using xt_request_find_match() as suggested in the em_ipt submittion.
I'd very much appreciate your feedback.
Thanks,
Eyal.
[1] https://patchwork.ozlabs.org/patch/864683/
[2] https://patchwork.ozlabs.org/patch/866490/
If you just want to call xt_policy_match from tc, then you
could use tc ipt infrastructure instead.
Thanks for the suggestion -
Are you referring to act_ipt? it looks like it allows calling
targets; I couldn't find a classifier calling a netfilter
matcher.
Then, I'd suggest you extend that infrastructure to alllow to
call matches, so we reduce the number of interdepencies between
different subsystems.
This appears very versatile. though in this case the use of the
xtables code and structures was done in order to avoid introducing
new uapi structures and supporting
match code, not necessarily to expose the full capabilities of
extended matches, similar in spirit to what was done in the
em_ipset ematch.
Perhaps in order to avoid the direct export of xt_policy code, I
could call xt_request_find_match() from the em_policy module,
requesting the xt_policy match?
this way api exposure is minimized while not overly complicating
the scope of this feature.
What do you think?
That would look better indeed.
But once you call xt_request_find_match() from there, how far is to
allow any arbitrary match? I think you only have to specify the
match name, family and the binary layout structure that represents
xt_policy, right?
I don't think that should be a problem. I'd need to pass the protocol
onto the ematches .change() callbacks and get the appropriate match
from there.
quoted
I'm telling this, because I think it would be fair enough to me if
you add the generic infrastructure to the kernel to allow arbitrary
load of xt matches, and then from userspace you just add the code to
support this which is what you need.
Probably someone else - not you - may follow up later on to
generalize the userspace codebase to support other matches, by when
that happens, the right bits will be in the kernel already.
I'm fine with submitting the more generic infrastructure.
Will follow up with a new series.
Following up on this thread, I think this feature would better be
implemented utilizing xt_policy from tc instead of supporting arbitrary
xt matches.
Feedback on the generic framework ([1], [2]) revolved around the ability
to create the skb environment for running matches accessing the
skb->data.
I think conclusion was that we're all fine. At ingress this turns into
noop and at egress there's no skb sharing at all. Anyway, see below.
My concern is that it would be difficult to maintain the correct
environment for any xt match, whereas it is simple to create a
designated ematch for a specific xt match - as done for ipset - which
can validate the necessary prerequisites for that xt match.
Then, artificially restrict this to work for xt_policy only. But please,
no new exported symbols to achieve this given you can do this with the
existing exported symbols. I mean no direct symbol dependencies with
xt_policy.
I'm fine if you just want to expose the policy match via tc, instead of
a generic ipt match infrastructure as long as you use the existing
exported symbols.
It is also simple to dynamically fetch the xt_policy match function
using xt_request_find_match() as suggested in the em_ipt submittion.
Exactly, you can use xt_request_find_match().
Thanks!
If you just want to call xt_policy_match from tc, then you
could use tc ipt infrastructure instead.
Thanks for the suggestion -
Are you referring to act_ipt? it looks like it allows
calling targets; I couldn't find a classifier calling a
netfilter matcher.
Then, I'd suggest you extend that infrastructure to alllow to
call matches, so we reduce the number of interdepencies
between different subsystems.
This appears very versatile. though in this case the use of the
xtables code and structures was done in order to avoid
introducing new uapi structures and supporting
match code, not necessarily to expose the full capabilities of
extended matches, similar in spirit to what was done in the
em_ipset ematch.
Perhaps in order to avoid the direct export of xt_policy code,
I could call xt_request_find_match() from the em_policy module,
requesting the xt_policy match?
this way api exposure is minimized while not overly
complicating the scope of this feature.
What do you think?
That would look better indeed.
But once you call xt_request_find_match() from there, how far
is to allow any arbitrary match? I think you only have to
specify the match name, family and the binary layout structure
that represents xt_policy, right?
I don't think that should be a problem. I'd need to pass the
protocol onto the ematches .change() callbacks and get the
appropriate match from there.
quoted
I'm telling this, because I think it would be fair enough to me
if you add the generic infrastructure to the kernel to allow
arbitrary load of xt matches, and then from userspace you just
add the code to support this which is what you need.
Probably someone else - not you - may follow up later on to
generalize the userspace codebase to support other matches, by
when that happens, the right bits will be in the kernel
already.
I'm fine with submitting the more generic infrastructure.
Will follow up with a new series.
Following up on this thread, I think this feature would better be
implemented utilizing xt_policy from tc instead of supporting
arbitrary xt matches.
Feedback on the generic framework ([1], [2]) revolved around the
ability to create the skb environment for running matches accessing
the skb->data.
I think conclusion was that we're all fine. At ingress this turns into
noop and at egress there's no skb sharing at all. Anyway, see below.
quoted
My concern is that it would be difficult to maintain the correct
environment for any xt match, whereas it is simple to create a
designated ematch for a specific xt match - as done for ipset -
which can validate the necessary prerequisites for that xt match.
Then, artificially restrict this to work for xt_policy only. But
please, no new exported symbols to achieve this given you can do this
with the existing exported symbols. I mean no direct symbol
dependencies with xt_policy.
I'm fine if you just want to expose the policy match via tc, instead
of a generic ipt match infrastructure as long as you use the existing
exported symbols.
New submitted version does not expose new netfilter symbols.
Thanks for your help!
Eyal.