In the time these have lingered in my tree, we've started to drop the
__FBSDID tags. Make sure we're using SPDX tags (and the correct one)
as well.
Reported by: mhorne
This macro has not been in use since commit "inline atomics and allow tied
modules to inline locks" (r335873, f4b3640475).
Reviewed by: markj, kib, emaste, imp
MFC after: 5 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48061
grant_supplementary_group_from_flags() had been used in previous
versions of the recent changes, but recently has not been needed
anymore. It has been kept around just in case deliberately, by analogy
with grant_primary_group_from_flags() (this one still being used).
Some limited support for later multi-die SoC is included, but not at all
tested and not expected to be functional yet. kevans needs to finish
getting his serial boards constructed, as the beefiest AS machine that
actually has multiple die to support in his fleet is currently a
dedicated serial console.
Reviewed by: andrew
Co-authored-by: Andrew Turner <andrew@FreeBSD.org>
Co-authored-by: Mike Karels <karels@FreeBSD.org>
Differential Revision: https://reviews.freebsd.org/D48079
Ensure it's disarmed upon attach, provide basic reset functionality.
Register definitions/usage obtained from OpenBSD.
Reviewed by: ray
Differential Revision: https://reviews.freebsd.org/D39824
Add reset controller driver for Eswin EIC7700.
This one has two reset cells in FDT, which is unusual, so provide a
custom hwreset_map method.
Tested on SiFive Premier P550.
Reviewed by: mhorne, jrtc27
Differential Revision: https://reviews.freebsd.org/D47853
Eswin EIC7700 has non-coherent DMAs but predate the standard RISC-V Zicbom
extension, so we need to use the SiFive CCache controller for non-standard
cache management operations.
Tested on SiFive Premier P550.
Reviewed by: mhorne, jrtc27
Differential Revision: https://reviews.freebsd.org/D47831
Check if RISC-V SSTC is available and advertise to the guest.
This is needed for Eswin EIC7700 that does not include SSTC.
As we don't have a mechanism for reporting extension presence
from the kernel to userspace, then use vm_cap_type for now.
Reviewed by: mhorne, markj
Differential Revision: https://reviews.freebsd.org/D48058
For IPv4 it's valid for a UDP checksum to be 0 (i.e. no checksum). This isn't
the case for IPv6, so if we translate a UDP packet from IPv4 to IPv6 we need to
ensure that the checksum is calculated.
Add a test case to verify this. Rework the server jail so it can listen for TCP
and UDP packets at the same time.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Pass the new address family rather than the incoming one. In most (i.e. all but
nat64) that's the same, but for nat64 we want the new address family instead.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Apply the fixes from c6f1116357 and b8ef285f6c to IPv6 as well.
Ensure that when dummynet re-injects it does so in the correct direction, and
uses the correct dummynet pipes.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Tables can only be used as a redirspec (i.e. in pf_map_addr()) in round-robin mode.
Enforce this for af-to tables as well.
Add a test case to verify.
Sponsored by: Rubicon Communications, LLC ("Netgate")
We do multiple lookups during the nat64 process, some of which will fail due
to address family mismatches. Do not reset the lookup offset so we actually use
different addresses from the table.
Sponsored by: Rubicon Communications, LLC ("Netgate")
This isn't expected to work, for obvious reasons, but we also expect to not
panic doing this. Exercise this special case.
Sponsored by: Rubicon Communications, LLC ("Netgate")
When translating packets from one address family to another, pass the
TOS/Traffic Class field of the original packet. Discussed with mikeb@
Obtained from: OpenBSD, jca <jca@openbsd.org>, fd92f2bb4f
Sponsored by: Rubicon Communications, LLC ("Netgate")
When we reassemble IPv4 packets tag them just like we tag the IPv6 reassembled
packtes. Use this information as the basis for refragmenting the IPv6 packet.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47804
Ensure that the packet length we track in struct pf_pdesc matches the
reassembled packet size.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47803
Just as with reply-to rules we don't know what interface we will send this out
of until we create the state. Create new nat64 rules as floating, but bind them
to the appropriate interface on the first pf_route(), when we do know.
Set state policy if-bound for the nat64 tests to validate this.
See also: 6460322a0
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47801
the patch was started by todd about a year ago and have been
finally finished by phessler and myself today; discussed with
and tweaks from jmc, ok sthen, henning
Obtained from: OpenBSD, mikeb <mikeb@openbsd.org>, 4d5e14dff3
Sponsored by: Rubicon Communications, LLC ("Netgate")
The general syntax is:
pass in inet from any to 192.168.1.1 af-to inet6 from 2001::1 to 2001::2
In the NAT64 case the "to" is not needed in af-to and the IP is extraced
from the IPv6 dst (assuming a /64 prefix).
Again most work by sperreault@, mikeb@ and reyk@
OK mcbride@, put it in deraadt@
Obtained from: OpenBSD, claudio <claudio@openbsd.org>, 0cde32ce3f
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47790
If we can't map ICMPv4 onto ICMPv6 or vice versa drop the packet rather than
continuing with an untranslated packet.
Sponsored by: Rubicon Communications, LLC ("Netgate")
In the NAT64 case we use pf_route(6)() to emit the translated packet. This
requires a new route lookup, so perform this, but only in the NAT64/NAT46 case.
Update the destination sockaddr to send packets to the gateway if appropriate.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47788
Now that we can NAT64 we can have states where the wire and stack address
families (and protocol) are different. Update the state export code to account
for this.
We keep exporting address family and protocol outside of the key, for backwards
compatibility. This'll return misleading information to userspace in the NAT64
case, but it's assumed that userspace will either understand NAT64 (and thus
look for them in the correct place), or not configure it.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47787
Since the IPv6 madness is not enough introduce NAT64 -- which is actually
"af-to" a generic IP version translator for pf(4).
Not everything perfect yet but lets fix these things in the tree.
Insane amount of work done by sperreault@, mikeb@ and reyk@.
Looked over by mcbride@ henning@ and myself at eurobsdcon.
OK mcbride@ and general put it in from deraadt@
Obtained from: OpenBSD, claudio <claudio@openbsd.org>, 97326e01c9
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47786
Similar to the existing in6_mask2len() function, but for IPv4. This will be used
by pf's nat64 code.
Obtained from: OpenBSD
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47785
stuff nsaddr/ndaddr/nsport/ndport (addrs/ports after NAT, used a lot while
walking the ruleset and up until state is fully set up) into pf_pdesc instead
of passing around those 4 seperately all the time, also shrinks the argument
count for a few functions that have/partialy had an insane count of arguments.
kinda preparational since we'll need them elsewhere too, soon
ok ryan jsing
Obtained from: OpenBSD, henning <henning@openbsd.org>, ccf63ac6cb
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47784
We won't follow this fully, because it involves breaking syntax changes
(removing nat/rdr rules and moving this functionality into regular rules) as
well as behaviour changes because NAT is now done after the rules evaluation,
rather than before it.
We import some related changes anyway, because it paves the way for nat64
support.
This change introduces a new pf_kpool in struct pf_krule, for nat. It is not yet
used (but will be for nat64) and renames the existing 'rpool' to 'rdr'.
Obtained from: OpenBSD, henning <henning@openbsd.org>, 0ef3d4febe
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47783
