Page MenuHomeVyOS Platform

Upstream Kernel Patches from Semper Victus Linux Hardened Tree
Open, Requires assessmentPublicFEATURE REQUEST

Description

Our company maintains several trees of hardened Linux kernels with extended functionality for scheduling, networking, and storage (we pretty much have our own Arch distro). While our primary efforts focus on development atop Grsecurity kernels, we maintain a parallel tree using the GrapheneOS kernel patches (linux-hardened) for distribution to clients who do not acquire Grsecurity patches from Open Source Security Inc. During out internal work on VyOS we've incorporated all of the out-of-tree kmods and patches directly into the kernel source - ixgbe, qat, stackable FS changes, etc. We have extracted these efforts along with applicable other patches to use in VyOS which provide:

  1. xtables-addons in-tree: iptables modules for geoip, tarpit, etc
  2. PF_RING in-tree: this can underpin NIDS traffic collection and other direct-access network functions
  3. LVS patches: http://ja.ssi.bg/
  4. IPoE in-tree: VyOS patch adapted for 5.4 tree

5: VLANmon in-tree: VyOS patch adapted for 5.4 tree
6: WireGuard official in-tree backport
7: AUFS5 to permit complex overlays without the efficiency issues of overlayfs
8: EoIP protocol driver in-tree: support MikroTik L2 tunneling protocol
9: UKSM in-tree for userspace memory dedup: this will be very handy once Dockers are being run in VyOS (we use systemd-nspawn today to do things like run Duo's authproxy, works great)
10: Inotify VyOS patch adapted for 5.4
11: RT6 link filter VyOS patch adapted for 5.4
12: Linux-Hardened: ASLR patches, some community backports from grsec, reduces privileged access vectors, hardens and fixes type issue on certain structures and data types, etc. Basically makes the OS-tier harder to attack, its no grsec, but its IS better than upstream. Can also theoreticaly work with LTO+CFI with Clang, though we use GCC in-house to take advantage of RANDSTRUCT and such (custom kernels which aren't distributed gain decent standoff from this, distro kernels benefit too, though less).
13: If desired, we can also push up our linux-hardened + RSBAC patch to provide full-fledged RBAC implementation on vanilla/hardened kernels.

Once this is done, we will upstream implementation of Hardened Malloc from https://github.com/GrapheneOS/hardened_malloc to help tighten up userspace memory defenses (we run it on our images, for a while now, no issues there).
None of this will make your system impervious, but memory corruption attacks will be harder (a lot harder remotely), same for privesc, and actual network defensive capabilities using XTables (geoip firewall rules are handy).
We tend to track LTS' so can support this work ongoing with minimal overhead if VyOS sticks to those kernels, or if we have to support yet another tree, we can work with the VyOS team to transfer knowledge and share maintenance costs for the effort.

Details

Difficulty level
Hard (possibly days)
Version
VyOS 1.3, Linux 5.4
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible

Event Timeline

It’s best to provide links to related descriptions instead of asking everyone to search for the related details and patch implementations you describe

While i appreciate that you have an opinion of what's "best," i'm not re-summarizing 10+y of Linux out-of-tree history to spoon feed someone data they can, and should (like good engineers do), acquire on their own. Several of those patches are simply in-tree integrations for things currently built and packaged as kmods by VyOS on an LTS tree, the rest are well documented long running projects of their own which one must research and review the source code for anyway to properly understand their function and benefit.

sempervictus updated the task description. (Show Details)
sempervictus changed Difficulty level from Unknown (require assessment) to Hard (possibly days).
sempervictus changed Version from - to VyOS 1.3, Linux 5.4.
pasik added a subscriber: pasik.Tue, Sep 15, 7:20 PM