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 fd7ba5e4c6)
init reads files in /data/property/ but it is not ready to read when
trigger_load_persist_props is triggered by vold.decrypt.
Bug: 29332975
Change-Id: I14beac8714ff2f722d8b11f666bc7ca693ccd46e
(cherry picked from commit e2ef0c0da4)
Otherwise we potentially waste minutes of the users time copying
data that will never fit.
Also fix bug around storage calculation. It's confusing, but f_bsize
is not the value you're looking for; the real block size is f_frsize.
Test: builds, boots
Bug: 27590986, 36840579
Change-Id: I77c63e259356824cc75a3adcf3f4af567efdc7aa
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.)
Change-Id: Ib44effe5368cdce380ae129dc4e6c6fde6cb2719
Init is no longer calling vdc with logwrapper, so it must take care of
logging to kmsg directly.
Bug: 36278706
Test: observe logging in kmsg on boot and stderr on normal usage
(cherry picked from commit f71511ac41)
Change-Id: Ieb643918f11bdde4f99ec7f3ec083efbb326e809
Init is no longer calling vdc with logwrapper, so it must take care of
logging to kmsg directly.
Test: observe logging in kmsg on boot and stderr on normal usage
Change-Id: Ie3e59da433bd154f121ce103dea0c59eb0bab069
Start with clang-analyzer-security* and cert-*, but disable two
specific errors:
-- cert-err34-c, which checks for atoi(); heavily triggered by
CommandListener, but will disappear when we move to Binder.
-- cert-err58-cpp, which checks for exceptions before main(); it's
a "Low" severity issue, and filed 36656327 to track cleanup.
Fix all other triggered errors along the way.
Test: builds, boots
Bug: 36655947
Change-Id: I1391693fb521ed39700e25ab6b16bc741293bb79
Also remove some unnecessary SELinux logic when creating image files
for loop devices.
Test: builds, boots, common operations work
Bug: 34903607
Change-Id: I68dfa022ecc39f56c175e786694e0de35b954ca0
It's extremely difficult to test storage related logic on devices
that don't have physical SD card slots. So to support better
debugging and testing, add a new "virtual disk" feature which mounts
a 512MB file through loop device.
It relies on the kernel having the "loop.max_part" value set to
something other than 0 via the boot command line, since that allows
all the existing partition logic to fall into place.
Bug: 34903607
Test: builds, boots, virtual disk works
Change-Id: I04c5b33e37319d867542985a56b7999a9b7cf35d
- In new shutdown sequence, volume shutdown is requested in two places:
system_server and init.
- Make VolumeManager.shutdown safe for double calls.
It crashed before this change.
bug: 36004738
Test: reboot and check last_kmsg for crash / vdc timeout
Change-Id: I296913959b2647b65d66553073f2032545beba57
The original default /fstab.{ro.hardware} might be moved to /vendor/etc/.
or /odm/etc/. Use the new API to get the default fstab instead of using
the hard-coded /fstab.{ro.hardware}.
Bug: 35811655
Test: boot marlin with /vendor/etc/fstab.marlin
Change-Id: I92d6aefe6ff3433b7d1a671358d990bb7b1f2150
The compatibility check assumes that the keymaster session was created
successfully which is a faulty assumption.
This patch adds propper error handling to the check.
Bug: 35576166
Change-Id: I0c70a0e53f488f8bd3164898722f490cd0573ce3
coldboot is needed when device rebooted with USB device attched
so Vold netlink won't miss the information.
This CL added back coldboot and moved down so that it won't block
vold cl and ccl threads.
Bug: 36007238
Test: reboot marlin with flash drive attached and flash drive is recognized
Change-Id: Ie39f348e97a8500515e394e386541289a91b2425
We simplified the way we track whether or not a dex file is used by
other apps. DexManger in the framework keeps track of the data and we
no longer need file markers on disk.
Test: device boots, foreign dex markers are not created anymore
Bug: 32871170
Change-Id: Id0360205b019be92049f36eab4339f4736e974f4
Change to use WaitForProperty API to wait for vold.post_fs_data_done
Also change cryptfs to C++
Bug: 35425974
Test: mma, marlin/angler boot
Change-Id: Id821f2035788fcc91909f296c83c871c67571de3
The getService() and registerAsService() methods of interface objects
now have default parameters of "default" for the service name. HALs
will not have to use any service name unless they want to register
more than one service.
Test: marlin boots
Bug: 33844934
Change-Id: I7c68c8b9ab0101b2f10ca20b9971a5bd34377168
Eric Biggers
Seigo Nonaka
Jeff Sharkey
TreeHugger Robot
Tom Cherry
Jeff Sharkey
Shawn Willden
Keun-young Park
Bowgo Tsai
Janis Danisevskis
Wei Wang
Calin Juravle
Chris Phoenix
Rubin Xu
Isaac Chen