Visual inspection: looks functionally equivalent, all options match their intend.
Test run: OK with 31 service jails (at least net_basic works ok).

The umask part looks fine.
About the dmesg_file part: from a technical point of view it is ok.,From a feature point of view, if it is not necessary, don't change it (I can't remember to have seen someone to have asked in the last 20 years about having it in another location).

I can confirm that this fixes the crash I've seen. Instead of crashing after a few minutes, it now is still humming happily with 16 minutes of uptime.

Just from reading I do not see an obvious issue now. Revision accepted (fixing the minor nit doesn't need another review IMO).

In D49976#1139747, @des wrote:

Wouldn't it be better to check at point of use rather than at point of initialization?

In D49843#1138774, @zec wrote:

In D49843#1138772, @netchild wrote:

In D49843#1138771, @zec wrote:

...

No, the host is gone as well, since the attacker has control over network connectivity.

You go to the keyboard of the host, delete the jail, and the attacker is gone.

Sounds pretty much as a very deep redefinition of the jail contract to me.

In D49843#1138771, @zec wrote:

In D49843#1138763, @ivy wrote:

In D49843#1138751, @zec wrote:

Consider an exploit in BIRD which would allow routing tables to be manipulated

consider an exploit in BIRD which would allow an attacker to run code as root.

running BIRD in a jail -> only the jail is compromised.

No, the host is gone as well, since the attacker has control over network connectivity.

In D49843#1138751, @zec wrote:

Repeating that someone might have his mind set on running BIRD in a swiss-cheese-jail is far from providing arguments on what real security benefit would this provide compared to running it in a plain system (or in a chrooted tree).

Consider an exploit in BIRD which would allow routing tables to be manipulated so that only the attacker would retain connectivity to the compromised host, while to the others the whole system would appear to be dead. What exactly does running BIRD in a service jail bring us, compared to running it in the base system?

In D49843#1137302, @lexi_le-fay.org wrote:

i have been mulling over how we can add more restrictions to svcj. i don't think "just use nullfs" is the answer here because that makes everything more complicated, but i don't yet have another proposal. i don't think this is impossible to fix in principle though.

In D49843#1137227, @markj wrote:

The svcj documentation in rc.conf.5 doesn't say anything about why one might want to run a service in a service jail, and what benefits that confers. I think that's a bug, especially given that the feature uses the term "jail" and not "container", and the former has specific connotations relating to security, at least in FreeBSD. And frankly I'm not sure what added security is obtained from having a privileged daemon run in a jail with path=/.

The kernel side (PRIV) of this patch is missing (compared to to the github pull request).
The svcj part is OK.

In my case I got
panic: invalid local group size 16 and count 16

Man page changed as suggested.

Committed

Separate review for SSP, add man page info for FORTIFY.

I'll split the two parts up and try to come up with something for the docs.

In D47932#1099399, @dev_submerge.ch wrote:

Thanks for your input. I agree that we should keep an eye on performance, but I'd like to clarify: In our current refactoring of the format conversion we're not touching anything that changes the buffer sizes. And that's the only thing that could possibly affect audio latency. If latency really is of concern, then we'd have to look at smaller buffer sizes and how to make timers and scheduling more reliable. Also I doubt that we ever had the lowest overall latency, if you count in ASIO on Windows. I suspect that was about the latency introduced by the resampler.

FYI: at some point we had the sound system with the lowest latency. Ariff was comparing MS, OS X and Linux. I do not know if they have catched-up since then, but it may be worth the effort to check the performance / latency for such changes. Unfortunately I haven't found the info about the latency stuff he did, only his resampling quality comparison with other resampler implementations (https://people.freebsd.org/~ariff/z_comparison/). In https://people.freebsd.org/~ariff/old/ he has some old low latency diffs, so some interested soul could check which parts he modified to get lower latency.

Looks good (not run tested).

FYI, I added this to src.conf:

grep LOADER /etc/src.conf

LOADER_GZIP_SUPPORT=no
LOADER_BZIP2_SUPPORT=no
LOADER_BIOS_TEXTONLY=no
LOADER_NFS_SUPPORT=no
LOADER_TFTP_SUPPORT=no
LOADER_CD9660_SUPPORT=no

While I agree with the rationale and the change:

In D40972#1062704, @arrowd wrote:

I just bumped into this and I wonder what's the rationale to perform promotion during bectl activate.
I want to keep the BE snapshot I'm creating a new BE from, but activating new BE removes the snapshot (well, transfers it to the new BE's dataset).