On case 4 (filesystem modified), we attempt to recheck the filesystem,
but due to the while(0), this immediately returns 0, resulting in
mounting a filesystem with unfixed errors. This corrects that.
Bug: 340128961
Test: Ensure case 4 leads to retries
Change-Id: Ida2840538ad88c8de5341b0d71d3712d93b0cab1
vold currently uses the first fstab entry for moun point /data .
However, if there are multiple fstab entries for /data and the
first one isn't the entry actually being used, checkpoint may fail.
Test: boot a device with ext4 entry placed after f2fs
Bug: 293313353
Change-Id: Id374c622c53fd61047d62743555234d36bd038ec
Replace the current `string secret` argument to the lock/unlock of
CE storage with a `byte[]`. This is part of an effort to remove
instances of the LSKF and LSKF-derived secrets that are available
in a RAMdump -- since the strings are passed from Java, they cannot
be cleared, but `byte[]` can be.
This CL is the described argument change, and the propagation of this
change to the various functions that are called by the vold binder
functions.
Bug: 320392352
Test: Manual upgrade test:
1. Flash the device with a build not including these changes
2. Rebuild with these changes
3. Flash the device (but do not wipe) with the build including
these changes
4. See if the device boots and works normally -- if the CE
storage cannot be unlocked it will not start up and be usable
when the user logs in.
Change-Id: Icd4c925f2fd79e7533fdf9027e16f6736dbe1ab3
[Description]
The usb has invalid partition table, but vold thinks it has partition.
So vold not to treat entire disk as partition.
Bug: 160433451
[Test Report]
Build pass.
The special usb can mount ok.
Change-Id: I0b0e761641f6961e69d7d7f7fbc58d33eeab3a08
This reverts commit 697c6a5217.
It is reapplying the change in I0439f63fd4739bf5a6c957695cc9c3003ec89eb0.
Reason for revert: Undoing the revert (putting the change back in); after looking at the
performance bug, it seems impossible it was caused by the addition of the `@SensitiveData`
tag on IVold.
Performance bug: 331045735
Bug: 320392352
Test: launch_cvd -daemon
Change-Id: I522f63836155ea404260e89fd2f209738f37d5b3
This reverts commit da1d160074.
Reason for revert: reverting while figuring out what is causing performance bug 331045735
Change-Id: Ib306e679e65c3a585304ad4c33304c549cbb240e
Mitigate data leak across the Binder boundary to Vold, of secrets derived from the LSKF.
Specifically: the `String secret` argument to both `setCeStorageProtection` and `unlockCeStorage` is
a secret derived from the user's synthetic password.
This CL is part of an effort to wipe instances of the LSKF and
secrets derived from it, so they are not available in a RAMdump.
Bug: 320392352
Test: launch_cvd -daemon
Change-Id: I0439f63fd4739bf5a6c957695cc9c3003ec89eb0
Since MANAGE_MISC_DIRS is hardcoded to 0, and it always has been, there
is no need to have it in the code.
Test: build
Change-Id: I30a73e67999841271e07dbc3eeb1b8568529a7c3
The current shutdown / reset logic in VolumeManager unmounts
EmulatedVolume first, and unmounts the other disks.
In ARC (Android on ChromeOS), ChromeOS Downloads directory (exposed from
ChromeOS to Android as a disk having StubVolume) is bind-mounted to
/data/media/0/Download in the ARC-customized version of
StubVolume::doMount() (http://shortn/_lKaAhTLhY3), and the current
unmount order causes EmulatedVolume not to be cleanly unmounted. This
patch hence changes the order of the unmount of volumes to first unmount
StubVolume disks, then unmount the EmulatedVolumes, then unmount the
non-StubVolume disks.
Bug: 304369444
Test: On an Android phone, create a virtual public volume with the
following commands on adb shell (taken from
android.scopedstorage.cts.lib.TestUtils.createNewPublicVolume()):
$ sm set-force-adoptable on
$ sm set-virtual-disk true
$ sm list-disks # <- This returns the virtual disk name
$ sm partition <virtual disk name> public
Then, run `vdc volume reset` on lynx adb shell, observe logcat from
vold and check that no error is observed.
Test: Run `vdc volume reset` on ARC adb shell, and confirm that:
* Without this patch, the primary emulated volume fails to unmount
with "Device or resource busy", followed by MyFiles volume unmount.
* With this patch, MyFiles volume is unmounted before the primary
emulated volume, and no error is observed.
Change-Id: I54f60e3320574ccf8d3589545ff77967fff14fc7
This CL is created as a best effort to migrate test targets to the new Android ownership model.
It is based on historical data from repository history and insights from git blame.
Given the nature of this effort, there may be instances of incorrect attribution. If you find incorrect or unnecessary
attribution in this CL, please create a new CL to fix that.
For detailed guidelines and further information on the migration please refer to the link below,
go/new-android-ownership-model
Bug: 304529413
Test: N/A
Change-Id: Ifbead75f744dc00b84aa71b5847ec6a5e0289251
This differs slightly from the previous API, which exists for idle
maintenance, whereas this value is intended to be displayed to users.
First, it returns remaining lifetime, rather than used lifetime. Second,
it rounds up the returned value for usabilty purposes. This isn't an
issue on Pixel (which reports at 1% granularity), but devices which
report at 10% granularity should show 100% out-of-box, which is not
possible to distinguish in the old API.
Bug: 309886423
Test: StorageManager.getRemainingStorageLifetime
Change-Id: Ic5f6ec9969667302ba8bad95b2765e2cc740bed4
Add time_offset=<UTC offset> to mount arguments for the vfat driver.
This is not being release flagged as it's a fix for a regression but is
a cosmetic fix that shouldn't affect anything besides reported file
timestamps.
Changes for issue 246256335 in Android U stopped Android syncing the
current time zone UTC offset to the kernel because doing so is
discouraged. It is discouraged because the current offset alone is not
very useful - it tells the kernel nothing of DST or historic UTC
offsets. Converting to and from local times are are best left to
userspace where time zone rules information is available, and different
users can use different time zones.
However, because FAT32 is poorly designed WRT timestamps, the kernel
FAT32 driver, vfat, does use the kernel offset when available and when
it isn't given a fixed offset to use at volume mount time. This means
that Android devices after the change from issue 246256335 displayed
more obviously incorrect times.
This change adds the argument necessary to vold when mounting a FAT32
volume to set a fixed UTC offset to adjust FAT32 local times
to a UTC-like time ("UTC time" from now on). Userspace then uses the UTC
offset for that UTC time, calculated using TZDB rules, to convert back
to a local time. This is still prone to generating some incorrect times,
e.g. due to DST or other historic offset changes, or a user time zone
change on device after mounting the volume. FAT32 lacks the information
about "what was the UTC offset at file time X?" (unlike exFAT) AND the
vfat driver has no way to look up the time zone rules itself. This
change is a reasonable "better than nothing" change to address times
being obviously wrong after the change from issue 246256335, especially
when a user copies a file from a desktop computer to USB / sd card
storage and immediately plugs the device into an Android device. It does
this without reverting to kernel UTC offset syncing, which is flawed
(i.e. it would never work completely), discouraged, and more effort/code
to improve, e.g. because userspace would have to schedule alarms for
offset changes.
Testing:
1) Obtain a USB FAT32 formatted USB storage device that can be plugged into
a pixel device, e.g. with an OTG USB adapter.
2) On a desktop computer, mount the device and write some files / note
times associated with existing files. These times will already be
adjusted by this OS to be "local time" based on its own logic, but if
it's working correctly that time will be exactly the local time value
stored in the FAT32 volume itself.
3) On a rooted Android device where you can use adb via Wifi (adb tcpip
/ adb connect), leaving the USB port free for external USB devices....
a) $ adb root
b) Insert the USB storage
c) $ mount | grep 'fat'
d) For the USB storage drive, observe the time_offset argument (or
tz=UTC when time_offset == 0) reported (this would not be reported
without this patch)
e) ls -l /mnt/<mount location from (3c)>
f) Confirm the local time displayed is as expected. e.g. the time
should be the same as shown in (2), regardless of the device's time
zone.
4) To observe the "fixed offset behavior" at mount time, alter the time
zone setting on the device via Settings -> System -> Date & Time
a) Repeat 3c-3e.
b) The times shown will have changed by the difference between
the original and new time zone chosen.
c) Extract / re-insert the USB storage device.
d) Repeat 3c-3e
e) The times shown should match the times from (2) again
5) Confirm the write behavior:
a) $ touch /mnt/<mount location from (3c)>/foobar
b) $ ls -l /mnt/<mount location from (3c)>
c) The time should match the device's displayed local time (status
bar)
d) Unmount the USB device and insert the USB device into a desktop computer
e) Confirm the timestamp matches the Android device's local time when
(5a) took place, e.g. using "ls -lT" on MacOS.
Testing was done with numerous zones with positive, negative and zero offsets.
Interesting zones like India (UTC+5:30), Kiribati (UTC+14), Wake Island
(UTC-11), the various fixed offset zones like Etc/GMT+12, Etc/GMT-14
were tried.
Note: Depending on the time zones being used on devices (Android and
desktop) and when the files were written / testing took place during the
year, you may see file times shifting by 1 hour from the "ls -l" step
depending on whether they were written in summer or winter time. This
is because the userspace code for rendering times knows about DST but
the kernel driver is applying a fixed offset and does not. This is
expected and illustrates the points at the top of this comment about
FAT32 integration never being perfect.
See https://www.google.com/search?q=fat32+dst for other examples.
Bug: 319417938
Bug: 315058275
Bug: 246256335
Test: See above
Change-Id: Ic7ce159d88db5d5cf5894bcc26ea60bd7c44917d
createUserStorageKeys(), unlockCeStorage(), and prepareUserStorage()
have a user serial number parameter, but they don't actually do anything
with it except log it. Remove this unnecessary parameter.
Bug: 316035110
Test: presubmit
Flag: N/A, mechanical refactoring
Change-Id: I73ebae1afb2bdb7ca856b40b34ce806fdda718fe
The android-4.14-stable and later kernels support the
FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY ioctls. This
has superseded the old way of adding fscrypt keys to the kernel, which
was to use the add_key() syscall to add keys to the "session" keyring.
On kernels that support the ioctls, Android doesn't use the obsolete
way. Since upgrading even just to Android 14 requires at minimum a
android-4.14-stable kernel (according to
https://source.android.com/docs/core/architecture/kernel/android-common#compatibility-matrix),
there is no need to support the obsolete way anymore.
Therefore, this commit removes the code that added and removed keys
to/from the session keyring. Now the ioctls are used unconditionally.
Flag: N/A for the following reasons:
- Removing obsolete code, which is fairly safe
- Very early code, so runtime flag cannot be used
- This topic also removes code from init, which cannot use aconfig
libraries because they do not support recovery_available
Bug: 311736104
Test: Build and boot Cuttlefish
Change-Id: I0d9abbda77b1ac838ea6f014dbe22ab032c0e5ae
Since the max read size of FUSE is 128KB in default, the socket header
of the appfuse epollcontroller is allocated in order 4 (64KB). When
memory environment is in insufficient situation that has a lot of
fragment, order 4 size memory allication is impossible, so more than
several tens of seconds could take to allocate the socket header.
To prevent the issue, limit the fuse read size to 64KB, so that the
memory allocation order of the socket header is changed to order 2.
Bug: 312503249
Test: atest AppFusePerfTest
Change-Id: I7020801b7539d980515885396916f8be1f1008e9
