Linux Aegis is a pentesting-patched Linux kernel, used in Athena OS, forked from the CachyOS kernel and enhanced with patches and configuration choices tailored to the real-world needs of penetration testers, security researchers, and CTF players.
It ships in two variants with distinct purposes:
| Variant | Purpose | Performance | Audience |
|---|---|---|---|
linux-aegis-offensive | Maximum capability, no restrictions | Full stack - BORE, -O3, 1000Hz | Offensive research, CTF, tool development |
linux-aegis-hardened | Security-first, professionally operable | BORE + -O3 + 1000Hz; faster than stock distro kernels but measurably slower than linux-aegis-offensive due to hardening overhead | Client engagements, sensitive data, paranoid mode |
Both variants share the CachyOS performance foundation - BORE, -O3, 1000Hz - making both significantly faster than any stock pentesting distro kernel. The hardened variant carries additional overhead from its security layer (memory zeroing, hardened usercopy, stack canaries) and does not support sched-ext. It is fast, but not as fast as “. That is the honest trade-off.
On every boot, systemd-boot presents both kernels as separate entries:
Each entry boots its own Unified Kernel Image (UKI), a single signed EFI executable containing the kernel, initramfs, and kernel command line. Both UKIs are measured into the TPM (if enrolled) and validated by Secure Boot. You get cryptographic verification regardless of which variant you choose.
Switching is a reboot. No reinstallation, no reconfiguration. Boot linux-aegis-hardened for the client site, reboot into linux-aegis-offensive back in the lab. Both kernels are first-class entries, not fallbacks.
Usually pentesting distributions don’t ship a kernel that is genuinely engineered for offensive security work.
The only meaningful kernel-level contribution from the entire category is Kali’s WiFi injection patch. Pentoo historically had the most sophisticated approach with grsecurity, but grsecurity is no longer freely available and some of its security hardening are already enforced on mainline Linux kernels.
This creates a fundamental contradiction: distributions that exist to run the most demanding security tools ship generic desktop kernels, making no concessions to the actual workloads they carry. Not only do these kernels lack pentesting-specific features - they are compiled with conservative, generic settings that actively leave performance on the table for every tool running on top of them. hashcat runs slower. masscan moves fewer packets. The desktop lags under concurrent load. This is the result of not having built a kernel that treats performance as a requirement rather than an afterthought.
A real pentesting workload looks like this simultaneously:
hashcat consuming the GPU at 100% while the operator works in a terminalnmap or masscan hammering thousands of ports while Burp Suite intercepts trafficairodump-ng capturing frames on multiple WiFi channelsbpftrace and bcc for kernel-level analysisNone of these workloads are served by a generic Debian or Arch kernel with default settings. A generic kernel throttles throughput, restricts kernel access, and provides no guarantees about WiFi injection support. More critically, a kernel compiled at -O2 with a 300Hz timer and generic x86-64 code paths leaves tangible performance on the table - performance that directly translates into faster scans, higher cracking throughput, and a more responsive desktop under concurrent load.
Forking vanilla Linux from scratch is the wrong approach for a distribution kernel:
CachyOS provides the best available starting point:
hashcat or a scanner saturates the CPU in the background-march=native, targeting the actual instruction set of the build machine and enabling AVX2, AVX-512, and other modern extensions in kernel code paths including network checksum offload, memory operations, and internal crypto; CI artifacts use generic x86-64 for compatibilityLinux Aegis inherits all of this and adds the pentesting-specific layer on top. When CachyOS rebases against a new kernel release, linux-aegis benefits automatically. Their maintenance work flows upstream to us. This is not a kernel built from performance features bolted onto a security base. It is a performance kernel with security capability engineered in.
The performance of linux-aegis is not an afterthought layered on top of a security-focused kernel. It is the foundation. Both linux-aegis-offensive and linux-aegis-hardened are built on the same CachyOS performance base - BORE, -O3, 1000Hz, native CPU (local) / generic x86-64 (CI), LRU_GEN. This means both are significantly faster than any stock kernel for the same workloads. However, the hardening layer in linux-aegis-hardened adds measurable overhead: memory zeroing on every allocation and free, hardened usercopy bounds checks, stack canaries, refcount validation, and stricter kernel protections all consume CPU cycles. linux-aegis-hardened is fast, much faster than any generic pentesting distro kernel, but it is not as fast as linux-aegis-offensive. That is the honest trade-off of choosing the hardened profile, and it is worth knowing.
The standard Linux kernel is compiled at -O2 - a conservative setting that prioritizes code size and compilation speed over runtime performance. CachyOS enables -O3 throughout the entire kernel build, allowing the compiler to apply additional loop unrolling, aggressive function inlining, and auto-vectorization passes that -O2 explicitly skips.
For a pentesting workload that makes constant heavy use of the kernel - packet processing, memory copies, filesystem I/O, process scheduling under load - this is a measurable improvement. Network paths are faster. Memory management operations complete sooner. The kernel gets out of the way of userspace tools more quickly.
CI builds of linux-aegis use Clang with full LTO (Link Time Optimization). This is a meaningful choice over GCC with no LTO, and it is worth understanding what it actually buys.
GCC vs Clang - in terms of runtime kernel quality, GCC and Clang produce essentially equivalent output on x86-64. Both compilers have been heavily tuned for kernel code and the difference in generated instruction quality is typically under 1% in real workloads. The real advantage of Clang is not performance but capability: it unlocks LTO, kCFI (on the hardened variant), and better sanitizer integration.
LTO - what it does - without LTO, each .c file is compiled and optimized in isolation. The compiler cannot see across file boundaries when making inlining or dead code decisions. With LTO, the compiler sees the entire codebase at link time and can inline across files, eliminate globally dead code, and propagate constants throughout the whole kernel.
Thin LTO vs Full LTO - thin LTO produces a compact summary of each translation unit during compilation and performs cross-module optimizations in parallel at link time. It captures roughly 80-90% of the benefit of full LTO at a fraction of the RAM and build time. Full LTO loads the entire kernel’s intermediate representation into memory as a single unit and optimizes globally - maximum quality, but requires 32GB+ RAM and is not viable on low resource CI runners. In practice the performance difference between thin and full LTO is under 1% for kernel workloads, because hot paths are already well-optimized within their own translation units.
What this means in practice - CI artifacts are built with Clang + full LTO. Local builds default to GCC with no LTO for simplicity, but can be switched:
# Build with Clang + thin LTO_use_llvm_lto=thin makepkg -s --skippgpcheck
# Build with Clang + full LTO (requires 32GB+ RAM)_use_llvm_lto=full makepkg -s --skippgpcheckA generic distribution kernel is compiled for the lowest common denominator of x86-64 hardware - x86-64-v1 - to ensure the binary runs on any machine. This means the compiler cannot emit AVX2, AVX-512, or any modern instruction even when the running CPU supports them fully.
linux-aegis supports several CPU targeting modes controlled by _processor_opt:
| Value | Behavior | Use case |
|---|---|---|
| (empty, default) | Native - equivalent to -march=native, detects the build machine’s CPU automatically | Best for local personal builds |
native | Explicit native - same as empty | Same as above, explicit form |
generic | Generic x86-64 - runs on any x86-64 machine | CI artifacts, distributed packages, multi-machine use |
zen4 | AMD Zen4/Zen5 optimized - znver4 target | AMD Ryzen 7000/9000 series machines |
CI builds use generic to produce artifacts that run on any x86-64 hardware. Local builds default to native, meaning the kernel is compiled for and optimized to the exact CPU in the build machine.
For most pentesting workloads the difference between targeting modes is small - the scheduler, timer frequency, WiFi injection patches, and security profile matter far more than whether the kernel uses AVX2 in its internal memory copy routines. The targeting mode matters most for CPU-bound kernel operations like network checksum computation, bulk memory copies, and internal crypto.
BORE patches the in-kernel EEVDF scheduler to add awareness of task burst behavior. Standard EEVDF treats all tasks equally based on their vruntime. BORE additionally tracks how bursty a task’s CPU usage is, and uses that information to make smarter preemption decisions.
In practice this means:
hashcat runs at full sustained throughput in the background while the terminal and GUI stay responsiveThis is the reason linux-aegis feels fast even with no configuration. BORE is always running, always making better decisions than plain EEVDF, and costs nothing at runtime.
The kernel’s timer interrupt frequency determines the minimum scheduling granularity. A 300Hz kernel wakes up to make scheduling decisions at most 300 times per second - every 3.3ms. A 1000Hz kernel does so every 1ms.
For a mixed workload where a terminal, Burp Suite, and a background scanner are competing for CPU time, higher timer frequency means faster context switching, better responsiveness under load, and more accurate data from perf and other profiling tools. For timing-sensitive security tools that measure response latencies, the improved granularity produces more reliable measurements. The CPU overhead of 1000Hz is negligible on any hardware capable of running modern pentesting tools.
Linux Aegis inherits CachyOS’s enabled LRU_GEN (Multigenerational LRU), a modern page reclaim algorithm that dramatically improves memory management under pressure. When a machine is simultaneously running a browser, Burp Suite, a scanner, and terminal sessions, memory pressure is common. LRU_GEN makes better decisions about which pages to evict, reducing the chance of thrashing and keeping the working set of active tools resident in RAM. On a pentesting laptop with 16GB of RAM running five tools simultaneously, this is one of the more meaningful day-to-day improvements over a stock kernel.
vm_swappiness=100 is baked directly into mm/vmscan.c under CONFIG_CACHY. For pentesting workloads it is good only when zram-backed swap is used. If not, the value must be overridden via sysctl because hashcat GPU buffers, masscan connection state, and large wordlists held in RAM will be aggressively swapped out under memory pressure, degrading tool performance significantly.
athena-settings keeps this to vm.swappiness=100 via sysctl. Without zram (disk-backed swap) lower this further to 10.
The sched-ext framework allows loading a BPF program that completely replaces the CPU scheduling policy at runtime - no reboot required. Linux Aegis ships with full sched-ext support, enabling users to switch between specialized schedulers optimized for specific workload profiles. See the Scheduler Architecture section for details on when each scheduler delivers the best results.
| Workload | Generic Kernel | linux-aegis | Why |
|---|---|---|---|
hashcat GPU cracking | Baseline | Faster CPU coordination | -O3, native ISA, better IRQ handling, BORE |
nmap / masscan throughput | Baseline | Higher packet rate | Optimized network paths, 1000Hz scheduling |
airodump-ng frame capture | Packet drops under load | Fewer drops | Tuned socket buffers, BORE prioritizes capture threads |
| Burp Suite + background scan | Laggy under load | Responsive | BORE keeps interactive threads prioritized |
bpftrace / kernel tracing | Restricted or unavailable | Full access | No lockdown, full eBPF, kprobes open |
| Multiple tools simultaneously | Context switch lag visible | Smooth | 1000Hz + BORE + LRU_GEN |
| Wine-based Windows tools | Poor timing accuracy | Improved | ntsync, better scheduler integration |
| USB WiFi adapter plug-in | Manual driver setup | Instant injection ready | Built-in injection patch + regulatory domain udev |
Because linux-aegis is built on CachyOS’s performance foundation rather than a minimal security kernel with performance bolted on, it performs exceptionally well as a general-purpose daily driver and not just during active engagements.
A security professional who uses their machine for development, research, content creation, or gaming between engagements gets a kernel that competes directly with gaming-focused Linux distributions:
-O3 optimization affects every kernel operation involved in a build: filesystem I/O, process scheduling, memory allocationThe machine is fast all day, every day, not only when running specific security tools. This is a meaningful quality-of-life advantage for professionals who live in their operating system.
Designed for maximum capability. Every restriction that blocks legitimate security tooling is removed. This kernel assumes the user is the attacker and their tools need full kernel access.
Scheduler and Performance:
scx_bpfland, scx_lavd, scx_rusty at runtime_tcp_bbr3=yes) for better VPN and tunnel throughputUnrestricted Capability:
LOCK_DOWN_IN_EFI_SECURE_BOOT - lockdown active only under EFI Secure Boot; disabled in normal bootMODULE_SIG_FORCE disabled - load any kernel module without signingSECURITY_DMESG_RESTRICT disabled - unrestricted kernel ring buffer access/dev/mem access filtered (STRICT_DEVMEM) - RAM regions accessible; hardware MMIO ranges blockedbpftrace, bcc, offensive eBPF tools work without restrictionperf access - no hardware performance counter restrictions (perf_event_paranoid unrestricted)USB_MON built-in - USB traffic capture without loading extra moduleskptr_restrict=1 - root retains access to /proc/kallsyms for kernel exploit developmentWiFi and Network:
net/mac80211/wireshark, tcpdump, airodump-ng)Designed for professional engagements where the machine carries client data and operates on hostile networks. BORE performance and pentesting capabilities are preserved, but the kernel defends itself against privilege escalation, unauthorized module loading, and raw memory attacks.
Performance is not touched by hardening. Hardening is applied at the memory safety, module integrity, and hardware access layer, not at the scheduler, compiler, or timer layer. The machine runs fast. The machine is also protected.
One genuine exception exists: linux-aegis-hardened does not support sched-ext. BORE remains the scheduler - and BORE is an excellent default that handles all pentesting workloads well.
Scheduler and Performance:
Security Additions:
Module and boot integrity:
SECURITY_LOCKDOWN_LSM at integrity level - blocks /dev/mem and unsigned modules, does not block perf, kprobes, uprobes, or ftraceMODULE_SIG_FORCE enabled - all modules must be signed with Athena’s enrolled MOK keyMSEAL_SYSTEM_MAPPINGS enabled - system mappings (vdso, vvar) are memory-sealed and cannot be remappedInformation restriction:
SECURITY_DMESG_RESTRICT enabled - kernel logs require privilegekptr_restrict=2 default) - kernel pointers hidden from all users including rootDEBUG_FS_ALLOW_NONE - debugfs inaccessible by default; eliminates a significant kernel introspection surfacedevice_sidechannel_restrict=1 - character and block device timestamps normalized for unprivileged users, preventing timing side-channel attacksperf and tracing:
SECURITY_PERF_EVENTS_RESTRICT enabled - perf_event_open restricted to CAP_PERFMON; closes CVE-2023-6931, CVE-2022-1729, CVE-2021-29657, CVE-2020-14351Memory safety:
INIT_ON_ALLOC_DEFAULT_ON - kernel memory zeroed on every allocationINIT_ON_FREE_DEFAULT_ON - kernel memory zeroed on every freePAGE_SANITIZE_VERIFY - verifies pages are actually zeroed after init_on_free, catching write-after-free bugsSLAB_SANITIZE_VERIFY - verifies slab objects are actually zeroed after init_on_freeSLAB_CANARY - randomized canaries at the end of every kernel heap allocation; detects overflows, absorbs small corruptions, provides double-free detectionSLAB_FREELIST_RANDOM - randomizes freelist order on new slab pages, reducing heap spray predictabilitySLAB_FREELIST_HARDENED - hardens slab freelist metadata against corruptionSLAB_MERGE_DEFAULT disabled - prevents slab cache merging, reducing heap spray effectivenessRANDOM_KMALLOC_CACHES - randomizes which slab cache kmalloc allocations useBUG_ON_DATA_CORRUPTION - kernel panics on detected memory corruption rather than continuing; automatically enables LIST_HARDENEDKFENCE_BUG_ON_DATA_CORRUPTION - kernel panics on kfence-detected memory corruptionHARDENED_USERCOPY - bounds checking on every kernel/userspace memory copyFORTIFY_SOURCE - compile-time buffer overflow detection throughout the kernelSTACKPROTECTOR_STRONG - stack canaries on all functionsPANIC_ON_OOPS - kernel panics on oops rather than attempting to continue in a potentially corrupted stateASLR and address space:
RANDOMIZE_BASE (KASLR) - kernel base address randomized on every bootRANDOMIZE_MEMORY (KSLR) - kernel memory layout randomizedRANDOMIZE_KSTACK_OFFSET_DEFAULT - kernel stack offset randomized per syscall, defeating stack-based info leaksARCH_MMAP_RND_BITS set to maximum - strongest available ASLR entropy for mmap baseARCH_MMAP_RND_COMPAT_BITS set to maximum - same for compat applicationsCOMPAT_BRK disabled - heap randomization enabledDEFAULT_MMAP_MIN_ADDR=65536 - raised from 4096, reducing NULL pointer dereference attack surfaceFilesystem and namespace:
LEGACY_TIOCSTI disabled - blocks terminal injection via the TIOCSTI ioctlSECURITY_TIOCSTI_RESTRICT - additionally requires CAP_SYS_ADMIN for TIOCSTIsysctl_protected_symlinks=1, sysctl_protected_hardlinks=1 - symlink and hardlink protections enabled by defaultsysctl_protected_fifos=2, sysctl_protected_regular=2 - FIFO and regular file protections at maximumOVERLAY_FS_UNPRIVILEGED disabled - overlayfs not mountable by unprivileged usersUSER_NS_UNPRIVILEGED default n - unprivileged user namespace creation disabled by default; overridable at runtime via kernel.unprivileged_userns_clone/dev/mem maximally restricted - RAM regions only (STRICT_DEVMEM), I/O port regions blocked even from root (IO_STRICT_DEVMEM)IO_STRICT_DEVMEM enabled - blocks I/O port region access through /dev/mem even from root - stacks on top of STRICT_DEVMEM for maximum /dev/mem restriction.Networking:
SYN_COOKIES enabled by default - TCP SYN flood protection always activetcp_simult_connect disabled - removes a TCP weakness allowing source-port-guessing attacksBPF and io_uring:
bpf_jit_harden=2 default - maximum BPF JIT hardening; constants are blinded, limiting JIT spray attacksio_uring compiled in but disabled at runtime by default (sysctl_io_uring_disabled=1) - io_uring has been a prolific kernel exploit surface; can be re-enabled via sysctl kernel.io_uring_disabled=0USB:
deny_new_usb sysctl available - root can block new USB device connections at runtime (echo 1 > /proc/sys/kernel/deny_new_usb), useful during sensitive engagements to prevent BadUSB attacksThe following capabilities are retained on linux-aegis-hardened despite the hardening posture. Each represents a conscious trade-off - the pentesting utility outweighs the marginal additional risk given that the primary threat model is an external attacker who has not yet gained root, not a post-root attacker with unlimited time.
The Kali WiFi injection patch is applied identically on both profiles. Lockdown integrity does not restrict WiFi driver behavior, monitor mode, or frame injection - these operate at the driver and mac80211 layer, entirely below the lockdown boundary. Wireless assessments work identically on hardened: airodump-ng, aireplay-ng, mdk4, hcxdumptool, and hostapd-wpe all function without restriction.
Risk: None introduced by retaining this. The patch does not expand kernel attack surface. It modifies transmission behavior in the WiFi stack for frames that the operator is already authorized to inject.
Privileged eBPF requires CAP_SYS_ADMIN or CAP_BPF + CAP_PERFMON. Lockdown integrity does not restrict it. The lockdown boundary is scoped to preventing persistent kernel modification (unsigned modules, kexec, /dev/mem), not to blocking introspection tools that already require root.
Unprivileged eBPF (BPF_UNPRIV_DEFAULT_OFF) is disabled on both profiles. Only privileged eBPF is available, and only to root.
Why it is kept: bpftrace and bcc are core pentesting and forensic tools - kernel tracing, dynamic instrumentation, network analysis, and some offensive eBPF workflows all depend on them. Disabling BPF_SYSCALL entirely would also break systemd’s BPF-based firewall, Cilium, and other system components.
Dynamic kernel and userspace tracing remain available. Like privileged eBPF, these require root and are not restricted by lockdown integrity. They are retained because pwndbg, gef, bpftrace, and kernel exploit development workflows depend on them.
Risk: Same category as privileged eBPF - a post-root attacker can use kprobes to hook arbitrary kernel functions. The same threat model scoping applies.
Users of linux-aegis-hardened can sign their own modules - DKMS drivers, LiME, custom out-of-tree modules - using the kernel’s built-in signing tooling and the MOK key enrolled during installation:
# Sign a module manually using the kernel's sign-file tool# and the MOK key created by the Dory installersudo /usr/lib/linux-<version>/build/scripts/sign-file \ sha512 \ /etc/secureboot/keys/MOK.key \ /etc/secureboot/keys/MOK.crt \ /path/to/module.ko
# DKMS modules can be signed automatically post-build# by adding a post_build hook to /etc/dkms/post_build.d/Linux Aegis applies patches in a defined order. Patches that modify different kernel subsystems are compatible; patches that touch the same subsystem may conflict and are reviewed carefully before inclusion.
1. CachyOS pre-patched tarball └── CachyOS base patchset already applied (performance fixes, ADIOS I/O scheduler, ntsync, compatibility) Note: unprivileged user namespace sysctl already integrated natively in kernel/fork.c - Kali's patch for this is not applied
2. CachyOS scheduler patch └── 0001-bore-cachy.patch Adds BORE code to kernel/sched/fair.c Adds CONFIG_SCHED_BORE to kernel/sched/Kconfig
3. Kali WiFi injection patches └── kali-wifi-injection.patch Modifies net/mac80211/ for global injection support Different subsystem from BORE - no conflict └── carl9170-promisc.patch AR9170 USB chipset promisc flag fix for aireplay-ng └── intel-iommu-intgpu-off.patch Adds intel_iommu=intgpu_off parameter
4. [linux-aegis-hardened only] linux-hardened patch └── hardened.patch Security hardening patches Different subsystem from BORE and WiFi - no conflict Adds perf_event_paranoid level 3 + CONFIG_SECURITY_PERF_EVENTS_RESTRICT └── platform-keyring-module-sig.patch UEFI DB certs for module signing via platform keyring
5. Config file applied cp ../config .config scripts/config -e CACHY scripts/config -e SCHED_BORE scripts/config --set-val HZ 1000 [profile-specific options]These are two distinct mechanisms that work together:
A patch must be applied before its config option can be enabled. For example: 0001-bore-cachy.patch adds CONFIG_SCHED_BORE to the kernel’s Kconfig system. Only after the patch is applied can scripts/config -e SCHED_BORE have any effect.
Some distributions ship a PREEMPT_RT kernel variant. The RT patch makes the kernel fully preemptible, giving hard real-time guarantees with microsecond-level timing precision. This sounds appealing but is the wrong trade-off for offensive security work.
RT trades throughput for latency consistency. For pentesting, throughput matters far more:
| Tool | Under PREEMPT_RT | Under BORE + sched-ext |
|---|---|---|
hashcat GPU cracking | Slower throughput | Maximum throughput |
nmap / masscan | Reduced packet rate | Full rate |
airodump-ng capture | More consistent timing | Fast with tuned buffers |
| Interactive terminal | Very responsive | Also very responsive |
| Simultaneous heavy workloads | RT overhead hurts all | Better overall balance |
BORE with sched-ext delivers better real-world results across every meaningful pentesting workload. RT remains appropriate for pro audio production, industrial control systems, and robotics. For pentesting it is the wrong approach and out of scope.
Beyond patches, linux-aegis explicitly sets kernel configuration options that enable pentesting workflows and enforce security baselines. These are not assumed from the CachyOS base but are set unconditionally in the PKGBUILD because CachyOS cannot be relied upon to maintain them across releases.
| Config | Value | Why |
|---|---|---|
CONFIG_PACKET | built-in | Raw packet socket - required by tcpdump, scapy, and any tool that captures at the link layer |
CONFIG_TUN | module | TUN/TAP virtual interfaces - required by OpenVPN, WireGuard userspace, and VPN tooling |
CONFIG_MAC80211_HWSIM | module | Software-simulated WiFi interfaces for testing injection without physical hardware |
CONFIG_CFG80211_CRDA_SUPPORT | enabled | Regulatory domain enforcement - ensures correct channel availability on all adapters |
CONFIG_TCP_AO | enabled | TCP Authentication Option - required for testing modern BGP and routing protocol implementations |
| Config | Value | Why |
|---|---|---|
CONFIG_SECURITY_APPARMOR | enabled | CachyOS dropped AppArmor in a recent build. Athena OS re-enables it explicitly - AppArmor is a core component of the security stack and cannot be silently absent. |
CONFIG_SECURITY_APPARMOR_HASH | enabled | AppArmor policy hash - required for policy verification and integrity checking. |
CONFIG_BPF_UNPRIV_DEFAULT_OFF | enabled | Unprivileged BPF disabled by default. Privileged BPF (bpftrace, bcc, offensive eBPF) works normally. Reduces kernel attack surface from untrusted userspace. |
CONFIG_USER_NS | enabled | User namespaces required for Flatpak, rootless Podman, and browser sandbox isolation. |
CONFIG_SECURITY_LOCKDOWN_LSM | enabled | Lockdown LSM compiled in on both profiles. Offensive: active only under EFI Secure Boot. Hardened: integrity level enforced. |
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT | enabled | Lockdown activates automatically when Secure Boot is active - both profiles. |
CONFIG_STACKPROTECTOR_STRONG | enabled | Stack canaries on all functions - both profiles. |
CONFIG_STRICT_KERNEL_RWX | enabled | Kernel code marked read/execute only - blocks post-exploit shellcode injection in kernel space. |
CONFIG_STRICT_MODULE_RWX | enabled | Module memory marked read/execute only - same protection for loaded modules. |
CONFIG_HARDENED_USERCOPY | enabled | Bounds checking on every kernel/userspace memory copy - both profiles. |
CONFIG_FORTIFY_SOURCE | enabled | Compile-time buffer overflow detection throughout the kernel - both profiles. |
CONFIG_SECURITY_YAMA | enabled | Yama LSM - ptrace scope restrictions. Both profiles enable it; hardened sets stricter scope. |
| Config | Value | Why |
|---|---|---|
CONFIG_SECURITY_PERF_EVENTS_RESTRICT | enabled | Restricts perf_event_open to CAP_PERFMON. Closes CVE-2023-6931, CVE-2022-1729, CVE-2021-29657, CVE-2020-14351. Provided by 0001-hardened.patch. |
CONFIG_SECURITY_DMESG_RESTRICT | enabled | Kernel ring buffer restricted to privileged users - prevents information leakage that helps build ROP chains. |
CONFIG_MODVERSIONS | enabled | Module version checking - prevents loading modules built against a different kernel ABI. |
CONFIG_MODULE_SIG | enabled | Module signature infrastructure compiled in. |
CONFIG_MODULE_SIG_ALL | enabled | All modules signed at build time with the kernel’s signing key. |
CONFIG_MODULE_SIG_SHA512 | enabled | SHA-512 signature algorithm for module signing. |
CONFIG_INTEGRITY | enabled | Integrity measurement framework - foundation for IMA and platform keyring. |
CONFIG_INTEGRITY_ASYMMETRIC_KEYS | enabled | Asymmetric key support for integrity verification. |
CONFIG_INTEGRITY_PLATFORM_KEYRING | enabled | UEFI DB certificates enrolled into the platform keyring for module signature verification. Provided by platform-keyring-module-sig.patch. |
CONFIG_IMA | enabled | Integrity Measurement Architecture - measures files before execution and records hashes. |
CONFIG_IMA_APPRAISE | enabled | IMA enforcement - can block execution of files that fail integrity checks. |
CONFIG_IMA_ARCH_POLICY | enabled | Architecture-defined IMA policy applied at boot. |
CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY | enabled | Restricts IMA keyrings to keys signed by the builtin or secondary trusted keyring. |
CONFIG_IO_STRICT_DEVMEM | enabled | Filters I/O port access - defense-in-depth alongside CONFIG_DEVMEM not being set; ensures even if /dev/mem were present, I/O memory regions claimed by drivers cannot be accessed. |
CONFIG_SLAB_CANARY | enabled | Randomized canaries at the end of every kernel heap allocation - detects overflows, absorbs small corruptions, provides basic double-free detection. |
CONFIG_SLAB_FREELIST_RANDOM | enabled | Randomizes freelist order on new slab pages - reduces predictability of heap spray attacks. |
CONFIG_SLAB_FREELIST_HARDENED | enabled | Hardens slab freelist metadata - makes freelist corruption harder to exploit. |
CONFIG_RANDOM_KMALLOC_CACHES | enabled | Randomizes slab cache selection for kmalloc - reduces determinism in heap layout attacks. |
CONFIG_PAGE_SANITIZE_VERIFY | enabled | Verifies pages are zeroed after init_on_free - catches write-after-free bugs that init_on_free would otherwise silently mask. |
CONFIG_SLAB_SANITIZE_VERIFY | enabled | Same verification for slab objects - ensures init_on_free actually worked on every allocation. |
CONFIG_PANIC_ON_OOPS | enabled | Kernel panics on oops rather than continuing in a potentially corrupted state. |
CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT | enabled | Randomizes kernel stack offset on every syscall - defeats stack-based information leaks. |
CONFIG_MSEAL_SYSTEM_MAPPINGS | enabled | Memory-seals system mappings (vdso, vvar) - prevents remapping attacks. |
CONFIG_SECURITY_TIOCSTI_RESTRICT | enabled | Requires CAP_SYS_ADMIN for TIOCSTI - additional restriction on top of LEGACY_TIOCSTI being disabled. |
CONFIG_OVERLAY_FS_UNPRIVILEGED | disabled | Overlayfs not mountable by unprivileged users - closes a historically exploited privilege escalation surface. |
CachyOS issue #574 removed AppArmor from their LSM stack. Athena OS re-enables it unconditionally because AppArmor is a core part of the security architecture - the threat model, sandboxing documentation, and user-facing security guidance all depend on it. Rather than trusting the upstream config, the PKGBUILD sets it explicitly and pins the LSM load order:
scripts/config \ -e SECURITY_APPARMOR \ -e SECURITY_APPARMOR_HASH \ -e SECURITY_APPARMOR_HASH_DEFAULT \ --set-str LSM "landlock,lockdown,yama,integrity,apparmor,bpf"This ensures AppArmor is always present and always in the correct position in the LSM stack regardless of what CachyOS changes upstream.
Linux Aegis uses a layered scheduler architecture that provides a reliable, high-performance default with optional runtime specialization for specific workloads:
No scx active (default):┌─────────────────────────────────────┐│ BORE (EEVDF + burst-awareness) │ ← Always available, zero config needed│ Best general-purpose fallback │ ← Outperforms plain EEVDF for mixed workloads└─────────────────────────────────────┘
scx scheduler loaded:┌─────────────────────────────────────┐│ scx_bpfland / scx_lavd / etc. │ ← Completely replaces BORE at runtime│ BORE is dormant │ ← No reboot required to switch└─────────────────────────────────────┘
scx unloaded or crashes:┌─────────────────────────────────────┐│ BORE resumes automatically │ ← Safe fallback, system stays stable└─────────────────────────────────────┘BORE is a patch to the in-kernel EEVDF scheduler. It is compiled into the kernel, always running, and cannot be removed without rebuilding. It adds burst-aware scheduling that improves desktop responsiveness under mixed workloads.
sched-ext schedulers (scx_bpfland, scx_lavd, scx_rusty, etc.) are BPF programs loaded at runtime that completely replace the scheduling policy. When one is active, BORE is bypassed entirely. When stopped, BORE resumes. No reboot is required.
| Workload | Recommended Scheduler | Reason |
|---|---|---|
| General pentesting | BORE (default) | Reliable, zero configuration, good for everything |
| Burp Suite + terminal + background scan | scx_bpfland | Best for mixed interactive + background heavy workloads |
| GPU cracking + interactive work | scx_lavd | Minimum input latency alongside heavy sustained GPU load |
High-rate nmap / masscan | scx_rusty | Better multi-core throughput for massively parallel workloads |
| Active professional engagement | BORE (default) | Predictability and stability over marginal peak performance gains |
linux-aegis-hardened | BORE only | sched-ext is not supported on the hardened variant |
# Install sched-ext schedulerssudo pacman -S scx-scheds scx-tools
# Start scx and switch to bpfland for mixed pentesting workloadssudo systemctl start scxscxctl switch scx_bpfland
# Switch to lavd for a cracking sessionscxctl switch scx_lavd
# Return to BOREsudo systemctl stop scx
# Check current statecat /sys/kernel/sched_ext/state # disabled / enabled / disablingcat /sys/kernel/sched_ext/root/ops # name of the currently active schedulerThe two variants represent an explicit, documented choice between two threat models. Neither is universally correct - the right choice depends on context.
| Capability enabled | Security implication | Why it is acceptable |
|---|---|---|
| No module signing | Root can load unsigned modules including rootkits | The user IS root; this is intentional by design |
| Lockdown only under Secure Boot | Raw hardware access, kexec, /dev/mem in normal boot | Tools like LiME, memory forensics require this |
| dmesg unrestricted | Kernel internals visible to any user | Pentesters need kernel messages for driver debugging |
| kptr readable by root | Kernel addresses accessible to root | Kernel exploit development requires /proc/kallsyms |
| perf unrestricted | Hardware counters accessible to unprivileged users | hashcat, bcc, bpftrace require this for legitimate workflows |
| Restriction | What it blocks | How to work around it |
|---|---|---|
| Module signing enforced | Unsigned DKMS modules, custom drivers | Sign with the kernel’s sign-file tool using the MOK key from /etc/secureboot/keys/ |
Lockdown integrity + CONFIG_DEVMEM not set | /dev/mem I/O regions, unsigned kexec | Live memory acquisition: use LiME with signed module |
| dmesg restricted | Casual kernel log reading | journalctl -k with appropriate privileges |
| kptr fully hidden | /proc/kallsyms from all users | Kernel debugging: use linux-aegis-offensive for development work |
| perf restricted to CAP_PERFMON | Unprivileged perf, hashcat perf counters | Run as root or grant CAP_PERFMON capability |
linux-aegis-offensive compiles lockdown support in but defaults to none in normal boot. You can tighten it without rebooting (one-way ratchet - cannot be loosened without reboot):
# Temporarily enable lockdown on the offensive kernelecho integrity > /sys/kernel/security/lockdownModule signing on linux-aegis-offensive can be toggled per-boot via kernel parameter (MODULE_SIG is compiled in but MODULE_SIG_FORCE is not):
# In bootloader entry - enforce signing for a specific bootmodule.sig_enforce=1Linux Aegis and athena-settings are complementary and independent. The kernel handles what is static and determined at compile/boot time. athena-settings handles what is dynamic and changes per session or per engagement.
| Concern | linux-aegis-offensive / linux-aegis-hardened | athena-settings |
|---|---|---|
| Module signing enforcement | ✅ | ❌ |
| Memory hardening (KASLR, stack protectors) | ✅ | ❌ |
| WiFi injection capability | ✅ | ❌ |
| BORE scheduler availability | ✅ | ❌ |
| I/O scheduler assignment per drive | ❌ | ✅ udev rules |
| ZRAM configuration and priority | ❌ | ✅ zram-generator |
| Sysctl tuning (swappiness, dirty bytes, etc.) | ❌ | ✅ 70-athena-settings.conf |
| Wireless regulatory domain | ❌ | ✅ iw-set-regdomain |
| MAC address randomization | ❌ | ✅ NetworkManager config |
| Firewall and VPN enforcement | ❌ | ✅ user-configured |
| Audio power management | ❌ | ✅ udev rules |
| THP defragmentation policy | ❌ | ✅ tmpfiles.d |
A user running linux-aegis-hardened still needs athena-settings for ZRAM, sysctl tuning (including the vm_swappiness override from the aggressive default value), the regulatory domain, and engagement-mode networking. The kernel and settings package together form a complete, coherent system - one handling the performance and capability foundation at compile time, the other handling dynamic system tuning and operational security at runtime.
Each kernel variant maps directly to documented threat models in the Athena OS documentation. This is intentional - the kernel choice is a security decision and should be made consciously.
linux-aegis-offensive
Matches: Offensive Researcher, CTF Player
“You are the threat. Your tools need full kernel capability. You accept that root can do anything, because you are root.”
Use when:
linux-aegis-hardened
Matches: Paranoid Professional, Daily Driver
“You carry client data. Your machine is a target. You need pentesting capability without sacrificing the machine’s own integrity.”
Use when:
See the Athena OS Threat Model for complete scenario-based guidance.
Aegis (ἀιγίς) - in Greek mythology, the divine shield carried by Zeus and Athena. It represented both inviolable protection and the authority to project overwhelming force. The name reflects the dual nature of this kernel: one variant strips away protection to maximize offensive capability, the other applies it fully to protect the operator in the field. Both are aspects of the same shield.