It will be used by userspace reboot to reset checkpoint state, to make
sure that when /data is remounted, it will be remounted in checkpointing
if a checkpoint was requested beforee userspace reboot.
Test: /system/bin/vdc startCheckpoint 1
/system/bin/vdc needsCheckpoint (returns 0)
/system/bin/vdc resetCheckpoint
/system/bin/vdc needsCheckpoint (returns 1)
Bug: 135984674
Change-Id: Ia29238686289b4eed93e2fb936a8b3d894b94dc9
Add support for setting v2 encryption policies when configured in the
fstab (for internal storage) or in system properties (for adoptable
storage), and for installing and evicting the keys for such policies.
v2 policies support the same encryption modes and flags as v1 policies,
but internally they use a more standard, secure, and flexible KDF. Due
to this, some future features will be supported by v2 policies only.
Bug: 140500999
Test: Configured a device to use v2 encryption policies (applied the
needed kernel patches and added
"fileencryption=aes-256-xts:aes-256-cts:v2" to fstab, and set the
corresponding system properties for adoptable storage). Wiped
userdata, booted device and checked logs to verify that v2
policies were being used.
Also enabled virtual SD card and formatted as adoptable storage;
verified it works and that v2 policies were being used on it.
Also created, started, and stopped a 2nd user and verified their
keys were evicted.
Also verified that the device comes up again after rebooting.
Also verified that a device using v1 encryption policies continues
to work, both with and without an updated kernel -- including
stopping a user so that their keys get evicted.
Change-Id: If64028d8580584b2c33c614cabd5d6b93657f608
When the kernel supports the new fscrypt key management ioctls, use them
instead of add_key() and keyctl_unlink().
This will be needed in order to support v2 encryption policies, since v2
encryption policies only support the new ioctls.
The new ioctls have other advantages too. For example,
FS_IOC_REMOVE_ENCRYPTION_KEY automatically evicts exactly the necessary
kernel objects, so the drop_caches sysctl is no longer needed. This
makes evicting keys faster and more reliable.
FS_IOC_REMOVE_ENCRYPTION_KEY also detects if any files are still open
and therefore couldn't be "locked", whereas this went undetected before.
Therefore, to start out this patch adds support for using the new ioctls
for v1 encryption policies, i.e. on existing devices.
(Originally based on a patch by Satya Tangirala <satyat@google.com>)
Bug: 140500828
Test: tested that a device using v1 policies continues to work, both
with and without an updated kernel. See
If64028d8580584b2c33c614cabd5d6b93657f608 for more details.
Also checked via the log that the filesystem-level keyring is in
fact used when supported.
Change-Id: I296ef78138578a3fd773797ac0cd46af1296b959
Before this, the FUSE daemon receives a setattr inode timestamp
request for every write request. This can be crippling for write
performance or read performance during writes especially random
writes where the write back cache does not effectively coagulate
requests.
We now add the MS_LAZYTIME mount flag
(http://man7.org/linux/man-pages/man2/mount.2.html) to lazily flush
the timestamp updates from memory to disk
Test: m
Bug: 135341433
Change-Id: I95a467d5682a325b4099f32634d93ed2921f815e
This will allow us to receive values from server flags and store them in
persist.sys.fuse without risking flag consistency during a boot.
Test: manual - flip persist.sys.fuse both ways and make sure FuseDaemon
works as expected.
Bug: 140803239
Change-Id: I839a1973c98b4eda982226d20be48d1c08e7464a
When mounting a FUSE device on /mnt/user/<userid>/<vol>,
bind mount the correspoinding lower filesystem path to
/mnt/pass_through/<userid>/<vol>. At Zygote fork time, an
app with the right privilege will have the pass_through path
bind mounted into /storage instead of the /mnt/user path.
This provides such an app direct access to the lower filesystem
without going through FUSE.
Bug: 140064376
Test: mount(8) shows /mnt/pass_through/0/emulated is a bind
mount of the lower fs
Change-Id: I32c3cad64138910fcec9fb8f66b206706b5fd139
am: 315855b541 -s ours
am skip reason: change_id I135099625f77344d1f8d2e8688735871c44ef2f5 with SHA1 9a6d1f73e5 is in history
Change-Id: Ic79d3e61e2167da5bcfcfaa08086ff9e6bcf5747
am: 1b535e41fd -s ours
am skip reason: change_id I135099625f77344d1f8d2e8688735871c44ef2f5 with SHA1 9a6d1f73e5 is in history
Change-Id: Ibfc9efb88aaac867a710529631a30fe33ba570d3
Current behavior:
Assume not checkpointing
cp_startCheckpoint creates the file in metadata
cp_needsCheckpoint will now set isCheckpointing to true
cp_commitCheckpoint will now think there is a checkpoint, and try to
commit it. This will fail on ext4 and it will return false, leading to
bad things.
cp_startCheckpoint is called when staging an apex module for update.
After this point, several things could go wrong:
If a keystore key is deleted, it calls cp_needsCheckpoint to see if the
delete should be deferred until cp_commitCheckpoint. The delete will now
be deferred, meaning that this key will never be deleted, using up the
key sots in trustzone
If a trim is scheduled through idle maintenance, this also calls
cp_needsCheckpoint, so the trims will not occur.
If either of these happens before a system crash, the device will not
recover since the system calls commitCheckpoint which will now crash.
When the system then goes on to reboot, the checkpoint will not be
triggered, since the commitCheckpoint call will have deleted the
checkpoint flag file before crashing.
Bug: 138952436
Test: vdc checkpoint startCheckpoint 5
vdc checkpoint needsCheckpoint
vdc checkpoint commitChanges
stop;start
commitChanges fails, then device loops
After applying this test, commitChanges succeeds and device does
not loop
Change-Id: I135099625f77344d1f8d2e8688735871c44ef2f5
Merged-In: I135099625f77344d1f8d2e8688735871c44ef2f5
am: a7e15f91ac -s ours
am skip reason: change_id I74077bf8f727dab726c25f512ed7406a74cbe0bf with SHA1 c8a3ef3f3c is in history
Change-Id: I86540b1256a24e61b0cf6979f540dd299c8af379
am: ccc84dec96 -s ours
am skip reason: change_id I74077bf8f727dab726c25f512ed7406a74cbe0bf with SHA1 c8a3ef3f3c is in history
Change-Id: I25f74556643e36061dd82c9947e1c5bd23563d13
Bug: 140882488
Test: Booted twice, checked logs to ensure encryption
is different each time, adb created files in directory.
Cherry-Picked-From: c8a3ef3f3c
Merged-In: I74077bf8f727dab726c25f512ed7406a74cbe0bf
Change-Id: I74077bf8f727dab726c25f512ed7406a74cbe0bf
Paul Lawrence
Nikita Ioffe
Xin Li
Eric Biggers
Tao Bao
Treehugger Robot
Daniel Rosenberg
Zim
shafik
Paul Crowley