Newer versions of libc++ check that an allocator can be rebound to the
same element type. We need to add a rebind member to ZeroingAllocator
to fix this compiler error:
prebuilts/clang/host/linux-x86/clang-r498229/include/c++/v1/vector:376:19: error: static assertion failed due to requirement 'is_same<android::vold::ZeroingAllocator, std::allocator<char>>::value': [allocator.requirements] states that rebinding an allocator to the same type should result in the original allocator
static_assert(is_same<allocator_type, __rebind_alloc<__alloc_traits, value_type> >::value,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It likely doesn't matter in practice because this allocator is only
used with std::vector, which probably doesn't use allocator rebinding,
because it won't allocate an internal node type (e.g. unlike std::map,
std::list, etc).
Alternatively, ZeroingAllocator could be changed to a
ZeroingAllocator<T> that can zero arbitrary types, but it doesn't seem
necessary currently, and types other than char wouldn't be used.
Bug: b/175635923
Test: treehugger
Change-Id: I42e9d8f02a18637fc67e94cc1358d2ed733a7268
When a volume is ejected from a user but not removed from the device
and mounted again by calling StorageManager#mount, the volume is
mounted for the user from which it was last ejected. This causes the
path of the mounted volume to be inaccessible to the current user.
Whenever StorageManager#mount is called, check if the
VolumeInfo#mountUserId is same as the current userId maintained by
StorageManagerService, if it is not, change the mountUserId for the
Volume to the current userId known to StorageManagerService if it
is not the primary volume and the volume is visible.
This change also fixes a bug where the volumes are unmounted for the
wrong user which causes StorageSessionController go out of sync
which would cause errors during mounting the volumes again as it
maintains sessions per user. The bug also caused volume event
broadcasts to be sent to wrong user handles. To solve the issue
add an extra paramter in IVoldListener#onVolumeStateChanged for userId
which will update the copy which is used for informing
StorageSessionController and also for sending broadcasts.
Test: Perform the following steps:
1. Format SD Card as portable storage in system user.
2. Eject the SD Card from Storage Settings.
3. Switch to a non-system user
4. Mount the SD Card again.
5. Check that the Storage Summary is shown correctly instead
of 0B out of 0B.
Also, checked from the logs the volume state broadcasts are sent to
the correct user handles.
Change-Id: I60b8954cdaee4a54ea6a6299fe5ddda2006faf1c
"Do not reboot with commit failure when ext4 userdata is wiped" has
caused a regression in cuttlefish on f2fs. Overlay.img rapidly grows to
the full userdata size. This updates that CL to only affect partitions
marked for block based checkpointing.
Test: Boot Cuttlefish, monitor overlay.img for 5 minutes
Bug: 285019395
Change-Id: I8aa37a97e847960afe8b368090a86c8835e6ca9e
https://r.android.com/2620458 is removing the write mode bit from the
top-level user directories on internal storage, in order to make the DAC
consistent with the SELinux policy.
This commit makes the corresponding change to adoptable storage.
Bug: 285239971
Test: sm set-virtual-disk true; sm partition disk:7,392 private
Change-Id: I17dfbe10909b34c2046a4d5b4ffd7764d5ae083b
Even after having changed the SELinux policy to remove system_server's
permission to create directories like /data/system_ce/10, there's still
a very small loophole where system_server can create a subdirectory
after vold creates the directory but before vold assigns an encryption
policy to it. This isn't known to have actually happened (b/285239971
was a candidate, but it seems to have actually been caused by SELinux
being in permissive mode), but it's theoretically possible.
Close this loophole by making vold create encrypted directories under
temporary names and move them into place once they are fully prepared.
Bug: 156305599
Bug: 285239971
Test: Cuttlefish boots, and can be rebooted.
Change-Id: I53407c938bab02ab4b7e5bab8402f36eb47fb203
These libraries are only used by vold on a device and gain no
benifit from being included as shared libraries.
Moving them to static saves disk space, memory, and cpu cycles from the
dynamic linker.
Checking on cuttlefish accross 3 reboots:
This saves 613827 bytes of storage from the installed-files, 44KB of
private dirty memory, 172KB of PSS when only looking at the
libraries, and 155KB of PSS when looking at libraries and heap/stack
with shomap.
go/shared-to-static for more info on how this was determined.
Test: m
Bug: 280829178
Change-Id: I29af66dd66f4087ff1820ca661dc6dc2ace841fc
Since Android platform codespace doesn't support exception handling, we
use strtoll() instead of stoll for direct error handling.
Bug: 274369737
Test: check smart idle maintenace service log
Change-Id: I57c709b1e329228790e0a883edb64dc023135a24
Since commit 08f4bdfe98 ("Don't use a secdiscardable file for keys
encrypted by SP") (https://r.android.com/2242561), some keys don't use a
secdiscardable file. Currently if such a key is destroyed, an ERROR
message like the following is logged:
E secdiscard: Secure discard open failed for: /data/misc/vold/user_keys/ce/14/current/secdiscardable
This case is expected, so it should not be an ERROR. Fix this by only
passing the secdiscardable file to the secdiscard program if it exists.
Bug: 232452368
Change-Id: I490289dfdaf0db6c3f4fb507509095e0033e2f69
It's essential that files created by vold get the correct SELinux
labels, so make sure to check for errors when setting them.
ENOENT (no label defined) is expected on some files such as
/mnt/appfuse/*, so allow ENOENT but log a DEBUG message.
This will help debug b/269567270. This is not a fix for b/269567270.
Bug: 269567270
Test: Created user and checked SELinux labels of user's directories
Test: atest CtsBlobStoreHostTestCases
Change-Id: Ife005bdd896952653943c57336deb33456f7c5d8
There is a race condition between key eviction and killing user
processes. The race condition is difficult to properly fix without
significantly degrading UI performance.
If the race condition occurs, decrypted filesystem data is left in
various kernel caches. To mitigate, we try to ensure the caches are
flushed by evicting the keys again in a worker thread.
Test: Checked that the correct log messages appear when evicting a
user's keys
Bug: 140762419
Change-Id: I9e39e5bb0f5190284552bcd252b6213a22a51e91
(cherry picked from commit a21962b207)
Merged-In: I9e39e5bb0f5190284552bcd252b6213a22a51e91
