Now that we're offering to store private app data on adopted storage
devices, the performance of those devices is much more important to
overall user experience.
To help set user expectations, this change offers to execute a
real-world benchmark on a storage device, returning a metric that can
be used to compare internal and external storage. The benchmark is
generated from the strace-instrumented storage access patterns of
typical apps.
A typical device completes the benchmark in under two seconds on
internal storage, a UHS-3 SD card is even faster (!), but a very slow
Class 4 SD card takes about 30 seconds to complete, giving us a clear
signal.
The measured benchmark numbers are logged along with information
about the storage device, such as manufacturer, model, etc. Card
serial numbers are scrubbed from output.
Bug: 21172095
Change-Id: I9b2713dafdfdfcf5d97bf1bc21841f39409a7e54
We eventually should move back to per-disk locks, but use a giant
lock to keep development rolling forward. Also move force adoptable
flag to framework since, since encrypted devices don't have persisted
properties loaded early during boot.
Bug: 19993667
Change-Id: Ifa3016ef41b038f8f71fc30bc81596cfd21dcd2a
This is cleaner and more direct than the reverse of having the disk
publish child volume membership. Rename state constants to match
public API. Add state representing bad removal. Make it clear that
volume flags are related to mounting.
Send new unsupported disk event when we finish scanning an entire
disk and have no meaningful volumes.
Bug: 19993667
Change-Id: I08a91452ff561171a484d1da5745293ec893aec0
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
Resize is no-op when sector count is unchanged; the caller can't
anticipate how vold does its sector calculations.
After resizing, we need to mount the container read-write, so allow
the caller to request "ro" or "rw" mode.
Handle ENOTSUP when trying to fallocate() on some filesystems
Bug: 16514385
Change-Id: I0d3a378280d4c36d14f8108ff428102283d583fa
Sometimes when an sdcard is already mounted,
some info like uuid and label are not re-broadcast to new listeners.
The extra argument to list allows late listeners to catch up by asking
volume list to broadcast that info again.
Bug: 16253597
Bug: 16306775
Change-Id: Ie7d0c1132c22d307a5b2a0e50075a3716138d00b
Signed-off-by: Benson Huang <benson.huang@mediatek.com>
(cherry picked from commit 85f4700f44170b772697e627b3075dcb9137e1b7)
ASECs formatted as ext4 can now be resized using vdc asec resize.
Refactored some common code.
Requires resize2fs.
Change-Id: Ie78bb6015114a7bc4af42b16d1f299322ffc1e2a
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Apps without sdcard_r or sdcard_rw need to have someone create
package-specific directories on their behalf. If apps have trouble
creating on their own, they now delegate through system to have
vold create the paths.
Requires that the requested path is actually managed by vold.
Bug: 10577808
Change-Id: I6835fc8f52240f9de07f89742a426a153e3ca32a
The new wipe option to the vold format command will invoke BLKDISCARD
on the partition before invoking newfs_msdos. This will be used whenever
a full wipe of the device is wanted, as this is more secure than just
doing newfs_msdos.
Bug: 9392982
Change-Id: Ie106f1b9cc70abc61206006d1821641c27c7ccae
Any ASEC or OBB files were unmounted when USB storage was set to UMS
mode. This changes it so only ASEC files on external storage and OBB
files mounted from external storage are unmounted.
Bug: 6948035
Change-Id: I91bc09ee5b792970b0eef895f6886f3ffad00e8f
Now that forward locked apps are stored on /data as asec image files
that are mounted, they need to be unmounted before /data can be unmounted
so it can be encrypted.
Change-Id: I7c87deb52aaed21c8ad8ce8aceb7c15c2338620a
Now forward locked applications will be in ASEC containers both internal
to the system and externally.
This change adds support for putting applications in ext4-based ASECs.
Change-Id: I8d6765b72dd2606e429c067b47a2dbcaa8bef37d
Add the force_and_revert option to the unmount command which will force
the unmount, and revert a crypto mapping. This is used during factory
reset so that when the internal sdcard volume is formatted, it formats
the raw device, not the encrypted mapping.
Change-Id: I36b6ff9bb54863b121de635472a303bf4a2334a9
Mounting was already not allowed, but also unshare before starting
encryption, and don't allow sharing or formatting to be initiated
during encrytion.
Change-Id: Ida188d81f025739ba4dd90492b3e66088735991e
Add support for keeping the keys in a separate file on another partition,
for devices with no space reserved for a footer after the userdata filesystem.
Add support for encrypting the volumes managed by vold, if they meet certain
criteria, namely being marked as nonremovable and encryptable in vold.fstab.
A bit of trickiness is required to keep vold happy.
Change-Id: Idf0611f74b56c1026c45742ca82e0c26e58828fe
Improves UI responsiveness when copying large amount of data to the device.
BUG: 3131847
Change-Id: I4aa5ade7e2cd7e5110c8f0f7ee43bdc57577e11d
Signed-off-by: Mike Lockwood <lockwood@google.com>
OBB and ASEC are tracked in the same active container list, but when it
comes time to unmount everything, it was trying to unmount the OBBs
according to ASEC rules. This led to the OBB not being unmounted and the
volume unmount failing.
Change-Id: I12c1d4d387b8022185d552b63edd61a50b9c0fc3
* Rename all functions dealing with OBB files to mention Obb
* Add 'path' and 'list' functionality to OBB commands
* Store hashed filename in loop's lo_crypt_name and keep lo_file_name
for the real source filename. That way we can recover it later with an
ioctl call.
Change-Id: I29e468265988bfb931d981532d86d7be7b3adfc8
Allow the mounting of OBB filesystem images if they're encrypted with
twofish and in FAT filesystem format.
Change-Id: I54804e598f46b1f3a784ffe517ebd9d7626de7aa
The usb_mass_storage switch no longer exists in our 2.6.35 kernel.
Instead we will consider mass storage to be available if both USB is connected
and the USB mass storage function is enable.
Change-Id: I730d1b3cb3cac664fc2abcdc36cd39856a08404a
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fixes bug: http://b/issue?id=2567572
Note: The framework will still likely restart since the system_server
is holding references to assets on the card which are mmaped, but
at least now storage will be available when a new card is re-inserted.
Change-Id: I4e195c0c666426b93da47198fa826a6f58d855a9
Signed-off-by: San Mehat <san@google.com>
- Fix issue where container-names > 64 bytes were getting truncated in the
kernel. lo_name is only 64 bytes in length, so we now hash the container
id via md5
- Add 'dump' command to dump loop and devicemapper status
- Add 'debug' command to enable more detailed logging at runtime
- Log vold IPC arguments (minus encryption keys)
- Fix premature return from Loop::lookupActive() and friends
Change-Id: I0e833261a445ce9dc1a8187e5501d27daba1ca76
Signed-off-by: San Mehat <san@google.com>
- Supports up to 4096 containers
- Keys are now implemented - specifying a key of 'none' means no encryption.
Otherwise, the key must be a string of 32 characters
Signed-off-by: San Mehat <san@google.com>
