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
Currently F2FS block size must match page size, so this just does that.
If we support page size != block size for F2FS, this should be
revisited.
Bug: 279820706
Test: Boot 16K device
Change-Id: I6b3b367cdf76ccf5b2c5d309499027a5e7383a44
Signed-off-by: Daniel Rosenberg <drosen@google.com>
When using multiple partitions, f2fs stores all the device paths, but we cannot
guarantee the dm targets are all the same across boot cycles.
Bug: 287247093
Change-Id: Ie4308a27548d4e814924afb656478cfa55fcf8b6
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Its possible for vold to read a pid from procfs, the pid is killed
externally and then vold tries to kill it. In this scenario, we sleep
for 5s without needing it. Verify the return value from the kill syscall
and validate that the pid was killed, if the pid didn't exist at the
moment of the kill call, then don't count the pid as being killed.
Test: Boots successfully
Bug: 307801020
Change-Id: Ie127108b85be7249cf8b2881f4917d653d032186
Rename methods that refer to "user key" to be more precise about what
they mean. For more details, see the corresponding frameworks/base
changes (I202ebbfd2b4f79fedb3ed120a8ad81500c126894 and
I5894beb97823dced5954e405d779fada49c79e8d).
No change in behavior except for some changed log messages.
Flag: exempt, mechanical refactoring only
Test: presubmit
Change-Id: I9edcb557172395f4f6cf8e837efcc06fcfefb37d
* changes:
Revert "fskeyring & userspace reboot: support CE keys"
Evict adoptable storage CE and DE keys when possible
Don't erase key from s_new_ce_keys on eviction
Call fscrypt_destroy_volume_keys() under mCryptLock
Fold read_and_install_user_ce_key() into fscrypt_unlock_user_key()
Userspace reboot turned out to be a dead end and is no longer supported.
Therefore, remove the code from vold that handled keeping CE storage
unlocked past the userdata filesystem being unmounted and mounted.
This is a revert of commit 1c6731c649 (https://r.android.com/1254615)
with various conflicts resolved.
Bug: 292469129
Change-Id: If530edaf7c1566dd3bd8b1322f935f38a2e66beb
Merged-In: If530edaf7c1566dd3bd8b1322f935f38a2e66beb
(cherry picked from commit 2b97a88ba4)
Adoptable storage CE and DE keys were not being explicitly evicted,
resulting in the benefits of key eviction not being fully realized on
devices that use adoptable storage. Fix this by evicting the adoptable
storage keys when the corresponding internal storage keys are evicted:
- In lockUserKey, evict the CE keys for adoptable storage volumes, not
just the CE key for internal storage as was done before.
- In destroyUserKey, evict the user's CE and DE keys for adoptable
storage, not just the internal storage keys as was done before.
To make this possible, starting keeping track of the EncryptionPolicy of
each currently installed adoptable storage key.
(This CL is reworked from https://r.android.com/2660878,
original author Arnab Sen <arnabse@amazon.com>)
Test: On Cuttlefish with config_multiuserMaxRunningUsers changed to 1:
sm set-virtual-disk true
sm partition disk:7,416 private
pm create-user 10
am start-user 10
am stop-user 10
# Verified that this fails with "Required key not available".
touch /mnt/expand/f1ad173b-d6d9-4948-8eb7-ccdd7b053b22/misc_ce/10/foo.txt
am start-user 10
pm remove-user 10
# Checked for all the expected "Evicted fscrypt key" messages.
# 2 from when user was stopped, and 4 from when user was removed.
adb logcat | grep Evicted
Change-Id: I7f11a135d8550618cd96013f834cebd54be5ef84
Merged-In: I7f11a135d8550618cd96013f834cebd54be5ef84
(cherry picked from commit 68fd3689a1)
Erasing a key from s_new_ce_keys is equivalent to destroying it, so it
shouldn't be done when the key is merely being evicted.
This didn't matter in practice since eviction requests don't come in
before the key gets persisted, but fix this to avoid confusion.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: I28412f243925b5a7242449b617fe9de9c90912b6
Merged-In: I28412f243925b5a7242449b617fe9de9c90912b6
(cherry picked from commit 3529302ede)
Everything in FsCrypt.cpp seems to run under VolumeManager::mCryptLock,
except for fscrypt_destroy_volume_keys() which uses mLock instead.
This was sort of okay because fscrypt_destroy_volume_keys() didn't
operate on any in-memory data structures. However, that is going to be
changed. Therefore, rework VoldNativeService::forgetPartition() to call
fscrypt_destroy_volume_keys() under mCryptLock.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: Ia27a61faf2fdd546cdbddb2a3985c7c6696f6aa6
Merged-In: Ia27a61faf2fdd546cdbddb2a3985c7c6696f6aa6
(cherry picked from commit ce86e24d23)
No change in behavior, except for removing a redundant check of
's_ce_policies.count(user_id)' and removing an extra ERROR message.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: If221e23991e8e04138ae7dbdafe8160b00893655
Merged-In: If221e23991e8e04138ae7dbdafe8160b00893655
(cherry picked from commit 92428b247f)
