The dm-crypt solution requires a kernel patch that won't be present in
the GKI kernel, while the new metadata encryption system in the GKI
kernel solves this problem in a much cleaner way.
Test: create private volume on Cuttlefish, setting property both ways.
Bug: 147814592
Change-Id: Ie02bd647c38d8101af2bbc47637f65845d312cea
metadata_encryption fstab option provides details on the cipher
and flags used for metadata encryption. wrappedkey_v0 is provided
to dm-default-key dm device when a wrapped key is used. The
inline encryption hardware unwraps the key and derives the
encryption key used to encrypt metadata without returning the key
in the clear to software.
Bug: 147733587
Test: FBE with metadata encryption using wrapped keys.
Change-Id: Ibf69bdc12bb18d2f0aef8208e65f3a8dececfd2a
No need for KeyUtil to know how to make a KeyGeneration, it's cleaner
if each module handles it separately. Also, create a CryptoOptions
structure to track metadata encryption options, and simplify legacy
cipher/option handling.
Test: Treehugger
Bug: 147814592
Change-Id: I740063882914097329ff72348d0c0855c26c7aab
Since installers can create directories in Android/obb, make sure those
directories end up with the correct ACL bits as well.
Bug: 146419093
Test: inspect filesystem manually
Change-Id: I211e921197560a40599938463f3171a0ff92d9aa
We want subdirectories of Android/data, Android/obb etc. to
automatically maintain their group-id.
Bug: 146419093
Test: manual inspection of /sdcard/Android
Change-Id: I36883febb01aa155dfafb0e86f8b99223cde9815
For some reason this can be racy; until we understand the root cause,
retry to unblock AdoptableHostTest.
Bug: 149396179
Test: atest AdoptableHostTest no longer hangs
Change-Id: I162ff8ad305535e7a4fab3d88f38b687b50cf4a3
More consistency between MetadataCrypt and cryptfs, and steps towards
supporting Adiantum properly in MetadataCrypt.
Test: create private volume on Cuttlefish
Bug: 147814592
Change-Id: Ic3993c1fde11b4f5a9e6cc8ee588a7d92241c6ab
Initially, we were thinking to pass kInternal for non usb drive/sd card
drive (for local external storage like directory shared from ChromeOS).
Fortunately, the DocumentsUI logic apparently has TYPE_LOCAL with
R.drawable.ic_root_smartphone (that is overlayable) for external storage
other than TYPE_USB and TYPE_SD.
Therefore, instead of creating a kInternal flags, we can just passed kUsb
and kSd and not passing anything for "internal external storage" - which
will render ic_root_usb, ic_root_sd, and ic_root_smartphone as icons
accordingly. And since ic_root_smartphone is already overlayable, we
could overlayed in /vendor - which effectively is what we initially
wanted when thinking of introducing kInternal flag.
Bug: 132796154
Test: Customize flags in /vendor for different devices and DocumentsUI
shows the ic_root_smartphone (which can be overlayed) when kUsb is not
passed, and USB icon when kUsb is passed.
Change-Id: I55f13e214bbb2aeed96b6950bcf391121174c354
This was hard to read and understand. Instead, fall back to explicit
string operations with more comments on what we're doing and what we're
allowing.
This also fixes an issue where apps were asking us to create dirs on
their behalf that our more than 2 levels deep, eg
com.foo/files/downloads ; I thought such paths weren't allowed, but
apparently they are (and there's no good reason for us to not set them
up correctly).
Bug: 149407572
Test: launch opera
Change-Id: I7c64831032b66e90960b96e41ee42c7d616a759c
For some reason this can be racy; until we understand the root cause,
retry to unblock presubmit.
Bug: 149396179
Test: atest AdoptableHostTest no longer hangs
Change-Id: I3fb4f1d966172bac2f6c52d41c4564f905765212
Abolish cryptfs_revert_ext_volume, handle in caller. This allows us to
use DeleteDeviceIfExists, avoiding a spurious error message.
Test: create private volume on Cuttlefish, eject, check logs
Bug: 147814592
Change-Id: I836d8bd11b29e32da0863aaa75144543bb9cab9c
Not for security, but for consistency with the way we handle other
keys, and to move the length check to where it belongs.
Test: create private volume on Cuttlefish
Bug: 147814592
Change-Id: I10fc4896183d050ce25ff174faf78f525cf62930
To prevent keys from being compromised if an attacker
acquires read access to kernel memory, some inline
encryption hardware supports protecting the keys in
hardware without software having access to or the
ability to set the plaintext keys. Instead, software
only sees "wrapped keys", which may differ on every boot.
'wrappedkey_v0' fileencryption flag is used to denote
that the device supports inline encryption hardware that
supports this feature. On such devices keymaster is used
to generate keys with STORAGE_KEY tag and export a
per-boot ephemerally wrapped storage key to install it in
the kernel.
The wrapped key framework in the linux kernel ensures the
wrapped key is provided to the inline encryption hardware
where it is unwrapped and the file contents key is derived
to encrypt contents without revealing the plaintext key in
the clear.
Test: FBE validation with Fscrypt v2 + inline crypt + wrapped
key changes kernel.
Bug: 147733587
Change-Id: I1f0de61b56534ec1df9baef075acb74bacd00758
We directly pass a reference to our std::string, instead of
forcing the creation of a temporary std::string from the
result of c_str().
Test: TreeHugger
Change-Id: Ibab13f1e1ff43af076df60ae4032bf9dd111dd27
