config: add MQUEUE, BRIDGE, NETFILTER support

[dustymabe]

See individual commit messages.

Essentially what I'm trying to do is run podman inside my krun VM and have it be completely isolated from the host, but also function well enough without special arguments to act generically like a container runtime. i.e. I want to be able to navigate to a project's source code and type make whatever and if that project leverages containers everything just works.

An example of this would be make ci-operator-config from this repo without having to patch the Makefile like this:

diff --git a/Makefile b/Makefile
index 2e779fbd235..fe6999cced6 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,7 @@ SHELL=/usr/bin/env bash -o errexit
 .PHONY: help check check-boskos check-core check-services check-validate-main-promotion dry-core core dry-services services all update release-controllers checkconfig jobs ci-operator-config registry-metadata boskos-config prow-config validate-step-registry new-repo branch-cut prow-config multi-arch-gen 
 
 export CONTAINER_ENGINE ?= podman
-export CONTAINER_ENGINE_OPTS ?= --platform linux/amd64
+export CONTAINER_ENGINE_OPTS ?= --platform linux/amd64 --net=host --mount type=tmpfs,destination=/dev/mqueue
 export SKIP_PULL ?= false
 
 VOLUME_MOUNT_FLAGS = :z

Ultimately my goal is to sandbox AI agents so I'm comfortable allowing them to do more, but not worrying about my host system.

I understand especially the last commit adding BRIDGE/NETFILTER may cause the size of the kernel to increase and may not be desired since it enables many options. Is this generally a problem? Is there some sort of balance between "these config options enable an important use case" and the size increase?

[slp]

I understand especially the last commit adding BRIDGE/NETFILTER may cause the size of the kernel to increase and may not be desired since it enables many options. Is this generally a problem? Is there some sort of balance between "these config options enable an important use case" and the size increase?

There's never been a well-defined rule. If there's a use case, the change doesn't impact boot time and the size increase isn't too large, it can go in.

In this case, on aarch64 I see the size increases by just 64k, and there isn't a reason for this change to affect boot time. So LGTM, thanks!

[slp]

I've just noticed the first commit, beyond aligning the config with 6.12.87, actually changes the current configuration, at least on aarch64 (for instance, disabling KVM). Please drop the first commit and just add the new configuration options (Makefile does an "olddefconfig" anyway).

[dustymabe]

I've just noticed the first commit, beyond aligning the config with 6.12.87, actually changes the current configuration, at least on aarch64 (for instance, disabling KVM).

oops. Yes, I see that now.

Please drop the first commit and just add the new configuration options (Makefile does an "olddefconfig" anyway).

Do you know an easy way for me to translate "I want bridge and netfilter/nftables support" into the right config options?

with MQUEUE and KVM it was pretty easy because there were only a few options but for netfilter there are a ton of options so going through some sort of "wizard" would help, but I think when you do that you end up with all the defaults from 6.12.87 getting updated too (i.e. the first commit of this PR, which is why I broke it out into a separate commit).

[slp]

with MQUEUE and KVM it was pretty easy because there were only a few options but for netfilter there are a ton of options so going through some sort of "wizard" would help, but I think when you do that you end up with all the defaults from 6.12.87 getting updated too (i.e. the first commit of this PR, which is why I broke it out into a separate commit).

Let me update the configs manually, and then you can rebase this PR on it.