Bug: 26778031
Test: Boots, reboots, sector 0 of userdata encrypted
Make sure an FDE device, both default and password protected,
boots.
Make sure an FBE device without metadata encryption boots.
Change-Id: Ic44a32ce7e9b978e9c9e2dc112b26206741c838d
Support encrypting metadata in /userdata using the dm-default-key
driver with a key in the /metadata partition.
Bug: 29189559
Test: Angler & Marlin build and boot
Change-Id: I716b117508d4bb4f6a4039293acb848cbc60f67b
The keyname binded to keyring return a wrong string when there are binary char larger than 127,
the sign extension will introduce unexpect FFFFFF string to the keyname.
Bug: 36975893
Test: local build
Change-Id: Iba2f6ef95aeacd08c8d6c72b71e7b92e956ec3fc
Signed-off-by: Ai, Ting A <ting.a.ai@intel.com>
This reverts commit 6abe6831b5.
Bringing this back temporarily for the same issue on sdcardfs.
Will remove once the kernel issue is resolved.
Change-Id: Ia29ea4fddb7777012a2eea9259f9ac856773fe01
Bug: 37231161
Test: Boot device with FBE enabled. ls /storage/emulated/0/Android
Unlock device. ls /storage/emulated/0/Android
1st will not be found. Second should be found.
Select whichever is real dir instead of symbolic link from either /data/data
or /data/user/0. This is to minimize path walking overhead in kernel.
This works together with Change 369787
Test: Manual test
Change-Id: I338518673fc22ccbfed6ddd6be196931fce18525
Signed-off-by: cjbao <cathy.bao@intel.com>
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
