For adoptable storage and FBE to coexist we need a new dm-biocrypt
kernel feature which isn't ready yet. So for now, prevent devices
from being adopted on FBE devices.
Bug: 30770036
Change-Id: I47639209161ee403ce13ea9a60da235e97c3fc30
(cherry picked from commit 1571751109)
Ephemeral users don't have keys stored on disk at all, so it's neither
necessary nor possible to manipulate the disk keys here.
Bug: 30038313
Change-Id: Idc7ec1bfe1e8a6ffa6cee2f284dbe378097b08da
On FBE devices, the filenames inside credential-encrypted directories
are mangled until the key is installed. This means the initial
restorecon at boot needs to skip these directories until the keys
are installed.
This CL uses an existing facility to request that init run a
recursive restorecon over a given path, and it requests that
operation for the CE directories that would have been omitted by
the SKIPCE flag earlier during boot.
Bug: 30126557
Change-Id: I8c7abea27215075a091f615a7185a82a2f4a4a95
Don't rely on cryptographic binding of secdiscard to key; securely
delete the other information needed to reconstruct the key too.
Bug: 26021231
Change-Id: If03d2c051b0ec2fdcb5c6f70bde7e3287424f216
On a device where we can't BLKSECDISCARD sectors, we "overwrite" them
with zeroes. This changes the FTL to remap those sectors to new
locations. With this done, the old contents are accessible only given
a compromise of flash firmware or a die level attack.
Bug: 26021231
Change-Id: Ia065921389886fac1ba456c19c138187237c2561
When "migrating" data failes due to insufficient space
at target location, the data copied so far is left in
target location, which in practice is now filled to the
brim.
If copy fails clean up the data copied so far since user
has the data in original location.
Bug: 26322200
Change-Id: Iab29a7f9e653e6857ee0e2723d151dfec81b14dd
Sometimes migrating data fails to mount the target
volume after operation is finished.
MoveTask is running in its own thread, copying data
between external card and internal memory.
After copying the data the method "bringOnline" is
run. This method destroys and creates the volumes.
When VolumeBase::create() is run it will notify
MountService, who upon receiving this notification
will send a mount command to mount the new primary
storage.
This command will sometimes run before
setState(State::kUnmounted); is called on the newly
created volume. This will cause the mount command to
fail.
VoldConnector: SND -> {10 volume mount emulated 3 -1}
vold : emulated flags change requires state unmounted or unmountable
vold : emulated user change requires state unmounted or unmountable
vold : emulated mount requires state unmounted or unmountable
Lock bringOnline so no volume commands will be processed
until volumes are (re-)created and have correct state.
Bug: 26322200
Change-Id: I4aba85c226d904c42ae9edcdfec21619218939d6
This had minimal impact on the results, since 95% of the writes were
performed through pwrite(), but it's important to fix this for future
benchmark suites.
Bug: 29759783
Change-Id: Ic628aab98b9f9def78508cc722899afdefed84ae
am: a363036b44
* commit 'a363036b44f7f140aa9a943578f56abff5880a60':
Two phases to set the password for disk encryption
Change-Id: Ia28823079d8c0bda220238339f28095b234a0ae5
Revert "Revert "Two phases to set the password for disk encryption""
This reverts commit d402389290.
In addition, fix the bug in the original commit.
Bug: 28154455
Bug: 28694324
Change-Id: I885f1d73e739416347c135d79979941c2bbdbe62
am: cfa03d4a4c
* commit 'cfa03d4a4c53acf41dca2c41a2efd00de06043bb':
e4crypt_is_native has been moved into system/extras.
Change-Id: I345475c44fb2d8812a25c9f2195c748cddc55bfe
am: d402389290
* commit 'd402389290eeef86be7eb9241e20fdd125d44eb1':
Revert "Two phases to set the password for disk encryption"
Change-Id: I53a3804fc7bff9c99840aeee36fc4b7ff8e46ac1
am: 92c5eeb467
* commit '92c5eeb46779f0fa1c9e6db6b0d632d960cbb2e4':
Two phases to set the password for disk encryption
Change-Id: I82c1cfa2874ac4709e42f5c2047c832cbcaccb91
In one phase, we make the new password work, and in the second we make
it the only one which works ("fixation"). This means that we can set
the password in Gatekeeper between these two phases, and a crash
doesn't break things. Unlocking a user automatically fixates the
presented credential.
Bug: 28154455
Change-Id: I54623c8652f0c9f72dd60388a7dc0ab2d48e81c7
am: b3de337
* commit 'b3de337acd7ad07de1ed30d24fdfd628d1d8590b':
Use a longer timeout on the disk encryption keys
Change-Id: Ieadec9da13383361ac76bf6b79ecea948965a1d9
Avoid a timeout error by extending the time allowed between getting
the auth token and decrypting the key from five to thirty seconds.
Bug: 28398766
Change-Id: I1dbb9e0e33707e7de4c1720ad1b8e153c77094b2
The old way (using triggers) starts defaultcrypto twice because
queue_property_triggers_action retriggers the action.
Bug: 27452459
Change-Id: I715d5441f8ae0b820b680f6a75f51694c4420992
Preparing and destroying users currently needs to be split across
installd, system_server, and vold, since no single party has all the
required SELinux permissions.
Bug: 27896918, 25861755
Change-Id: Ieec14ccacfc7a3a5ab00df47ace7318feb900c38
Users don't have to be unlocked to be deleted, so don't worry if we
don't have their key to evict.
Bug: 26847403
Bug: 27441228
Change-Id: Ifd93f620926630aa102a3bb4a5d2d45d34f9b75d