tree 5bae734dcf1645e57ac61c970e9a26becfacf08f
parent e6c142174c51ebecd3d451bd92482af6709f3d35
author Eric Biggers <ebiggers@google.com> 1491259689 -0700
committer Paul Crowley <paulcrowley@google.com> 1491344724 +0000

vold: unlink ext4 encryption keys rather than revoking them

Unlinking keys rather than revoking them avoids bugs in certain kernel
versions without having to hack around the problem with an arbitrary 20
second delay, which is not guaranteed to be sufficient and has caused
full device hangs like in b/35988361.

Furthermore, in the context of filesystem encryption, unlinking is not
currently supposed to be any less secure than revoking.  There was a
case where revoking (but not unlinking) keys will cause the filesystem
to deny access to files that were previously opened with that key.
However, this was a means of _access control_, which encryption is not
intended to be used for.  Instead, file permissions and/or SELinux
should be used to enforce access control, while filesystem encryption
should be used to protect data at rest independently from access
control.  This misfeature has also been removed upstream (and backported
to 4.4-stable and 4.9-stable) because it caused CVE-2017-7374.

Eventually we'd really like to make the kernel support proper revocation
of filesystem encryption keys, i.e. fully clearing all key material and
plaintext and safely waiting for any affected filesystem operations or
writeback to complete.  But for now this functionality does not exist.
('sync && echo 3 > /proc/sys/vm/drop_caches' can be useful, but it's not
good enough.)

Bug: 35988361
Change-Id: Ib44effe5368cdce380ae129dc4e6c6fde6cb2719
(cherry picked from commit fd7ba5e4c61691d8a45bc729b7659940a984bab0)