summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* remove unused usbdi functionsjsg2021-02-242-44/+2
| | | | ok mpi@
* add support for adding and deleting mac addr entries on nvgre.dlg2021-02-241-1/+89
| | | | | | | | | | | | | | the guts of this are in the etherbridge code which i added for veb and used in bpe. there's a bit of boilerplate to make sure that the addresses used for the endpoints will work with the tunnel addresses that have been configured, but it's not too bad. again, this is hard to use because ifconfig doesnt (yet) know how to put ethernet addresses into the "add address" ioctl. these ioctls could be used for things like evpn via bgpd though. not sure if that's interesting to anyone though. it would probably be more useful on vxlan interfaces.
* remove unused xhci_cmd_evaluate_ctx()jsg2021-02-241-22/+1
| | | | ok mpi@
* syncderaadt2021-02-241-0/+1
|
* add support for adding and deleting address table entries.dlg2021-02-241-1/+52
| | | | | | | the guts of this are in the etherbridge code which i just added for veb, so this code is very minimal. it's hard to use though cos ifconfig doesnt (yet) know how to put ethernet addresses into the "add address" ioctl.
* add support for adding and deleting address table entries.dlg2021-02-243-3/+149
|
* Put obsolete aliases for hostbasedalgorithms and pubkeyacceptedalgorithmsdtucker2021-02-242-6/+6
| | | | | after their current names so that the config-dump mode finds and uses the current names. Spotted by Phil Pennock.
* typoderaadt2021-02-231-2/+2
|
* handle ifconfig veb0 flush with etherbridge_flush, like bpe and nvgredlg2021-02-231-1/+5
|
* lots more s/key types/signature algorithms/ mostly indjm2021-02-232-32/+32
| | | | | HostbasedAcceptedAlgorithms and HostKeyAlgorithms; prompted by Jakub Jelen
* Correct reference to signature algorithms as keys; from Jakub Jelendjm2021-02-231-3/+3
|
* Make this test module aware so it passes with Go 1.16tb2021-02-231-0/+4
|
* Make this test module aware so it passes with Go 1.16tb2021-02-231-0/+4
|
* Use pool to allocate tdbs.tobhe2021-02-231-3/+12
| | | | ok patrick@ bluhm@
* Move -u to alphabetically correct place in options. As spotted by jmc@lum2021-02-231-5/+5
|
* aplintc(4)kettenis2021-02-232-2/+44
|
* Add aplintc(4), a driver for the interrupt controller found onkettenis2021-02-234-3/+388
| | | | | | Apple M1 SoCs. ok patrick@
* syncderaadt2021-02-231-14/+0
|
* sparc64/clock.c: use ANSI-style function definitionscheloha2021-02-231-57/+20
| | | | | | | | While here, zap a few ARGUSED linter comments. Compile-tested by deraadt@. ok deraadt@
* Wrap by netlock the whole foreach loop which calls switch_port_detach() inmvs2021-02-231-1/+3
| | | | | | | | | switch_clone_destroy(). This fixes netlock assertion within underlay ifpromisc(). The problem was reported by hrvoje@ [1]. "why not" by deraadt@ 1. https://marc.info/?l=openbsd-bugs&m=161338077403538&w=2
* Fix m_copyback(9) prototype in DESCRIPTION section.mvs2021-02-231-3/+3
| | | | ok millert@
* previous commit mismanaged the control fdderaadt2021-02-231-2/+2
| | | | ok claudio
* Adjust pledge() and unveil() calls for proc_rsync() a bit. Since theclaudio2021-02-232-11/+3
| | | | | | mkdir was moved to the main process there is no need for access to . in the rsync process. OK job@ deraadt@
* syncderaadt2021-02-231-0/+1
|
* remove unused malloc_roundup()jsg2021-02-232-15/+2
|
* As ip_insertoptions() may prepend a mbuf, "goto bad" has to freebluhm2021-02-231-19/+11
| | | | | | the new chain. This fixes a potential memory leak in ip_output(). Also simplify a bunch of "goto done". OK kn@ mvs@
* Make more efficient clearing interrupts on all processors at boot time.aoyama2021-02-231-4/+4
| | | | | | | | | | | | | | | | Without this modification, because of the volatile qualifier, the compiler does not produce four `` = 0 '' assignments, but code equivalent to: *(volatile uint32_t *)INT_ST_MASK3 = 0; *(volatile uint32_t *)INT_ST_MASK2 = *(volatile uint32_t *)INT_ST_MASK3; *(volatile uint32_t *)INT_ST_MASK1 = *(volatile uint32_t *)INT_ST_MASK2; *(volatile uint32_t *)INT_ST_MASK0 = *(volatile uint32_t *)INT_ST_MASK1; Anders Gavare reported to Miod Vallat, and he gave me a diff.
* small adjustment of the deck chairs, no functional change.dlg2021-02-231-2/+2
|
* fix up which link flags do what.dlg2021-02-231-5/+5
| | | | | ipsec code is written, but is disabled, so the ipsec words here are still commented out for now.
* Use NULL instead of 0 in `m_nextpkt' assignment.mvs2021-02-233-7/+7
| | | | ok deraadt@ dlg@
* make a start on transparent ipsec interception, based on bridge(4).dlg2021-02-231-1/+287
| | | | | | | | | | | | | | | | | | | | | | | i found the Transparent Network Security Policy Enforcement paper by angelos and jason was useful for understanding the background and why you'd want to do this. the implementation is a little bit different to the bridge one because i've tweaked the order that pf and ipsec processing happens, depending on which direction the packet is going over the bridge. bridge always runs ipsec processing before pf, no matter which direction the packet is going. packets going into veb, pf runs first and then ipsec input processing is allowed to happen. in the outgoing direction ipsec happens first and then pf. pf runs before ipsec in the inbound direction so pf can apply policy to ipsec encapsulated packets before they hit pf. this allows you to apply policy to both the encrypted and unencrypted packets in both directions. the code is disabled for now. this is mostly because i want veb(4) to have a good chance at operating outside the netlock, and i'm pretty sure the ipsec stack isn't ready for that yet. the other reason why it's disabled is getting a test setup is effort, but i want to sleep.
* remove unused uvm_mapent_bias()jsg2021-02-231-35/+1
| | | | ok mpi@
* Move `pgo_fault' handler outside of uvm_fault_lower().mpi2021-02-231-25/+32
| | | | | | Reduce differences with NetBSD and prepare for `uobj' locking. No functionnal change. ok chris@, kettenis@
* remove some unused includesjsg2021-02-2319-2387/+0
|
* use the ipv6 dst addr to look up an ipsec tdb in bridge_ipsec in.dlg2021-02-231-2/+2
| | | | | | | | | using the ipv6 next protocol header probably doesnt work. it also probably doesnt matter cos i'm not sure anyone uses this feature in bridge. or maybe there isn't anyone who uses ipv6. both are plausible options. hahaha^Wok patrick@
* Allow the user to specify a path to the mg startup file on the command line.lum2021-02-235-14/+27
|
* use link0 to allow vlans to cross the bridge.dlg2021-02-231-2/+2
|
* implement support for the blocknonip port flag.dlg2021-02-231-2/+25
|
* add support for setting and getting bridge port flags.dlg2021-02-231-1/+48
|
* timecounting: use C99-style initialization for all timecounter structscheloha2021-02-2326-111/+238
| | | | | | | | | | | | | | | | | | The timecounter struct is large and I think it may change in the future. Changing it later will be easier if we use C99-style initialization for all timecounter structs. It also makes reading the code a bit easier. For reasons I cannot explain, switching to C99-style initialization sometimes changes the hash of the resulting object file, even though the resulting struct should be the same. So there is a binary change here, but only sometimes. No behavior should change in either case. I can't compile-test this everywhere but I have been staring at the diff for days now and I'm relatively confident this will not break compilation. Fingers crossed. ok gnezdo@
* filter MAC Bridge component Reserved addressdlg2021-02-231-1/+21
| | | | | | im considering converting ethernet addresses into uint64_ts to make comparisons (and masking) easier. im trialling it here, and it doesn't seem like the worst.
* try and use my words to explain what veb is and does.dlg2021-02-232-2/+124
| | | | ok jmatthew@
* add veb(4), a Virtual Ethernet Bridge driver.dlg2021-02-232-1/+1745
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | my intention is to replace bridge(4), but the way it works is different enough from from bridge that a name change is justified to distinguish them. it also makes it easier to commit it to the tree and work on it in parallel to bridge, and allows a window of migration. the main difference between veb(4) and bridge(4) is how they use interfaces as ports. veb takes over interfaces completely and only uses them to receive and transmit ethernet packets. bridge also use each interface as a port to the ethernet segment it's connected to, but also tries to continue supporting the use of the interface as a way to talk to the network stack on the local system. supporting the use of interfaces for both external and local communication is where most of my confusion with bridge comes from, both when i'm trying to operate it and also understand the code. changing this semantic is where most of the simplification in veb comes from compared to bridge. because veb takes over interfaces, the ethernet network set up on a veb is isolated from the host network stack. by default veb does not interact with pf or the ip (and mpls) stacks. to enable pf for ip frames going over veb ports link1 on the veb interface must be set. to have the stack interact with a veb network, vport interfaces must be created and added as ports to a veb. the vport interface driver is provided as part of veb, and is handled specially by veb. veb usually prevents the use of ports by the stack for sending an receiving packets, but that's why vports exist, so veb has special handling for them. veb already supports a lot of the other features that bridge has, including bridge rules and protected domains, but i got tired of working out of the tree and stopped implementing them. the main outstanding features is better address table management, the blocknonip flag on ports, transparent ipsec interception, and spanning tree. i may not bother with spanning tree unless someone tells me that they actually use it. the core ethernet learning bridge functionality is provided by the etherbridge code that was factored out of nvgre and bpe. veb is already (a lot) faster than bridge, and is better prepared to operate in parallel on multiple CPUs concurrently. thanks to hrvoje popovski for testing some earlier versions of this. discussed with many ok patrick@ jmatthew@
* syncderaadt2021-02-231-0/+1
|
* warn when the user specifies a ForwardAgent path that does not existdjm2021-02-231-1/+7
| | | | and exit if ExitOnForwardFailure is set; bz3264
* remove unused acpiec_lock() acpiec_unlock() functionsjsg2021-02-231-28/+1
| | | | ok kettenis@ pirofti@
* remove unused decode_hw_header() functionjsg2021-02-222-19/+2
| | | | ok krw@
* Terminate backtrace of secondary processors in ddb.kettenis2021-02-221-1/+4
| | | | From miod@
* Mark as arm64-specific.kettenis2021-02-221-2/+2
|
* Don't pass 'id' as argument to make function signature match similartobhe2021-02-223-7/+7
| | | | functions. config_setpfkey() is always called with id PROC_IKEV2.