Reference 1 Neverland: Lightweight Hardware Extensions for Enforcing Operating System Integrity.
Current solutions has draw backs:
Secure Boot is not enough to protect kernel from being tempered: attackers could exploit software vulnerabilities to perform malicious actions such as overwriting kernel memory, executing malware in kernel-mode, or disabling driver integrity checks (example attacks can be seen in [^c64] [^c8] [^c16] [^c41] [^c62] [^c54] [^c48] [^c44]).
Supervisor Mode Access/Execution prevention.
In kernel integrity monitor.
Continuous Integrity Monitor can be subverted if run at the same privilege level: a kernel bug has previously been exploited to bypass Microsoft’s Kernel Patch Protection (KPP) feature[^c1].
Protection mechanisms via virtualization support [^c17] [^c22] [^c33] [^c60] [^c55] [^c50] [^c12]: either in a hypervisor or in another separate virtualized operating system. E.G: Microsoft Windows 10 has adopted this approach to protect its driver and kernel integrity enforcement mechanisms[^c66].
Trusted execution environment. TrustZone, SGX. EG. Android devices commonly take advantage of TrustZone to isolate the kernel integrity mechanisms from the main kernel [^c5] [^c7].
However,
hardware based protection, zero runtime performance overhead.
During boot, neverland takes away the ability of OS to overwrite certain configuration registers and portions of the physical address space.
CPU configuration registers that store kernel entry points.
prevents the CPU from fetching kernel-mode code from any memory region lying outside the physical address assigned to the OS kernel and drivers, regardless of virtual page permissions.
hardware permission table to mark physical address space as read-only, executable, privileged, and locked. (Similar to ARM MPU, RISC-V PMP)
locked CPU configuration registers, to prevent system call/interrupt hijacking.
Kernel mode rootkits:
If you could revise
the fundmental principles of
computer system design
to improve security...
... what would you change?