security/hakurei.app
security/hakurei.app
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

document minor restored kernel hardening features

Browse Source
This commit is contained in:
Daniel Micay 2022-10-29 03:53:57 -04:00
parent 53c6cdf17a
commit 45ff49c34d
1 changed files with 34 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
static/features.html
View File

@ -310,31 +310,40 @@
<li> <li>
Hardened kernel Hardened kernel
<ul> <ul>
<li>4-level page tables are enabled on arm64 to provide a much larger <li>4-level page tables are enabled on arm64 to provide a much
address space (48-bit instead of 39-bit) with significantly higher larger address space (48-bit instead of 39-bit) with
entropy Address Space Layout Randomization (33-bit instead of significantly higher entropy Address Space Layout
24-bit).</li> Randomization (33-bit instead of 24-bit).</li>
<li>Random canaries with a leading zero are added to the kernel heap <li>Random canaries with a leading zero are added to the
(slub) to block C string overflows, absorb small overflows and detect kernel heap (slub) to block C string overflows, absorb small
linear overflows or other heap corruption when the canary value is overflows and detect linear overflows or other heap corruption
checked (on free, copies to/from userspace, etc.).</li> when the canary value is checked (on free, copies to/from
<li>Memory is wiped (zeroed) as soon as it's released in both the userspace, etc.).</li>
low-level kernel page allocator and higher level kernel heap allocator <li>Memory is wiped (zeroed) as soon as it's released in both
(slub). This substantially reduces the lifetime of sensitive data in the low-level kernel page allocator and higher level kernel
memory, mitigates use-after-free vulnerabilities and makes most heap allocator (slub). This substantially reduces the lifetime
uninitialized data usage vulnerabilities harmless. Without our of sensitive data in memory, mitigates use-after-free
changes, memory that's released retains data indefinitely until the vulnerabilities and makes most uninitialized data usage
memory is handed out for other uses and gets partially or fully vulnerabilities harmless. Without our changes, memory that's
overwritten by new data.</li> released retains data indefinitely until the memory is handed
<li>Kernel stack allocations are zeroed to make most uninitialized out for other uses and gets partially or fully overwritten by
data usage vulnerabilities harmless.</li> new data.</li>
<li>Assorted attack surface reduction through disabling features or <li>Kernel stack allocations are zeroed to make most
setting up infrastructure to dynamically enable/disable them only as uninitialized data usage vulnerabilities harmless.</li>
needed (perf, ptrace).</li> <li>Assorted attack surface reduction through disabling
<li>Assorted upstream hardening features are enabled, including many features or setting up infrastructure to dynamically
which we played a part in developing and landing upstream as part of enable/disable them only as needed (perf, ptrace).</li>
our linux-hardened project (which we intend to revive as a more active <li>Assorted upstream hardening features are enabled,
project again).</li> including many which we played a part in developing and
landing upstream as part of our linux-hardened project (which
we intend to revive as a more active project again).</li>
<li>Forced kernel module signing with per-build keys and
lockdown mode set to forced confidentiality mode help to
enforce a low-level boundary between the kernel and userspace
even if mistakes are made in SELinux policy or there's a deep
userspace compromise.</li>
<li>Additional consistency / integrity checks are enabled for
frequently targeted kernel data structures.</li>
</ul> </ul>
</li> </li>
<li>Android Runtime Just-In-Time (JIT) compilation/profiling is fully <li>Android Runtime Just-In-Time (JIT) compilation/profiling is fully