When running in a container, the process might be in a user/net
namespace, which would cause setting the SO_RCVBUFFORCE socket option to
fail with EPERM. But rmem_max is set to a high enough value which allows
SO_RCVBUF to succeed.
Bug: 62417946
Test: Run android in a new user and network namespace, vold does not
abort here.
Change-Id: I2b678ddd886a406a3394d9fdd33f9c8800ef78a3
Signed-off-by: Junichi Uekawa <uekawa@google.com>
(cherry picked from commit b41155d4af0e00fc6f65d7d67b80e7b866f847d6)
We don't know which FS and kernel version is going to want these keys,
so put them in the kernel three times with all three possible prefixes.
Bug: 62900873
Test: Marlin set up before this change successfully boots after it.
Change-Id: I6ccfe0894551ba068de9bf5e23fe4fd1e10e36b1
We have android::base::WaitForProperty() that uses futexes to
efficiently wait for property value changes, so use that instead
polling.
Test: Boot bullhead
Change-Id: Id964eddbdbfd9b5ceac5ed83a8ed66b9e60008ca
* Owners are selected from top CL approvals or owners.
They will be suggested to review/approve future CLs.
* OWNERS files are recognized by the new find-owners plugin, see .md files in
https://gerrit.googlesource.com/plugins/find-owners/+/master/src/main/resources/Documentation/
Test: build/make/tools/checkowners.py -c -v OWNERS
Change-Id: I4d0431105b55e88be258800a7fd45a42deb9bb60
This is used by LockSettingsService to delete sensitive credential files.
Bug: 34600579
Test: manual - change device lock under synthetic password, verify
old data on disk is erased.
Change-Id: I5e11b559ad8818bd2ad2b321d67d21477aab7555
Merged-In: I5e11b559ad8818bd2ad2b321d67d21477aab7555
Was depending on this transitively from MQDescriptor.h
Test: links
Bug: 37791060
Change-Id: I9b52bbe9ac6c3a54fdb6e352e90eba50914633d4
(cherry picked from commit 25e8b4b4f6)
This reverts commit 8ad0bef7b5.
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.
Change-Id: I92c7ad0adaa7bd357e10661a47cc667ac0ff84b4
Merged-In: I92c7ad0adaa7bd357e10661a47cc667ac0ff84b4
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)
