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)
Bug: 241479010
Test: incfs_test passes, play confirm behavior in bug is fixed
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ie51f2b76d0873057f54fecf7fcc793c66df20969
Also fix race whereby multiple providers writinig the same block would
actually write out the same block.
Note that multiple_providers_test started failing when incfs was ported
to 5.15, and these fixes are needed to make the test reliable
Bug: 264703896
Test: incfs-test passes, specifically multiple_providers_test. Ran 100
times
Change-Id: I05ad5b2b2f62cf218256222cecb79bbe9953bd97
Signed-off-by: Paul Lawrence <paullawrence@google.com>
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
Now that the branch is used to create production GKI
images, need to institute ACK DrNo for all commits.
The DrNo approvers are in the android-mainline branch
at /OWNERS_DrNo.
Bug: 240999246
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Id5bb83d7add5f314df6816c1c51b4bf2d8018e79
We have namespaces, so use them for all vfs-exported namespaces so that
filesystems can use them, but not anything else.
Some in-kernel drivers that do direct filesystem accesses (because they
serve up files) are also allowed access to these symbols to keep 'make
allmodconfig' builds working properly, but it is not needed for Android
kernel images.
Bug: 157965270
Bug: 210074446
Cc: Matthias Maennich <maennich@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iaf6140baf3a18a516ab2d5c3966235c42f3f70de
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
The old and new mount user name spaces need to be populated
before calling vfs_rename(). Otherwise vfs_rename will try
to dereference a null ptr and segfault.
Bug: 211066171
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I3656073581218107fc3b1a52ebe7bcfd81a10fc2
This reverts three increment-fs commits:
d5faa13b5910412e10c67ad88c9349
This is to fix the incrementalinstall test.
Can now install the same apk twice, and repeated installs are stable.
Bug: 217661925
Bug: 219731048
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: Ia8488d728218881ed17e4d68cab21b0b152e3ca4
The old and new mount user name spaces need to be populated
before calling vfs_rename().
Bug: 211066171
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: Ieac6975abb4131c8f5bdefe25b5f241c80023e38
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 and incomplete dirs.
Also free options.sysfs_name in incfs_mount_fs() instead of in
incfs_free_mount_info() to make it consistent with incfs_remount_fs().
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
The merkle tree pages at the end of the incremental files were being
zero'd and marked uptodate on 5.15. Mark uptodate on creation to prevent
this.
Bug: 197663427
Test: The test in that bug now passes on 5.15 kernel
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I5c0781c51bfbc64929e7a465db1ae975ce5928f9
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
It is possible that fget returns NULL. This needs to be handled
correctly in ioctl_permit_fill.
Bug: 212821226
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: Iec8be21982afeab6794b78ab1a542671c52acea2
Add a flag option to get xattr method that could have a bit flag of
XATTR_NOSECURITY passed to it. XATTR_NOSECURITY is generally then
set in the __vfs_getxattr path when called by security
infrastructure.
This handles the case of a union filesystem driver that is being
requested by the security layer to report back the xattr data.
For the use case where access is to be blocked by the security layer.
The path then could be security(dentry) ->
__vfs_getxattr(dentry...XATTR_NOSECURITY) ->
handler->get(dentry...XATTR_NOSECURITY) ->
__vfs_getxattr(lower_dentry...XATTR_NOSECURITY) ->
lower_handler->get(lower_dentry...XATTR_NOSECURITY)
which would report back through the chain data and success as
expected, the logging security layer at the top would have the
data to determine the access permissions and report back the target
context that was blocked.
Without the get handler flag, the path on a union filesystem would be
the errant security(dentry) -> __vfs_getxattr(dentry) ->
handler->get(dentry) -> vfs_getxattr(lower_dentry) -> nested ->
security(lower_dentry, log off) -> lower_handler->get(lower_dentry)
which would report back through the chain no data, and -EACCES.
For selinux for both cases, this would translate to a correctly
determined blocked access. In the first case with this change a correct avc
log would be reported, in the second legacy case an incorrect avc log
would be reported against an uninitialized u:object_r:unlabeled:s0
context making the logs cosmetically useless for audit2allow.
This patch series is inert and is the wide-spread addition of the
flags option for xattr functions, and a replacement of __vfs_getxattr
with __vfs_getxattr(...XATTR_NOSECURITY).
Bug: 204981027
Link: https://lore.kernel.org/lkml/20211117015806.2192263-2-dvander@google.com
Change-Id: Id2c6fa6eeb2b5cca5a11e0cd02a3fbf2a5fcbef4
Signed-off-by: David Anderson <dvander@google.com>
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
In commit edb0872f44 ("block: move the bdi from the request_queue to
the gendisk"), the backing device info moved .h files which breaks the
building of incfs. Fix this up like was done for fat, just include the
correct .h file.
Fixes: edb0872f44 ("block: move the bdi from the request_queue to the gendisk")
CC: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iccc990b1b01af4580192921410b915b91dc6a155
<linux/blkdev.h> no longer includes <linux/pagemap.h>.
Besides, source files should explicitly include headers providing used
functionality anyway.
Fixes: 4ee60ec156 ("include: remove pagemap.h from blkdev.h")
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I6d28e5cc100780ecd74f5d772f08fd4b0f977898
Prior change
ANDROID: Incremental fs: stat should return actual used blocks
adds blocks to getattr. Unfortunately the code always looks for the
backing file, and pseudo files don't have backing files, so getattr
fails for pseudo files.
Bug: 186567511
Test: incfs_test passes, can do incremental installs on test device
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ia3df87f3683e095d05c822b69747515963c95f1c
Sparse complains about casting a five byte number to a ulong on 32-bit
platorms. Fix by anding the constant with ULONG_MAX
Bug: 186015158
Test: incfs_test passes, sparse reports no warnings on 32 & 64 bit builds
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ic83e03626b7f290370d75b3aaba187b8392fb344
Adding seven sysfs entries per mount:
reads_failed_timed_out
reads_failed_hash_verification
reads_failed_other
reads_delayed_pending
reads_delayed_pending_us
reads_delayed_min
reads_delayed_min_us
to allow for status monitoring from userland
Change-Id: I50677511c2af4778ba0c574bb80323f31425b4d0
Test: incfs_test passes
Bug: 160634343
Bug: 184291759
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Compiler (arm-linux-gnueabihf-gcc 8.3.0) complains about an invalid cast
of an __aligned_u64 integer to a pointer on 32-bit architectures. Using
u64_to_user_ptr() for the cast fixes the following warning:
fs/incfs/pseudo_files.c: In function ‘ioctl_create_file’:
fs/incfs/pseudo_files.c:656:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
656 | (u8 __user *)args.signature_info,
| ^
Bug: 183339614
Fixes: bc6a70e849 (ANDROID: Incremental fs: Remove signature checks from kernel)
Reported-by: kernelci.org bot <bot@kernelci.org>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I98a987fb83c160740796c0b4b3fdd7551880e12a
Use the correct printk specifier [%zu] for size_t variable.
This fixes the following warning:
fs/incfs/format.c: In function ‘incfs_read_next_metadata_record’:
./include/linux/kern_levels.h:5:18: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
fs/incfs/format.c:669:3: note: in expansion of macro ‘pr_warn’
669 | pr_warn("incfs: The record is too large. Size: %ld",
| ^~~~~~~
Bug: 183339614
Fixes: c6819dd778 (ANDROID: Initial commit of Incremental FS)
Reported-by: kernelci.org bot <bot@kernelci.org>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: Ia784a9ced9fb6bc76e2f1baa495b3ccf568e3b1d
Lots of different vfs changes happened in 7d6beb71da ("Merge tag
'idmapped-mounts-v5.12' of
git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux") which were
not made to incfs as it is out-of-tree :(
So fix it up by doing a quick port to the initial user namespace and
hopefully all works properly now, at least it builds :)
Fixes: 7d6beb71da ("Merge tag 'idmapped-mounts-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux")
Cc: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I32899a792fbfad9455d504868e7a02d30a0a6049
This reverts commit 3484eba91d.
It's causing too many merge issues, so revert it for now and hopefully
bring it back later...
Cc: Mark Salyzyn <salyzyn@android.com>
Bug: 133515582
Bug: 136124883
Bug: 129319403
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id70a37d9471eff58f0027a1371538858136604d3
In order to provide better reviewer suggestions and to introduce fine
grained additional approval permissions, sprinkle some OWNERS files over
the tree.
This essentially grants additional OWNERS permissions in
- net/
- arch/arm*/net
- arch/x86/net
- drivers/net
- fs/crypto
- fs/f2fs
- fs/verity
All other permissions are already covered by ref/meta/config:OWNERS.
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: I02a6563e4dd63842af37c50f7180bf38e9b9b4be
Backing file needs to have write permissions for all users
even though the mounted view doesn't - otherwise incfs can't
change the internal file data.
Bug: 180535478
Test: adb install <apk>
Signed-off-by: Yurii Zubrytskyi <zyy@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I5d7915b28072cff1508ba45b56e844cb678ca466
For incfs files that were created without a merkle tree, enabling verity
requires building a merkle tree first. Although this is the same logic
as verity performs, it is not that easy to reconcile the two given that
incfs has the merkle tree potentially when verity is not enabled.
Bug: 160634504
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ia15a4051fa3362820846d65859e3af76b77f8cc4
Add ioctl to return the verity file digest, compatible with the identical
ioctl in fs/verity/.
Bug: 160634504
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I1bc2dc975b9be122e1c831a25a1d44f27a360f3c
Now fsverity state is preserved across inode eviction.
Added incfs.verity xattr to track when a file is fs-verity enabled.
Bug: 160634504
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I41d90abd55527884d9eff642c9834ad837ff6918
Add FS_IOC_GETFLAGS ioctl to incfs. Currently this will only get the
S_VERITY flag.
Bug: 160634504
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Id79add0db0d66f604ca0f222fe5faec91450ade5
Add FS_IOC_ENABLE_VERITY ioctl
When called, calculate measurement, validate signature against fsverity,
and set S_VERITY flag.
This does not (yet) preserve the verity status once the inode is
evicted.
Bug: 160634504
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I88af2721f650098accc72a64528c7d85b753c7f6
Bug: 177075428
Test: incfs_test passes
atest GtsIncrementalInstallTestCases has only 8 failures
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I73accfc1982aec1cd7947996c25a23e4a97cfdac
.blocks_writen file handling was missing some operations:
SELinux xattr handlers, safety checks for it being a
pseudo file etc.
This CL generalizes pseudo file handling so that all such
files work in a generic way and next time it should be
easier to add all operations at once.
Bug: 175823975
Test: incfs_tests pass
Change-Id: Id2b1936018c81c62c8ab4cdbaa8827e2679b513f
Signed-off-by: Yurii Zubrytskyi <zyy@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
