Network equipment is critical infrastructure with long uptimes and
significant throughput/processing, especially in undercloud fabric.
The OS kernel is responsible for managing raw system resources and
the enforcement of security (privilege/access) boundaries. This
set of responsibilities, and a number of technical reasons such as
long-running memory layouts, and physical page table access, make
the kernel a high-value target for attackers. Rebooting the system
for upgrades can be problematic, and patches providing correct
solutions for ring0 concerns may take some time to matriculate to
stable release - leaving gaps in the security posture of systems.
In order to reduce exposure during these gaps, and the impact or
feasibility of 0-day attacks, this high-value target needs to be
better protected with probabilistic, deterministic, and semantic
defenses. While this effort is by no means a replacement for the
professional-grade mitigations in Grsecurity/PaX, it does start
down the path of elevated defensive posture by introducing the
Linux Hardened kernel patchset from GrapheneOS by Daniel Micay and
others.
The hardening patchset implements a number of C-level fixes, higher
entropy ASLR, namespace protections, FS access restrictions to
sensitive targets like /dev/mem, and syscall restrictions. Atop the
basics, it adds GCC plugins or improves upon the upstream ones to
randomize struct layouts, initify and initialize variables at
compile-time, and provides a PRNG from the jitterentropy source.
More info at https://www.whonix.org/wiki/Hardened-kernel as well as
in the source repo https://github.com/anthraxx/linux-hardened.
Notes:
While not in the scope of this pull request, the kernel-tier
mechanisms provided here should be complemented by Daniel Micay's
hardened-malloc to guard against userspace memory corruption, UAF,
and other malfeasance.
This effort parallels a similar pull request for VyOS - sonic-net#132.
The added functionality provided there in regards to LVS, XTables,
and other patches can be backported here on request.
Testing:
None on this branch, we maintain 5.4 and 5.10 branches in-house