Since evicting inodes triggers writes to the backing file, which uses
the mi_owner field from the mount_info struct, make sure inodes are
evicted before we free the mount_info data
Test: incfs_test
Bug: 270117845
Change-Id: I673b2e0e04b5adc3998caf6f22443598a30338af
Signed-off-by: Paul Lawrence <paullawrence@google.com>
(cherry picked from commit 7899985277527b29c47929a6d6a89c5c89b406ad)
(cherry picked from commit faf3626b8e34df3dfff3a99e6582a9abd24410ce)
Add an explicite check for ATTR_KILL_SUID and ATTR_MODE in incfs_setattr.
Both of these attributes can not be set at the same time, otherwise
notify_change() function will check it and invoke BUG(), crashing
the system.
Bug: 243394930
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I91080d68efbd62f1441e20a5c02feef3d1b06e4e
Syzbot recently found a number of issues related to incremental-fs
(see bug numbers below). All have to do with the fact that incr-fs
allows mounts of the same source and target multiple times.
This is a design decision and the user space component "Data Loader"
expects this to work for app re-install use case.
The mounting depth needs to be controlled, however, and only allowed
to be two levels deep. In case of more than two mount attempts the
driver needs to return an error.
In case of the issues listed below the common pattern is that the
reproducer calls:
mount("./file0", "./file0", "incremental-fs", 0, NULL)
many times and then invokes a file operation like chmod, setxattr,
or open on the ./file0. This causes a recursive call for all the
mounted instances, which eventually causes a stack overflow and
a kernel crash:
BUG: stack guard page was hit at ffffc90000c0fff8
kernel stack overflow (double-fault): 0000 [#1] PREEMPT SMP KASAN
This change also cleans up the mount error path to properly clean
allocated resources and call deactivate_locked_super(), which
causes the incfs_kill_sb() to be called, where the sb is freed.
Bug: 211066171
Bug: 213140206
Bug: 213215835
Bug: 211914587
Bug: 211213635
Bug: 213137376
Bug: 211161296
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I08d9b545a2715423296bf4beb67bdbbed78d1be1
This reverts commit fe0c18d0f0.
This is follow up cleanup after revert of:
"Revert "ANDROID: incremental-fs: fix mount_fs issue"
Bug: 220805927
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I7749401484d87b9d519bd7b9600cd02f91a18090
This reverts commit 013b7ed754.
Test: Can now install the same apk twice, and repeated installs are
stable
Bug: 217661925
Bug: 219731048
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I86871c364c17a0d1107b3891a574b72edcf04ea2
(cherry picked from commit d107cd06f26b4d45b1079c7eb857815905198076)
Signed-off-by: Howard Chen <howardsoc@google.com>
Cleanup incremental-fs left overs on umount, otherwise incr-fs will
complain as below:
BUG: Dentry {i=47a,n=.incomplete} still in use [unmount of incremental-fs]
This requires vfs_rmdir() of the special index dir.
Since set_anon_super() was used in incfs_mount_fs() the incfs_kill_sb()
should use kill_anon_super() instead of generic_shutdown_super()
otherwise it will leak the pseudo dev_t that set_anon_super() allocates.
Bug: 211066171
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I7ea54db63513fc130e1997cbf79121015ee12405
Syzbot recently found a number of issues related to incremental-fs
(see bug numbers below). All have to do with the fact that incr-fs
allows mounts of the same source and target multiple times.
The correct behavior for a file system is to allow only one such
mount, and then every subsequent attempt should fail with a -EBUSY
error code. In case of the issues listed below the common pattern
is that the reproducer calls:
mount("./file0", "./file0", "incremental-fs", 0, NULL)
many times and then invokes a file operation like chmod, setxattr,
or open on the ./file0. This causes a recursive call for all the
mounted instances, which eventually causes a stack overflow and
a kernel crash:
BUG: stack guard page was hit at ffffc90000c0fff8
kernel stack overflow (double-fault): 0000 [#1] PREEMPT SMP KASAN
The reason why many mounts with the same source and target are
possible is because the incfs_mount_fs() as it is allocates a new
super_block for every call, regardless of whether a given mount already
exists or not. This happens every time the sget() function is called
with a test param equal to NULL.
The correct behavior for an FS mount implementation is to call
appropriate mount vfs call for it's type, i.e. mount_bdev() for
a block device backed FS, mount_single() for a pseudo file system,
like sysfs that is mounted in a single, well know location, or
mount_nodev() for other special purpose FS like overlayfs.
In case of incremental-fs the open coded mount logic doesn't check
for abusive mount attempts such as overlays.
To fix this issue the logic needs to be changed to pass a proper
test function to sget() call, which then checks if a super_block
for a mount instance has already been allocated and also allows
the VFS to properly verify invalid mount attempts.
Bug: 211066171
Bug: 213140206
Bug: 213215835
Bug: 211914587
Bug: 211213635
Bug: 213137376
Bug: 211161296
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I66cfc3f1b5aaffb32b0845b2dad3ff26fe952e27
Use same selinux scheme as incfs v2
Fix memory leak
Bug: 174692664
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I6058ddad9d43ba01b2eabd7d3c576f2cc9b42292
This reverts commit 28688d32ed.
Reason for revert: rolling the three fixes into one with feature flag
Bug: 174692664
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I85cb75b7acb5606659698a6d0e0918ffb731009d
This reverts commit 75c93eb439.
Reason for revert: rolling the three fixes into one with feature flag
Bug: 174692664
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I838bed85d6682aba44165a58c22e6a0e10c49d58
Bug: 177075428
Test: incfs_test passes
atest GtsIncrementalInstallTestCases has only 8 failures
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I73accfc1982aec1cd7947996c25a23e4a97cfdac
Bug: 174692664
Test: incfs_test passes, incremental installs work with ag/13082306
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ib1c924bbaff759f58f7d83bad8e23d7224ba7ed9
It's still magic number issue which cannot be compatible with
arm-32 platform, although we try to fix it in Iae4f3877444
("ANDROID: Incremental fs: magic number compatible 32-bit"),
there is still incompatible scenario, such as: get_incfs_node(),
it will return NULL then kernel exception will be trigger because
of NULL pointer access. (inode_set() -> get_incfs_node(), then used
node->xxx directly)
We change magic number directly, otherwise, we must fix above issues one by one.
Bug: 159772865
Fixes: Iae4f3877444("ANDROID: Incremental fs: magic number compatible 32-bit")
Signed-off-by: Peng Zhou <Peng.Zhou@mediatek.com>
Signed-off-by: mtk81325 <peng.zhou@mediatek.com>
Change-Id: I71f279c1bb55ea296ab33a47644f30df4a9f60a6
Incfs's magic is bigger than 32-bit, but super block structure's
s_magic is unsigned long which is 32-bit in ARM 32-bit platform.
Do the cast for magic!
Bug: 159772865
Signed-off-by: Peng Zhou <Peng.Zhou@mediatek.com>
Signed-off-by: mtk81325 <peng.zhou@mediatek.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Iae4f38774440c7d6ae44529d4f0f8ebb2ec5dacc
Bug: 155996534
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ic508e6fa07c90decb29e07647dd3b0fc4d243ce8
(cherry picked from commit 21e6d932da379416bab8ea8d78f14525e7bf564d)
If an incfs file is created, then the file system is sync'd,on opening
the incfs file inode_set reads the size from the backing file from
within iget5_locked, causing this error.
Test: incfs_test passes, this no longer occurs
Bug: 156413528
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I8939c4afa514d39d251c044d7680cfc69272669e
As was, chmod would change the cached inode's mode, which would
persist until the inode was uncached.
Fix to change mode of backing file, but make sure mount files
are read only, backing files are always writeable.
Test: App no longer fails with incfs errors
Bug: 154972299
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I40517331f24329484387c6b880f1517f887b29f6
(cherry picked from commit fe4fae35fe307a15cacc5e6693a98bf5140e643b)
Bug: 153560805
Test: incfs_test passes on qemu and Pixel 4
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I1b55341e4e4247a74f3f539b9d190fef0ca409b8
Read log buffer can have multiple threads doing any of these
operations simultaneously:
- Polling for changes
- Reading log records
- Adding new log records
- Updating log buffer size, or enabling/disabling it completely
As we don't control the userspace, and it turns out that they
all currently originate from different processes, code needs to
be safe against parallel access to a read buffer and a request
for reallocating it.
This CL add an r/w spinlock to protect the buffer and its size.
Each remount takes the write lock, while everything else takes
a read lock. Remount makes sure it doesn't take too long by
preallocating and precalculating all updates, while other
operations don't care much about their critical section size -
they all can still run together.
Bug: 152633648
Test: manual remount + reading
Signed-off-by: Yurii Zubrytskyi <zyy@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I7271b4cb89f1ae2cbee6e5b073758f344c4ba66a
Found by sparse
Bug: 153174547
Test: make C=2 fs/incfs/incrementalfs.ko no errors, incfs_test pass
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I9ff4f4f35975fe09936724488b96cd8bdeeb719e
Since INCFS_IOC_GET_FILLED_BLOCKS potentially leaks information about usage
patterns, and is only useful to someone filling the file, best protect it in
the same way as INCFS_IOC_FILL_BLOCKS.
Add useful field data_block_out as well
Test: incfs_test passes
Bug: 152983639
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I126a8cf711e56592479093e9aadbfd0e7f700752
Without these, you can't unmount a volume on which incfs was
mounted and the tests run.
Also incfs_tests would fail sporadically without the fix to
test_inode
Test: Run incfs_test and unmount underlying volume 1000 times
Bug: 152636070
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I88f11f5d4269c22d9073e5eb671d0c7cc4629f6c
(cherry picked from commit c062bc8e769f0f6e47cc41fb9b7ab30e3e7f2689)
Provide a securable way to open a file for filling
Test: incfs_test passes
Bug: 138149732
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ib4b6fd839ad30ce08e31121d19e2c0d7066d302f
Filling blocks is not equivalent to writing a file, since they are
constrained by the root hash. selinux policy may wish to treat them
differently, for instance.
Test: incfs_test passes
Bug: 138149732
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ic369b84b92547b1cfefe422bd881c4e466090aed
They provide no value and simply duplicate a check in copy_from/to_user
Test: incfs_test passes
Bug: 138149732
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Icc6054a2d6a495c9a03cd1507dda1ab8ca0b0dc4
To make selinux work, add xattr support. This is a bit clunky -
it seems like it would be better for the log and pending read
functionality to be ioctls rather than this mixture of real
and virtual files.
Bug: 133435829
Change-Id: I56579fabe2ae7efb88f0344553948dc9573299aa
Signed-off-by: Paul Lawrence <paullawrence@google.com>
- added chmod() to +0222 to make all backing files and dirs
writable. vold/system_server have a umask that clears those
flags, making incfs unusable
Signed-off-by: Yurii Zubrytskyi <zyy@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Bug: 133435829
Change-Id: Id9258401570cc2cc7cd5735aace89d379a9b043d
(cherry picked from commit bc5e5bc1d007e99228ca0717daa12639627819ba)
Don't call dput on error code
Change-Id: Ie63645c9ed67fa231829917ae8ca154e049b4921
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Bug: 133435829
(cherry picked from commit 334164ca0f18ea89a922b90020f5e3840a928503)
Fix all sparse errors in fs/incfs except
fs/incfs/integrity.c:192:9: warning: Variable length array is used
Test: incfs_test passes
Bug: 133435829
Change-Id: I9c2e26e4e1a06a894977f11a3c8559b968dd115e
Signed-off-by: Paul Lawrence <paullawrence@google.com>
