This commit also adds several #include directives in source files in
order to make the 'ofp-util.h' move possible
Signed-off-by: Ben Warren <ben@skyportsystems.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This commit also moves some bitmap macros into public header files and
adds some #include directives in soure files in order to make the
'meta-flow.h' move possible.
Signed-off-by: Ben Warren <ben@skyportsystems.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
It's pretty easy to forget to update the pointer to an ofpact when
finishing it. This commit forces the caller to pass a pointer-to-pointer
instead, and uses that to automatically update the pointer. There still
could be cases that retain other pointers into the ofpbuf, but I imagine
that this is harder to misuse.
Suggested-by: Joe Stringer <joe@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
ofpact_finish() may now reallocate the buffer it is passed, but not all
callers updated their local pointers to the current action in the
buffer. This could potentially lead to several use-after-free bugs.
Update ofpact_finish() to return the new pointer to the ofpact which is
provided, and update the calling points to ensure that their local
pointers are pointing into the correct (potentially reallocated) buffer.
Fixes: 2bd318dec242 ("ofp-actions: Make composing actions harder to screw up.")
Reported-by: William Tu <u9012063@gmail.com>
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
Add color output for flow actions for ovs-ofctl dump-flows command
utility, by inserting color markers in the functions responsible for
printing those actions.
Signed-off-by: Quentin Monnet <quentin.monnet@6wind.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Variable-length actions must have a nonzero length; if they don't,
something went wrong and we should bail out.
Suggested-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
When decoding a variable-length action, if the length of the action
exceeds the length storable in a uint16_t then something has gone
terribly wrong. Assert that this is not the case.
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
If the actions list in an incoming flow mod is long enough, and there is
a bundle() action with 3 or more slaves, then it is possible for a
reallocation to occur after placing the ofpact_bundle into the ofpacts
buffer, while slave ports into the buffer. If the memory freed by this
reallocation is then passed to another thread, then that thread may
modify the value that bundle->n_slaves points to. If this occurs quickly
enough before the main thread finishes copying all of the slaves, then
the iteration may continue beyond the originally intended number of
slaves, copying (and swapping) an undetermined number of 2-byte chunks
from the openflow message. Finally, the length of the ofpact will be
updated based on how much data was written to the buffer, which may be
significantly longer than intended.
In many cases, the freed memory may not be allocated to another thread
and be left untouched. In some milder bug cases, this will lead to
'bundle' actions using more memory than required. In more serious cases,
this length may then exceed the maximum length of an OpenFlow action,
which is then stored (truncated) into the 16-bit length field in the
ofpact header. Later execution of ofpacts_verify() would then use this
length to iterate through the ofpacts, and may dereference memory in
unintended ways, causing crashes or infinite loops by attempting to
parse/validate arbitrary data as ofpact objects.
Fix the issue by updating 'bundle' within the iteration, immediately
after (potentially) expanding the bundle.
Thanks to Jarno Rajahalme for his keen pair of eyes on finding this
issue.
VMWare-BZ: #1614715
Fixes: f25d0cf3c366 ("Introduce ofpacts, an abstraction of OpenFlow actions.")
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
One purpose of OpenFlow packet-in messages is to allow a controller to
interpose on the path of a packet through the flow tables. If, for
example, the controller needs to modify a packet in some way that the
switch doesn't directly support, the controller should be able to
program the switch to send it the packet, then modify the packet and
send it back to the switch to continue through the flow table.
That's the theory. In practice, this doesn't work with any but the
simplest flow tables. Packet-in messages simply don't include enough
context to allow the flow table traversal to continue. For example:
* Via "resubmit" actions, an Open vSwitch packet can have an
effective "call stack", but a packet-in can't describe it, and
so it would be lost.
* A packet-in can't preserve the stack used by NXAST_PUSH and
NXAST_POP actions.
* A packet-in can't preserve the OpenFlow 1.1+ action set.
* A packet-in can't preserve the state of Open vSwitch mirroring
or connection tracking.
This commit introduces a solution called "continuations". A continuation
is the state of a packet's traversal through OpenFlow flow tables. A
"controller" action with the "pause" flag, which is newly implemented in
this commit, generates a continuation and sends it to the OpenFlow
controller in a packet-in asynchronous message (only NXT_PACKET_IN2
supports continuations, so the controller must configure them with
NXT_SET_PACKET_IN_FORMAT). The controller processes the packet-in,
possibly modifying some of its data, and sends it back to the switch with
an NXT_RESUME request, which causes flow table traversal to continue. In
principle, a single packet can be paused and resumed multiple times.
Another way to look at it is:
- "pause" is an extension of the existing OFPAT_CONTROLLER
action. It sends the packet to the controller, with full
pipeline context (some of which is switch implementation
dependent, and may thus vary from switch to switch).
- A continuation is an extension of OFPT_PACKET_IN, allowing for
implementation dependent metadata.
- NXT_RESUME is an extension of OFPT_PACKET_OUT, with the
semantics that the pipeline processing is continued with the
original translation context from where it was left at the time
it was paused.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
A number of times I've looked at code and thought that it would be easier
to understand if I could write an initializer instead of
ofpbuf_use_const(). This commit adds a function for that purpose and
adapts a lot of code to use it, in the places where I thought it made
the code better.
In theory this could improve code generation since the new function can
be inlined whereas ofpbuf_use_const() isn't. But I guess that's probably
insignificant; the intent of this change is code readability.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
This makes it accept the same syntax as parse_NOTE(), so that that function
can be simplified. In an upcoming commit a second action will also be
able to take advantage of the same feature.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
An upcoming commit will have a need to parse actions incrementally, so this
change makes that easier to do.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
It does more than just update the length now, so this is a more accurate
name.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Russell Bryant <russell@ovn.org>
Until now, composing a fixed-length action with ofpact_put_<NAME>() failed
to append any padding required after the action. This commit changes that
so that these calls now add padding. This meant that the function
ofpact_pad(), which was until now required in various unintuitive places,
is no longer required, and removes it.
Variable-length actions still require calling ofpact_update_len() after
composition. I don't see a way to avoid that.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Russell Bryant <russell@ovn.org>
ofpacts_pull_openflow_instructions() should fill 'ofpacts' with a list
of OpenFlow actions and each action (including the last one) should be
padded to OFP_ACTION_ALIGN(8) bytes.
In most of the cases this is taken care of (e.g. by ofpacts_decode), but
for the Goto-Table instruction (and Clear-Actions, based on a quick code
inspection), this wasn't the case.
This caused the copy operation in recirc_unroll_actions() to read two
extra bytes after an allocated area (not a big deal, but enough to
displease the AddressSanitizer).
Signed-off-by: William Tu <u9012063@gmail.com>
Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com>
Co-authored-by: Daniele Di Proietto <diproiettod@vmware.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This function finds the mf destination field for any ofpact, returning
NULL if not applicable. It will be used by the next patch to properly
reject OpenFlow flows with conntrack actions when conntrack is
unsupported by the datapath.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
The out_port and out_group matches only looked at apply_actions
instructions, but my interpretation of the OpenFlow spec is that they
should also look inside write_actions.
This affected the output of (and in one case the correctness of) some
tests, so this updates them.
Reported-by: Gavin Remaley <gavin_remaley@selinc.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Extend OVS conntrack interface to cover NAT. New nested NAT action
may be included with a CT action. A bare NAT action only mangles
existing connections. If a NAT action with src or dst range attribute
is included, new (non-committed) connections are mangled according to
the NAT attributes.
This work extends on a branch by Thomas Graf at
https://github.com/tgraf/ovs/tree/nat.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Restrictions from embedded actions should be folded in rather than
discarded.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Joe Stringer <joestringer@nicira.com>
This patch adds support for specifying a "helper" or ALG to assist
connection tracking for protocols that consist of multiple streams.
Initially, only support for FTP is included.
Below is an example set of flows to allow FTP control connections from
port 1->2 to establish active data connections in the reverse direction:
table=0,priority=1,action=drop
table=0,arp,action=normal
table=0,in_port=1,tcp,action=ct(alg=ftp,commit),2
table=0,in_port=2,tcp,ct_state=-trk,action=ct(table=1)
table=1,in_port=2,tcp,ct_state=+trk+est,action=1
table=1,in_port=2,tcp,ct_state=+trk+rel,action=ct(commit),1
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This patch adds a new 128-bit metadata field to the connection tracking
interface. When a label is specified as part of the ct action and the
connection is committed, the value is saved with the current connection.
Subsequent ct lookups with the table specified will expose this metadata
as the "ct_label" field in the flow.
For example, to allow new TCP connections from port 1->2 and only allow
established connections from port 2->1, and to associate a label with
those connections:
table=0,priority=1,action=drop
table=0,arp,action=normal
table=0,in_port=1,tcp,action=ct(commit,exec(set_field:1->ct_label)),2
table=0,in_port=2,ct_state=-trk,tcp,action=ct(table=1)
table=1,in_port=2,ct_state=+trk,ct_label=1,tcp,action=1
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This patch adds a new 32-bit metadata field to the connection tracking
interface. When a mark is specified as part of the ct action and the
connection is committed, the value is saved with the current connection.
Subsequent ct lookups with the table specified will expose this metadata
as the "ct_mark" field in the flow.
For example, to allow new TCP connections from port 1->2 and only allow
established connections from port 2->1, and to associate a mark with those
connections:
table=0,priority=1,action=drop
table=0,arp,action=normal
table=0,in_port=1,tcp,action=ct(commit,exec(set_field:1->ct_mark)),2
table=0,in_port=2,ct_state=-trk,tcp,action=ct(table=1)
table=1,in_port=2,ct_state=+trk,ct_mark=1,tcp,action=1
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This patch adds a new action and fields to OVS that allow connection
tracking to be performed. This support works in conjunction with the
Linux kernel support merged into the Linux-4.3 development cycle.
Packets have two possible states with respect to connection tracking:
Untracked packets have not previously passed through the connection
tracker, while tracked packets have previously been through the
connection tracker. For OpenFlow pipeline processing, untracked packets
can become tracked, and they will remain tracked until the end of the
pipeline. Tracked packets cannot become untracked.
Connections can be unknown, uncommitted, or committed. Packets which are
untracked have unknown connection state. To know the connection state,
the packet must become tracked. Uncommitted connections have no
connection state stored about them, so it is only possible for the
connection tracker to identify whether they are a new connection or
whether they are invalid. Committed connections have connection state
stored beyond the lifetime of the packet, which allows later packets in
the same connection to be identified as part of the same established
connection, or related to an existing connection - for instance ICMP
error responses.
The new 'ct' action transitions the packet from "untracked" to
"tracked" by sending this flow through the connection tracker.
The following parameters are supported initally:
- "commit": When commit is executed, the connection moves from
uncommitted state to committed state. This signals that information
about the connection should be stored beyond the lifetime of the
packet within the pipeline. This allows future packets in the same
connection to be recognized as part of the same "established" (est)
connection, as well as identifying packets in the reply (rpl)
direction, or packets related to an existing connection (rel).
- "zone=[u16|NXM]": Perform connection tracking in the zone specified.
Each zone is an independent connection tracking context. When the
"commit" parameter is used, the connection will only be committed in
the specified zone, and not in other zones. This is 0 by default.
- "table=NUMBER": Fork pipeline processing in two. The original instance
of the packet will continue processing the current actions list as an
untracked packet. An additional instance of the packet will be sent to
the connection tracker, which will be re-injected into the OpenFlow
pipeline to resume processing in the specified table, with the
ct_state and other ct match fields set. If the table is not specified,
then the packet is submitted to the connection tracker, but the
pipeline does not fork and the ct match fields are not populated. It
is strongly recommended to specify a table later than the current
table to prevent loops.
When the "table" option is used, the packet that continues processing in
the specified table will have the ct_state populated. The ct_state may
have any of the following flags set:
- Tracked (trk): Connection tracking has occurred.
- Reply (rpl): The flow is in the reply direction.
- Invalid (inv): The connection tracker couldn't identify the connection.
- New (new): This is the beginning of a new connection.
- Established (est): This is part of an already existing connection.
- Related (rel): This connection is related to an existing connection.
For more information, consult the ovs-ofctl(8) man pages.
Below is a simple example flow table to allow outbound TCP traffic from
port 1 and drop traffic from port 2 that was not initiated by port 1:
table=0,priority=1,action=drop
table=0,arp,action=normal
table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2
table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1)
table=1,in_port=2,ct_state=+trk+est,tcp,action=1
table=1,in_port=2,ct_state=+trk+new,tcp,action=drop
Based on original design by Justin Pettit, contributions from Thomas
Graf and Daniele Di Proietto.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
A future patch will make use of this version parameter to pass nested
attributes. Prepare for that by adding the parameter as an unused
variable for the existing functions.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Previously, reg_load would only understand 64-bit values passed to it.
This patch extends the parsing to handle larger fields, if they are
specified in hexadecimal. Internally they are stored as a single action,
but they are converted into multiple 64-bit modifications when
re-serialised.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Combine the codepaths for splitting "set_field" and "reg_load" string
arguments into the value, key, and delimiter component. The only
user-visible change is that reg_load will now provide a more meaningful
error message when parsing input such as "reg_load:1".
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The next patch will introduce nested actions with special restrictions.
Refactor the action verification to allow ofpacts_verify() to identify
nesting so that these restrictions may be applied.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Define struct eth_addr and use it instead of a uint8_t array for all
ethernet addresses in OVS userspace. The struct is always the right
size, and it can be assigned without an explicit memcpy, which makes
code more readable.
"struct eth_addr" is a good type name for this as many utility
functions are already named accordingly.
struct eth_addr can be accessed as bytes as well as ovs_be16's, which
makes the struct 16-bit aligned. All use seems to be 16-bit aligned,
so some algorithms on the ethernet addresses can be made a bit more
efficient making use of this fact.
As the struct fits into a register (in 64-bit systems) we pass it by
value when possible.
This patch also changes the few uses of Linux specific ETH_ALEN to
OVS's own ETH_ADDR_LEN, and removes the OFP_ETH_ALEN, as it is no
longer needed.
This work stemmed from a desire to make all struct flow members
assignable for unrelated exploration purposes. However, I think this
might be a nice code readability improvement by itself.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Currently, when using an OpenFlow 1.0 connection to encode a
tunnel metadata set field action, a series of NXAST_REG_LOADs
are emitted. The result is something like this:
actions=load:0xa->NXM_NX_TUN_METADATA0[0..63],load:0->
NXM_NX_TUN_METADATA0[64..127],load:0->NXM_NX_TUN_METADATA0[128..191],
load:0->NXM_NX_TUN_METADATA0[192..255],load:0->NXM_NX_TUN_METADATA0
[256..319],load:0->NXM_NX_TUN_METADATA0[320..383],load:0->
NXM_NX_TUN_METADATA0[384..447],load:0->NXM_NX_TUN_METADATA0[448..511],
load:0->NXM_NX_TUN_METADATA0[512..575],load:0->NXM_NX_TUN_METADATA0
[576..639],load:0->NXM_NX_TUN_METADATA0[640..703],load:0->
NXM_NX_TUN_METADATA0[704..767],load:0->NXM_NX_TUN_METADATA0[768..831],
load:0->NXM_NX_TUN_METADATA0[832..895],load:0->NXM_NX_TUN_METADATA0
[896..959],load:0->NXM_NX_TUN_METADATA0[960..991]
This happens because tunnel metadata is seen as a maximum size field
and so many loads need to be emitted to cover the entire thing. Besides
being ugly (this shows up when using ovs-ofctl in the default
configuration), it exposes the internal size of the field. While this
shouldn't be an issue since specific protocol fields (such as Geneve
options) have fixed max sizes even if the OVS implementation is extended,
it's still not a great idea.
If we instead use NXAST_REG_LOAD2 in cases where there isn't a suitable
OpenFlow alternative, both problems are avoided:
actions=set_field:0xa->tun_metadata0
This prefers NXAST_REG_LOAD2 for variable length fields since they would
all generally have the same problems. In addition, since the concept of
this type of field is fairly new, there are no backwards compatibility
issues.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
It isn't otherwise useful and in fact hurts performance so it's disabled
without --enable-dummy.
An upcoming commit will make use of this.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
This is implied by the list of ports that are valid for output in the
various versions of the OpenFlow specification.
Found by OFTest.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
It doesn't make sense to mix "conjunction" actions with most other kinds
of actions. That's because flows with "conjunction" actions aren't ever
actually executed, so any actions mixed up with them would never do
anything useful. "note" actions are a little different because they never
do anything useful anyway: they are just there to allow a controller to
annotate flows. It makes as much sense to annotate a flow with
"conjunction" actions as it does to annotate any other flow, so this
commit makes this possible.
Requested-by: Soner Sevinc <sevincs@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
Each rule is now added or deleted in a specific tables version. Flow
tables are versioned with a monotonically increasing 64-bit integer,
where positive values are valid version numbers.
Rule modifications are implemented as an insertion of a new rule and a
deletion of the old rule, both taking place in the same tables
version. Since concurrent lookups may use different versions, both
the old and new rule must be available for lookups at the same time.
The ofproto provider interface is changed to accomodate the above. As
rule's actions need not be modified any more, we no longer need
'rule_premodify_actions', nor 'rule_modify_actions'. 'rule_insert'
now takes a pointer to the old rule and adds a flag that tells whether
the old stats should be forwarded to the new rule or not (this
replaces the 'reset_counters' flag of the now removed
'rule_modify_actions').
Versioning all flow table changes has the side effect of making
learned flows visible for future lookups only. I.e., the upcall that
executes the learn action, will not see the newly learned action in
it's classifier lookups. Only upcalls that start executing after the
new flow was added will match on it.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Found by LLVM scan-build.
Reported-by: Kevin Lo <kevlo@FreeBSD.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
xlate_actions() now considers an optional recirculation context (via
'xin') and restores OpenFlow pipeline metadata (registers, 'metadata',
etc.) based on it. The recirculation context may contain an action
set and stack to be restored and further actions to be executed upon
recirculation. It also contains a table_id number to be used for rule
lookup in cases where no post-recirculation actions are used.
The translation context internal metadata is restored using a new
internal action: UNROLL_XLATE action stores the translation context
data visible to OpenFlow controllers via PACKET_IN messages. This
includes the current table number and the current rule cookie.
UNROLL_XLATE actions are inserted only when the remaining actions may
generate PACKET_IN messages.
These changes allow the post-MPLS recirculation to properly continue
with the pipeline metadata that existed at the time of recirculation.
The internal table is still consulted for bonds.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
ofpbuf was complicated due to its wide usage across all
layers of OVS, Now we have introduced independent dp_packet
which can be used for datapath packet, we can simplify ofpbuf.
Following patch removes DPDK mbuf and access API of ofpbuf
members.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
A "conjunctive match" allows higher-level matches in the flow table, such
as set membership matches, without causing a cross-product explosion for
multidimensional matches. Please refer to the documentation that this
commit adds to ovs-ofctl(8) for a better explanation, including an example.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
A new function vlog_insert_module() is introduced to avoid using
list_insert() from the vlog.h header.
Signed-off-by: Thomas Graf <tgraf@noironetworks.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The following macros are renamed to avoid conflicts with other headers:
* WARN_UNUSED_RESULT to OVS_WARN_UNUSED_RESULT
* PRINTF_FORMAT to OVS_PRINTF_FORMAT
* NO_RETURN to OVS_NO_RETURN
Signed-off-by: Thomas Graf <tgraf@noironetworks.com>
Acked-by: Ben Pfaff <blp@nicira.com>
