full context

full context

Results from the affected hardware (em0, 82541PI), ~44 h
on a v3 kernel. Summary: 16 watchdog fires, all true positives, 0 false
positives.

New tested version, on hardware which triggers the watchdog.

So you disagree with kern.features.exterror.
Do you also disagree with kern.features.exterr_strings which covers the optional behavior of verbose exterror and is useful in unit tests to differentiate between "fails because something is wrong -> error" and "fails because it does not exist -> intendet -> ok".

The kern.features.exterror part is for the benefit of userland programs which want to use it (e.g. difference between FreeBSD 14.x and 15.x).
The kern.features.exterr_strings part is for the benefit of unit tests to be able to skip if the verbose strings are not enabled.

This fires too often, maybe some false positives. I will rework.

Switch to the mxge way. Mxge seems to harvest the completions
eagerly per interrupt, while iflib seems to reclaim lazy. The
software counter of iflib would get into the watchdog firing
situation on a lightly loaded interface... if I get it correctly.

When excluding from fortify the ones for which I mailed the error message to you, I have build
Queued: 1338 Inspected: 0 Ignored: 0 Built: 1338 Failed: 0 Skipped: 0 Fetched: 0 Remaining: 0

In D57628#1322519, @kevans wrote:

In D57628#1322468, @netchild wrote:

In D57628#1321971, @kevans wrote:

All supported releases should have it, but it is also harmless to define any of this when it isn't -- I'd probably avoid complicating it too much.

Sounds sensible.

If you don't object to the ports patch as the maintainer, I'll just go ahead and request an exp-run with both patches applied (with the assignment you noted fixed). I had hoped to land this this week, but I also don't want antoine throwing tomatoes at me if we fundamentally break the ports tree. =-)

I don't object for sure. But I suggest to use this instead:

diff --git Mk/Features/fortify.mk Mk/Features/fortify.mk
index 2e43ca98242..86d149ff68e 100644
--- Mk/Features/fortify.mk
+++ Mk/Features/fortify.mk
@@ -14,5 +14,7 @@ FORTIFY_SOURCE?=2
 FORTIFY_CFLAGS?=       -D_FORTIFY_SOURCE=${FORTIFY_SOURCE}
 CFLAGS+=       ${FORTIFY_CFLAGS}
 CXXFLAGS+=     ${FORTIFY_CFLAGS}
+.  else
+FORTIFY_SOURCE=0
 .  endif
 .endif

That works- it does need an .export FORTIFY_SOURCE line to work, though, otherwise the build will pick up the default in bsd.sys.mk if we aren't adding to C*FLAGS (since the port build would be running in a submake)

In D57628#1321971, @kevans wrote:

All supported releases should have it, but it is also harmless to define any of this when it isn't -- I'd probably avoid complicating it too much.

Without doing any build-test, should the UNSAFE part be "=0" instead of "?=0"? We want a hard override in the UNSAFE case, don't we?

@kevans would it help if I build a known failing port with your ports-patch applied?

This is what I have, this is historically grown and may or may not be an issue today:

I assume we do not have .md files in the kernel subsystem directories (yet). As such I assume this should not affect the output on the next run. Based opn that, I so no reason why not to add more supported file types.
If there are .md files, I suggest to check how it affects the output.

Very strange. First "patch" told me it is already applied (it was a pristine src tree). Now I do a git diff and it is showing up. Pffft.

I was wrong. It is committed. It just needs to be closed here. I do not see a way to close. Maybe I'm blind... the only thing I found was abandoning this revision.

Yes, it waits for me to remember that this is not committed...

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