74ae3f3e33
This is the culmination of about a week of work from three developers to fix a number of functional and security issues. This patch consists of work done by the following folks: - Jason A. Donenfeld <Jason@zx2c4.com> - Matt Dunwoodie <ncon@noconroy.net> - Kyle Evans <kevans@FreeBSD.org> Notable changes include: - Packets are now correctly staged for processing once the handshake has completed, resulting in less packet loss in the interim. - Various race conditions have been resolved, particularly w.r.t. socket and packet lifetime (panics) - Various tests have been added to assure correct functionality and tooling conformance - Many security issues have been addressed - if_wg now maintains jail-friendly semantics: sockets are created in the interface's home vnet so that it can act as the sole network connection for a jail - if_wg no longer fails to remove peer allowed-ips of 0.0.0.0/0 - if_wg now exports via ioctl a format that is future proof and complete. It is additionally supported by the upstream wireguard-tools (which we plan to merge in to base soon) - if_wg now conforms to the WireGuard protocol and is more closely aligned with security auditing guidelines Note that the driver has been rebased away from using iflib. iflib poses a number of challenges for a cloned device trying to operate in a vnet that are non-trivial to solve and adds complexity to the implementation for little gain. The crypto implementation that was previously added to the tree was a super complex integration of what previously appeared in an old out of tree Linux module, which has been reduced to crypto.c containing simple boring reference implementations. This is part of a near-to-mid term goal to work with FreeBSD kernel crypto folks and take advantage of or improve accelerated crypto already offered elsewhere. There's additional test suite effort underway out-of-tree taking advantage of the aforementioned jail-friendly semantics to test a number of real-world topologies, based on netns.sh. Also note that this is still a work in progress; work going further will be much smaller in nature. MFC after: 1 month (maybe) |
||
|---|---|---|
| .. | ||
| BSD.debug.dist | ||
| BSD.include.dist | ||
| BSD.lib32.dist | ||
| BSD.libsoft.dist | ||
| BSD.release.dist | ||
| BSD.root.dist | ||
| BSD.sendmail.dist | ||
| BSD.tests.dist | ||
| BSD.usr.dist | ||
| BSD.var.dist | ||
| Makefile | ||
| README | ||
$FreeBSD$
Note: If you modify these files, please keep hier(7) updated!
These files are used to create empty file hierarchies for building the
system into. Some notes about working with them are placed here to try
and keep them in good working order.
a) The files use 4 space indentation, and other than in the header
comments, should not contain any tabs. An indentation of 4 is
preferable to the standard indentation of 8 because the indentation
of levels in these files can become quite deep causing the line to
overflow 80 characters.
This also matches with the files generated when using the
mtree -c option, which was implemented that way for the same reason.
b) Only directories should be listed here.
c) The listing should be kept in filename sorted order.
d) Sanity checking changes to these files can be done by following
this procedure (the sed -e is ugly, but fixing mtree -c to
not emit the trailing white space would be even uglier):
mkdir /tmp/MTREE
mtree -deU -f BSD.X.dist -p /tmp/MTREE
mtree -cdin -k uname,gname,mode -p /tmp/MTREE | \
sed -e 's/ *$//' >BSD.X.new
diff -u BSD.X.dist BSD.X.new
rm -r /tmp/MTREE
Note that you will get some differences about /set lines,
and uname= gname= on certain directory areas, mainly man page
sections. This is caused by mtree not having a look ahead
mechanism for making better selections for these as it
traverses the hierarchy.
The BSD.X.new file should NOT be committed, as it will be missing
the correct header, and important keywords like ``nochange''.
Simply use the diff for a sanity check to make sure things are in
the correct order and correctly indented.
e) Further sanity checking of the system builds with DESTDIR=/someplace
are more complicated, but can often catch missing entries in these
files. I tend to run this more complete sanity check shortly after
the target date for a new release is announced.
If you want details on it bug me about it via email to
rgrimes@FreeBSD.org.