I have .. feelings about this, having spent my time in the routing service trenches and jail trenches too. I mean, heck, we can't even jail the wifi services just yet! :-)

Rewrite DB_SHOW_COMMAND_FLAGS to make it clearer.

In D49843#1138954, @netchild wrote:

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.

Apart from jamies comment, How is this different from any other daemon running as root in a jail? If you can take over any externally reachable service in a jail, it is over. You need to delete the jail and start fresh (with a fixed daemon).

@bz Thanks, patch updated.

Add SPDX, remove #-, and link to details about EC2 IMDS.

This version just does an execl() as suggested by kib@.

If this header is used outside of base and the _id[] array is used from it, then we might need to instead disable the warning for this header during the test-includes phase.

See D49954 and D49955 for one approach. I also tested patching tools/build/test-includes/Makefile to add -Wno-unused-variable to CFLAGS for these specific headers.

BTW, for other arrays like this in <sys/disklabel.h> and <sys/resource.h> we require consumers to define a special macro to expose the array of names (e.g. _RLIMIT_IDENT for the resource limit names). That is probably the correct fix.

Oops, missed the last suggested change from kib@
the last time. It is here now.

Sigh, so my builds work fine because I had versions of these built from before. Note that we intentionally enabled this specific warning for both Clang and GCC back in 2023 (it used to be disabled). I'm not sure why clang's version is too broken to flag this correctly. Probably this is just poor form in headers, and notably an actual kernel build doesn't fail. The only warning I get from if.c with GCC is:

Updated runat.c to apply kib@'s suggestions.
For some reason (don't know where I got it) I
thought that fchdir() directory change would
affect more than the process, which was why I
did the fork(). (I think it came from ancient
recollections of how 6th Edition worked in the
1970s. I'm gettin old;-)

Also, this build:

I just pushed the fixes I need for a world + kernel build to complete. I did not hit the error you are getting in test-includes at all. Not at all clear to me why CI is seeing them. I wonder if NO_CLEAN builds don't re-run test-includes on changes?

Re-written to conform to the more Solaris-like
semantics of O_NAMEDATTR that is now implemented
in main.

This definitely needs changes, including I think cleaning up how we define the ioctl struct and key struct to have separate key and mic sections, before this is toyed with a bit more.

Editing for comments and user strings.

In D49913#1139036, @markj wrote:

This seems ok. I still think the approach is inferior to using the mmap() hint or a new flag. A process, especially a language runtime, could legitimately load some library which wants to use the full LA57 address space even when other components in the process do not support LA57. General-purpose applications do not get much benefit from the extra address bits, and with this approach, the extra bits are inaccessible to libraries unless the binary is specially marked. It is probably fine for appliance vendors at least.

Anyone? Otherwise I'll commit this before the end of this week (24/26. April).

Anyone?

This seems ok. I still think the approach is inferior to using the mmap() hint or a new flag. A process, especially a language runtime, could legitimately load some library which wants to use the full LA57 address space even when other components in the process do not support LA57. General-purpose applications do not get much benefit from the extra address bits, and with this approach, the extra bits are inaccessible to libraries unless the binary is specially marked. It is probably fine for appliance vendors at least.