Sadly setexeccon() is process global, so we need to carefully ensure
that all exec() are mutually exclusive to avoid transitioning into
unwanted domains. Also, because we have several threads floating
around, we need to guard all our FDs with O_CLOEXEC.
Format all newly created volumes immediately after partitioning,
but silence all events emitted from those volumes to prevent the
framework from getting all excited. Unify all notify events under a
single codepath to make them easy to silence.
Sent SIGINT before escalating to SIGTERM when unmounting.
Bug: 19993667
Change-Id: Idc6c806afc7919a004a93e2240b42884f6b52d6b
This adds support for private volumes which is just a filesystem
wrapped in a dm-crypt layer. For now we're using the exact same
configuration as internal encryption (aes-cbc-essiv:sha256), but we
don't store any key material on the removable media. Instead, we
store the key on internal storage, and use the GPT partition GUID
to identify which key should be used.
This means that private external storage is effectively as secure as
the internal storage of the device. That is, if the internal storage
is encrypted, then our external storage key is also encrypted.
When partitioning disks, we now support a "private" mode which has
a PrivateVolume partition, and a currently unused 16MB metadata
partition reserved for future use. It also supports a "mixed" mode
which creates both a PublicVolume and PrivateVolume on the same
disk. Mixed mode is currently experimental.
For now, just add ext4 support to PrivateVolume; we'll look at f2fs
in a future change. Add VolumeBase lifecycle for setting up crypto
mappings, and extract blkid logic into shared method. Sprinkle some
more "static" around the cryptfs code to improve invariants.
Bug: 19993667
Change-Id: Ibd1df6250735b706959a1eb9d9f7219ea85912a0
Wire up new Disk and VolumeBase objects and events to start replacing
older DirectVolume code. Use filesystem UUID as visible PublicVolume
name to be more deterministic.
When starting, create DiskSource instances based on fstab, and watch
for kernel devices to appear. Turn matching devices into Disk
objects, scan for partitions, and create any relevant VolumeBase
objects. Broadcast all of these events towards userspace so the
framework can decide what to mount.
Keep track of the primary VolumeBase, and update the new per-user
/storage/self/primary symlink for all started users.
Provide a reset command that framework uses to start from a known
state when runtime is restarted. When vold is unexpectedly killed,
try recovering by unmounting everything under /mnt and /storage
before moving forward.
Remove UMS sharing support for now, since no current devices support
it; MTP is the recommended solution going forward because it offers
better multi-user support.
Switch killProcessesWithOpenFiles() to directly take signal. Fix
one SOCK_CLOEXEC bug, but SELinux says there are more lurking.
Bug: 19993667
Change-Id: I2dad1303aa4667ec14c52f774e2a28b3c1c1ff6d
ioctl(BLKGETSIZE) expects unsigned long
(8 bytes on 64 bit environment).
This is fixing fails in android.os.storage.StorageManagerIntegrationTest
(in FrameworkCoreTests).
To verify, install FrameworksCoreTests.apk and do:
adb shell am instrument -r -w -e class android.os.storage.\
StorageManagerIntegrationTest#testMountSingleEncryptedObb \
com.android.frameworks.coretests/android.test.InstrumentationTestRunner
Change-Id: Ib6d5c7490c02521c93f107c35ad0aac49f6a3f1a
Redirect all crypto calls to e4crypt equivalents if file level encryption
detected. Note this change implements only the ones needed for minimal
functionality.
Requires matching change:
https://googleplex-android-review.git.corp.google.com/#/c/642778/
Change-Id: I622d1a91704de4b3ab655486e6d38cd6718e6016
Redirect all crypto calls to e4crypt equivalents if file level encryption
detected. Note this change implements only the ones needed for minimal
functionality.
Requires matching change:
https://googleplex-android-review.git.corp.google.com/#/c/642778/
Change-Id: I622d1a91704de4b3ab655486e6d38cd6718e6016
This is to accomodate the new keymaster1_device_t, which has an entirely
different interface.
Soon I'll provide a libkeymaster which provides a unified (and nicer)
interface for dealing with both v0 and v1 keymaster implementations
using a v1 keymaster API. For now this change is just so that vold will
build and run.
Change-Id: I5c54282c12d1c4b8b22ed4929b6e6c724a94ede4
This is to accomodate the new keymaster1_device_t, which has an entirely
different interface.
Soon I'll provide a libkeymaster which provides a unified (and nicer)
interface for dealing with both v0 and v1 keymaster implementations
using a v1 keymaster API. For now this change is just so that vold will
build and run.
Change-Id: I5c54282c12d1c4b8b22ed4929b6e6c724a94ede4
Changing the device lock (even from swipe to none) will cause the
master key to be re-encrypted.
If at that point keymaster fails (e.g. due to an incompatible keymaster update)
cryptfs will write back the now-incomplete crypto metadata.
Upon next reboot, userdata can't be decrypted.
Now we don't bother writing on keymaster failure.
Bug: 19301883
Change-Id: I2b9a1278f8b4d333ac8d567e17e2263005e99409
This reverts commit 6a69cfc411.
The original fix seems to have led to boot failures in QA. Rather than
risk shipping, revert the change. Bug 18764230 reopened.
Requires change
https://googleplex-android-review.git.corp.google.com/#/c/629950/
Bug: 19278390
Bug: 19199624
Change-Id: Ia858c4db0abb917f9364ec8048f59ca4fb48e233
The strncpy operation does not write a 0 termination
if the name is larger than the target buffer.
Ensure that zero termination is always written using
safe strlcpy function.
Change-Id: Idb68cdff7cd1a860c1dfac7494fa99f3d382cb91
Using lseek on 64-bit offset parameter caused failure
to write persistent data in crypto footer.
Changed calls to use lseek64 instead.
Change-Id: I4e4c397a6d36201b8b08be3017e17c9fac3b34e4
The structure crypt_persist_data was allocated,
but never freed.
Added free of allocated memory in normal and
error case.
Change-Id: I9aaa067e6f6501e8ce007f8659004b5dbcf2b246
Add maybeenabledefaultencryption function, that encrypts based
on the encryption flag and appropriate environment variable
Bug: 18764230
Change-Id: Id9a1967d09a7ae63a51240c0a5f3c41505af0e9a
The libcrypto and libssl modules (and their respective static and host
versions) use LOCAL_EXPORT_C_INCLUDE_DIRS thus just including the module
is sufficient.
Additionally, cryptfs.h was including an OpenSSL header just to get the
length of a SHA-256 hash. Rather than force all users of this header to
also depend on libcrypto, it's easier just to define that value in the
header file.
Change-Id: I3e3e0db906a212e1093944b298e4a8ff2e2fb07d
Add maybeenabledefaultencryption function, that encrypts based
on the encryption flag and appropriate environment variable
Bug: 18764230
Change-Id: Id9a1967d09a7ae63a51240c0a5f3c41505af0e9a
Since the dm_ioctl struct was being allocated on the stack as a large
character array, it was getting character alignment rather than the
proper alignment for the struct. GCC had been getting away with this
so far, but it's undefined behavior that clang managed to expose.
Bug: 18736778
Change-Id: Ied275dfad7fcc41d712b2d02c8a185f499221f57
-Wno-missing-field-initializers is used as well, but that is an
overzealous warning from initializing structs with {0} and not a
real warning.
bug 18736778 and 16868177
Change-Id: Iffde89cd7200d9a11193e1614f1819f9fcace30a
encrypt-and-wipe was broken when checks were added that encryption succeeded
which assumed a 'normal' full encrypt traversing the device.
encrypt-and-wipe doesn't traverse, it just lays down a file system over
the encrypted device, so in this mode do not check the amount encrypted -
it will always be 0.
Bug: 18511900
Change-Id: Icb1d7e0cdb67abd2eac0ab3cbfc1a88912768f9d
Devices already encrypted with aes-cbc-essiv:sha256 will continue to be
decrypted in software, until a factory data reset. New devices that
implement CONFIG_HW_DISK_ENCRYPTION will switch to aes-xts.
b/17475056 Enable hardware crypto for userdata encryption
Change-Id: I62d1583bdaf7ff06b87e386e758fa3b18c719bca
Signed-off-by: Iliyan Malchev <malchev@google.com>
Currently Android provides disk encryption support using dm-crypt
which is based on bios. dm-crypt uses 512 bytes packet size for
crypto operations. While 512 bytes size packet is ok for SW based
disk encryption, it is inefficient for HW based crypto engines.
dm-req-crypt is similar to dm-crypt except it uses block requests
rathe bios for crypto operations. block requests when unpacked
carries data upto 512KB. Hence, HW based crypto engine can be used
more efficiently.
Also move create disk encryption key before framework start as
HW based disk encryption creates key in secure side. Key creation
can take sometime to create the key securely. If framework is
started before creating the key, it is possible that framework
requests service from secure side. Secure side can serve mostly one
request at a time. Secure side may reject framework request if key
creation request is still going on. This may cause problem in the
system
b/17475056 Enable hardware crypto for userdata encryption
Change-Id: I5480ab72a37c02532218a18faaba598a824589fd
Signed-off-by: Iliyan Malchev <malchev@google.com>
vold should only use hardware keymaster implementations to protect the
disk encryption key, because there's little value in using the software
implementation. More importantly, if we allow vold to use softkeymaster
in the absence of a HW keymaster and (somehow) a HW keymaster is added
to a device, the HW version will be loaded, and will be unable to use
the softkeymaster key found in the crypto footer, forcing a factory
reset.
This CL will not break devices without HW keymaster, because
softkeymaster currently reports its keys as non-standalone (which isn't
correct). After this CL is in, I will fix softkeymaster.
Bug: 17362157
Change-Id: I98b169e7a59ff7d44b72069b87743463ec823ea2
Store long field values in multiple underlying fixed-length entries
and concatenate them together when reading back.
Bug: 17556485
Change-Id: I2f8033d18c208993fa1b010712be0dad5d8b646b
