Building monolithic kernels should be investigated to avoid reliance on LKMs for those systems that do not require third-party modules.

In the context of hardening VyOS, removing the bulk of the LKM subsystem reduces a significant amount of attack surface in terms of the ability to inject dynamic code into the kernel address space easily. Even with LKMs disabled at runtime through modifications, the kernel (when surpporting LKMs) is built with an ELF loader and several other facilities providing runtime executable code loading primitives.

By carefully preventing privileged IO (including ioperm, iopl, interfaces like kmem, etc) and removing the LKM subsystem, we can have an immediate improvement in terms of resilience against kernel tampering for rootkits and such.
In addition, this will allow several places in the kernel to have read-only, permanently RX (but never writable) memory regions that would otherwise need to be written to in order to support loading LKMs.

I do not expect this to impact performance (for the worse) or break things. If a kernel module has been merged upstream and it does not operate well in a monolithic build, that is a major upstream problem signaling the failure of the maintainer of that subtree of drivers, as all drivers in the Linux kernel are expected to function exactly the same per the ABI regardless of whether they are built-in or built as modules.

Also, VyOS is essentially a static, pre-built system that does not undergo changes as far as the kernel and core user-land are involved. This reduces the likelihood of having trouble significantly and allows us to have repeatable builds and images deployed. We know exactly what drivers and modules go in, and what doesn't.

In the event that external drivers are needed, LKM-enabled images could be left available for the user, or the drivers could be chosen to be built-in.