add section on clearing sensitive data from memory
This commit is contained in:
parent
346a47be6b
commit
44a35f8b99
@ -110,6 +110,7 @@
|
|||||||
<li><a href="#supports-longer-passwords">Supports longer
|
<li><a href="#supports-longer-passwords">Supports longer
|
||||||
passwords</a></li>
|
passwords</a></li>
|
||||||
<li><a href="#auto-reboot">Auto reboot</a></li>
|
<li><a href="#auto-reboot">Auto reboot</a></li>
|
||||||
|
<li><a href="#clearing-sensitive-data-from-memory">Clearing sensitive data from memory</a></li>
|
||||||
<li><a href="#duress">Duress PIN/Password</a></li>
|
<li><a href="#duress">Duress PIN/Password</a></li>
|
||||||
<li><a href="#more-secure-fingerprint-unlock">More secure fingerprint
|
<li><a href="#more-secure-fingerprint-unlock">More secure fingerprint
|
||||||
unlock</a></li>
|
unlock</a></li>
|
||||||
@ -819,6 +820,37 @@
|
|||||||
panic which leads to a reboot.</p>
|
panic which leads to a reboot.</p>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
<section id="clearing-sensitive-data-from-memory">
|
||||||
|
<h3><a href="#clearing-sensitive-data-from-memory">Clearing sensitive data from memory</a></h3>
|
||||||
|
|
||||||
|
<p>As documented in our section on <a href="#exploit-mitigations">our added
|
||||||
|
exploit mitigations</a>, GrapheneOS adds zeroing of freed memory to both the
|
||||||
|
standard userspace and kernel allocators. These features have the secondary
|
||||||
|
benefit of clearing sensitive data from memory as soon as possible in addition
|
||||||
|
to defending against exploits. Android implements regular compaction of frozen
|
||||||
|
cached apps and apps currently running in the background based on triggering a
|
||||||
|
full compacting garbage collection (GC) and then requesting that malloc frees as
|
||||||
|
much memory as it can back to the OS. This pairs well with zeroing features and
|
||||||
|
results in freed data getting cleared faster for Java/Kotlin and also the C, C++
|
||||||
|
and Rust libraries used by them where low-level allocators get held onto until
|
||||||
|
the high level objects are freed.</p>
|
||||||
|
|
||||||
|
<p>When the device is locked, we trigger full compacting garbage collection (GC)
|
||||||
|
for the SystemUI and system_server processes to release all of the memory that's
|
||||||
|
no longer used back to the OS. Due to GrapheneOS enabling kernel page allocator
|
||||||
|
zeroing, this results in all the no longer referenced data in objects being
|
||||||
|
cleared. We based our approach on Android's standard approach to running a full
|
||||||
|
compacting GC for these two processes after the device is unlocked to clear
|
||||||
|
remnants of the user's PIN/password and keys derived from it. This is a nice way
|
||||||
|
to clear some data immediately after locking prior to our
|
||||||
|
<a href="#auto-reboot">auto-reboot</a> feature kicking in to clear all of the OS
|
||||||
|
memory.</p>
|
||||||
|
|
||||||
|
<p>GrapheneOS modifies some of the ways the device can be rebooted to proceed
|
||||||
|
with the normal reboot process where memory gets freed and cleared by the kernel
|
||||||
|
page and slab allocator zeroing features enabled by GrapheneOS.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section id="duress">
|
<section id="duress">
|
||||||
<h3><a href="#duress">Duress PIN/Password</a></h3>
|
<h3><a href="#duress">Duress PIN/Password</a></h3>
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user