- A more aggressive prctl side channel is already implemented by cimb octo app and this is found by backslashxx (https://github.com/backslashxx/)
- The fix is easy same as the one implemented for sus_su by checking the TIF_PROC_UMOUNTED bit in current->thread_info.flags in the very beginning of ksu_handle_prctl()
- Also we need make sure to explicitly check for ksu manager uid in ksu_handle_setuid() before checking for normal user app since ksu maanger app uid is excluded in allow_list_arr which ksu_uid_should_umount(manager_uid) will always return true
Co-authored-by: simonpunk <simonpunk2016@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
- In order to reduce the extra patch code and increase the rate of hunk succeed, we do not rename the symbols in KernelSU drvier but instead do it all in kernel/kallsym.c
- Make susfs_starts_with() global as it maybe useful in future
Co-authored-by: sidex15 <24408329+sidex15@users.noreply.github.com>
Co-authored-by: simonpunk <simonpunk2016@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
KernelSU requires struct seccomp to have atomic_t filter_count ,
but this field is missing on NON-GKI kernels.
Adding the field fixes build errors such as:
error: no member named 'filter_count' in 'struct seccomp'
Reference: https://github.com/tiann/KernelSU/pull/2708
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
- There are two situations only now:
1. if "ksu_susfs hide_sus_mnts_for_all_procs 1" is set(default 1 in kernel), all processes will NOT see any sus mounts in mountinfo
2. if "ksu_susfs hide_sus_mnts_for_all_procs 0" is set, all processes that have NO sus_mounts umounted can still see the sus_mounts, and vice versa, processes that have sus_mounts umounted will NOT see any sus_mounts.
- Make sure "ksu_susfs hide_sus_mnts_for_all_procs 0" is executed only after post-fs-data.sh.
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
This might be strange fix as the other kernel (probably mostly on GKI kernels) work even UID limit is less than 2000
For this kernel (or probably other non-gki kernels) it needs to be set <11000 as most user apps' UID starts at 10000+ range.
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
in case of any infinite bootloop without being able to boot into ksu rescue
mode, see post-fs-data.sh in module template for proer usage
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
There is a few change in here:
- sus_mount functionality still remain in v1.5.5 as backporting it to the latest version will result a mount detection leak in some apps/detectors
Thank you @simonpunk for the help of sus_path backport
Co-authored-by: sidex15 <24408329+sidex15@users.noreply.github.com>
Co-authored-by: simonpunk <simonpunk2016@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Both glibc and musl define 'struct sched_param' in sched.h, while kernel
has it in uapi/linux/sched/types.h, making it cumbersome to use
sched_getattr(2) or sched_setattr(2) from userspace.
For example, something like this:
#include <sched.h>
#include <linux/sched/types.h>
struct sched_attr sa;
will result in "error: redefinition of ‘struct sched_param’" (note the
code doesn't need sched_param at all -- it needs struct sched_attr
plus some stuff from sched.h).
The situation is, glibc is not going to provide a wrapper for
sched_{get,set}attr, thus the need to include linux/sched_types.h
directly, which leads to the above problem.
Thus, the userspace is left with a few sub-par choices when it wants to
use e.g. sched_setattr(2), such as maintaining a copy of struct
sched_attr definition, or using some other ugly tricks.
OTOH, 'struct sched_param' is well known, defined in POSIX, and it won't
be ever changed (as that would break backward compatibility).
So, while 'struct sched_param' is indeed part of the kernel uapi,
exposing it the way it's done now creates an issue, and hiding it
(like this patch does) fixes that issue, hopefully without creating
another one: common userspace software rely on libc headers, and as
for "special" software (like libc), it looks like glibc and musl
do not rely on kernel headers for 'struct sched_param' definition
(but let's Cc their mailing lists in case it's otherwise).
The alternative to this patch would be to move struct sched_attr to,
say, linux/sched.h, or linux/sched/attr.h (the new file).
Oh, and here is the previous attempt to fix the issue:
https://lore.kernel.org/all/20200528135552.GA87103@google.com/
While I support Linus arguments, the issue is still here
and needs to be fixed.
[ mingo: Linus is right, this shouldn't be needed - but on the other
hand I agree that this header is not really helpful to
user-space as-is. So let's pretend that
<uapi/linux/sched/types.h> is only about sched_attr, and
call this commit a workaround for user-space breakage
that it in reality is ... Also, remove the Fixes tag. ]
Change-Id: I3943f8f4a11a9007ccc392de3ece9e62841e8fcb
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20230808030357.1213829-1-kolyshkin@gmail.com
Recent Android deprecated sdcardfs and uses native fs casefold
functionality to achieve case insensitivity on /sdcard[1][2].
However, this breaks overlayfs on userdata partition because this
partition is now formatted with casefold option.
Overlayfs checks DCACHE_OP_{HASH,COMPARE} to ensure the filesystem is
case sensitive. However, this flags userdata partition as a false
positive. Most of the userdata partition is indeed case sensitive
except [3].
So this patch workarounds the issue by removing the check, which is
DANGEROUS! The responsibility to ensure fs case sensitivity is
shifted to the users.
Fixes overlayfs driver for docker.
[1]: https://source.android.com/docs/core/storage/sdcardfs-deprecate
[2]: 5b711b10db/model/PrivateVolume.cpp (170)
[3]: 5b711b10db/model/PrivateVolume.cpp (178)
Change-Id: Ia3a4a81e6772796b3400fd13b89c6f3677e35872
Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
* 'master' of github.com:Linux-on-droid/lindroid-drm-loopback: (429 commits)
lindroid-drm-loopback: vmap: try vm_map_ram first always
lindroid-drm-loopback: encourage reclaim on gem unpin
lindroid-drm-loopback: add evdi_pin_page fast path
lindroid-drm-loopback: remove dmabuf per page array
lindroid-drm-loopback: improve vma flags for drm usage
lindroid-drm-loopback: utilize vmf_insert_page on supported kernels
lindroid-drm-loopback: fix unpinning vma on 4.14
lindroid-drm-loopback: fixes for qcom 4.14 and no CONFIG_MODULES
lindroid-drm-loopback: do not depend on modules
lindroid-drm-loopback: implement a write prefault for <5.15
evdi_drm_drv: guard fault_in_readable/writeable to >=5.15
lindroid-drm-loopback: add_buff: move gralloc_buf to kmem cache
lindroid-drm-loopback: inline evdi_get_buff_callback replies
Fix hotplug
lindroid-drm-loopback: inline add/create buf replies
lindroid-drm-loopback: remove cursor code
lindroid-drm-loopback: free buffers from unconsumed events
lindroid-drm-loopback: check for sleepers before wakeup
lindroid-drm-loopback: defer evdi event free until rcu gp on XArray
lindroid-drm-loopback: add some bp hints
...
Change-Id: I99f90e103fe5ae9e1da9b1d9fd6db9ed0e7e7d72
Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
'commit b6115e14010 ("ANDROID: uid_sys_stat: split the global
lock uid_lock to the fine-grained locks for each hlist in hash_table.")'
The above patch split the global lock to per-uid lock to reduce lock
competition. But result in data-error from uid_cputime_show and uid_io_show in
some cases.
E.g, if thread1 and thread2 read /proc/uid_cputime/show_uid_stat at the same time,
thread2 maybe operate in partA and zero active_stime and active_utime of uid_entry
when thread1 is between partB and partC, which would cause thread1 show the error data.
static int uid_cputime_show(struct seq_file *m, void *v)
{
...
/*partA*/
for (bkt = 0, uid_entry = NULL; uid_entry == NULL &&
bkt < HASH_SIZE(hash_table); bkt++) {
lock_uid_by_bkt(bkt);
hlist_for_each_entry(uid_entry, &hash_table[bkt], hash) {
uid_entry->active_stime = 0;
uid_entry->active_utime = 0;
}
unlock_uid_by_bkt(bkt);
}
rcu_read_lock();
/* partB */
do_each_thread(temp, task) {
...
lock_uid(uid);
if (!(task->flags & PF_EXITING)) {
task_cputime_adjusted(task, &utime, &stime);
uid_entry->active_utime += utime;
uid_entry->active_stime += stime;
}
unlock_uid(uid);
} while_each_thread(temp, task);
rcu_read_unlock();
for (bkt = 0, uid_entry = NULL; uid_entry == NULL &&
bkt < HASH_SIZE(hash_table); bkt++) {
lock_uid_by_bkt(bkt);
hlist_for_each_entry(uid_entry, &hash_table[bkt], hash) {
u64 total_utime = uid_entry->utime +
uid_entry->active_utime;
u64 total_stime = uid_entry->stime +
uid_entry->active_stime;
/* partC */
seq_printf(m, "%d: %llu %llu\n", uid_entry->uid,
ktime_to_us(total_utime), ktime_to_us(total_stime));
}
unlock_uid_by_bkt(bkt);
}
The patch ensures that the calculation and seq_printf of each uid_entry is within
the uid_lock range, in order to accurate data.
Bug: 278138377
Change-Id: Iaa2ccd95c4b4b333f04b2ba18d7699d94017394e
Signed-off-by: lipeifeng <lipeifeng@oppo.com>
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
Amit Pundir at Linaro reported seeing crashes in uid_sys_stats
driver when building with GCC.
Looking into it, it seems the uid_entry_tmp value is used
while only partially initialized, causing potential out of bound
access on the uid_entry io arrays.
This likely has gone unnoticed with clang as I believe we're
using the zero initialization for stack variables security
feature.
So change the logic to fully initialize the uid_entry_tmp
value.
Fixes: 46112c304156 ("ANDROID: uid_sys_stat: instead update_io_stats_uid_locked to update_io_stats_uid")
Reported-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: John Stultz <jstultz@google.com>
Change-Id: I78de245e80ef60aabec78a615c7ba582ab5a2242
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
It was pointed out that since commit b6115e140102 ("ANDROID:
uid_sys_stat: split the global lock uid_lock to the fine-grained locks
for each hlist in hash_table") taking a spin_lock in uid_lock()
causes a scheduling while atomic error if CONFIG_UID_SYS_STATS_DEBUG
is enabled, as get_full_task_comm() takes the mmap_write_lock()
which is a semaphore, breaking the proper ordering.
In the GKI CONFIG_UID_SYS_STATS_DEBUG is disabled, so this went
unnoticed.
The uid_sys_stats logic isn't ever going to go upstream (it depends
on reverting upstream logic) and will hopefully be replaced eventually.
So there's not much reason to drag around this debug logic that is
unused.
So drop it. Less code to schlep forward.
Bug: 320184870
Change-Id: I2cfce79d5a25a3eba11a5509444c07b4642ef2de
Signed-off-by: John Stultz <jstultz@google.com>
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
Update_io_stats_uid_locked would take a long lock-time of uid_lock due to
call do_each_thread to compute uid_entry->io, which would cause to lock
competition sometime.
Using uid_entry_tmp to get the result of update_io_stats_uid, so that we
can unlock_uid during update_io_stats_uid, in order to avoid the
unnecessary lock-time of uid_lock.
Bug: 278138377
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
(cherry picked from https://android-review.googlesource.com/q/commit:c1fa53f3cf85c0a1c23f0e0a944986b4aa049073)
Merged-In: I5be62105e57e2a896a95d906e3c14e17c7f8077d
Change-Id: I5be62105e57e2a896a95d906e3c14e17c7f8077d
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
1.Hash_table in uid_sys_stat is protected by a global lock named id_lock,
which causes some lock competition issue. Actually, uid_lock can be split to
several file-grained locks for each hlist in hash_table, which avoid
the unnecessary lock competition when get different-uid process info.
2. Switching rt-mutex to spinlock, in order to operate with read_rcu_lock.
Bug: 278138377
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
(cherry picked from https://android-review.googlesource.com/q/commit:c949fbdce0bc792dea206c709d909094be579c3a)
Merged-In: Ib252b65e9aebe3a594e6edf075f7aa01f8e6105d
Change-Id: Ib252b65e9aebe3a594e6edf075f7aa01f8e6105d
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
A use-after-free bug was found in the previous custom lock-free list
implementation for the deferred work, so switch functionality to llist
implementation.
While the previous approach atomically handled the list head, it did not
assure the new node's next pointer was assigned before the head was
pointed to the node, allowing the consumer to traverse to an invalid
next pointer.
Additionally, in switching to llists, this patch pulls the entire list
off the list head once and processes it separately, reducing the number
of atomic operations compared with the custom lists's implementation
which pulled one node at a time atomically from the list head.
BUG: KASAN: use-after-free in process_notifier+0x270/0x2dc
Write of size 8 at addr d4ffff89545c3c58 by task Blocking Thread/3431
Pointer tag: [d4], memory tag: [fe]
call trace:
dump_backtrace+0xf8/0x118
show_stack+0x18/0x24
dump_stack_lvl+0x60/0x78
print_report+0x178/0x470
kasan_report+0x8c/0xbc
kasan_tag_mismatch+0x28/0x3c
__hwasan_tag_mismatch+0x30/0x60
process_notifier+0x270/0x2dc
notifier_call_chain+0xb4/0x108
blocking_notifier_call_chain+0x54/0x80
profile_task_exit+0x20/0x2c
do_exit+0xec/0x1114
__arm64_sys_exit_group+0x0/0x24
get_signal+0x93c/0xa78
do_notify_resume+0x158/0x3fc
el0_svc+0x54/0x78
el0t_64_sync_handler+0x44/0xe4
el0t_64_sync+0x190/0x194
Bug: 294468796
Bug: 295787403
Fixes: 8e86825eecfa ("ANDROID: uid_sys_stats: Use a single work for deferred updates")
Signed-off-by: John Stultz <jstultz@google.com>
[nkapron: Squashed with other changes and rewrote the commit message]
Signed-off-by: Neill Kapron <nkapron@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:87647c0c54bbfe865691d8b58988a3ce941b905e)
Merged-In: Id377348c239ec720a5237726bc3632544d737e3b
Change-Id: Id377348c239ec720a5237726bc3632544d737e3b
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
uid_sys_stats tries to acquire a lock when any task exits to do some
bookkeeping in common data structure. If the lock is contended, it
allocates and schedules a work to do the work later to avoid task exit
latency.
In a stress test which creates many tasks exiting, the workqueue can be
overwhelmed by the number of works being scheduled and allocates more
worker threads to handle queue. The growth of the number of threads is
effectively unbounded and can exhaust the process table. This causes
denial of service to userspace trying to fork().
Instead of allocating a new work each, create a linked list of the
update stats deferred work and have a single work to drain the linked
list. The linked list is implemented using an atomic_long_t.
Bug: 294468796
Fixes: 5586278c0fe6 ("ANDROID: uid_sys_stats: defer process_notifier work if uid_lock is contended")
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
(cherry picked from https://android-review.googlesource.com/q/commit:8e86825eecfaaa582ab51a0924b469d2d2adc743)
Merged-In: I15f20f4f69ea66a452bdf815c4ef3a0da3edfd36
Change-Id: I15f20f4f69ea66a452bdf815c4ef3a0da3edfd36
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
process_notifier() is called every time a process exits. When multiple
processes exit roughly at the same time, the uid_lock taken from inside
of process_notifier() will create contention which slows down process
exit. Defer stats accounting in such case to avoid lock contention.
Bug: 261537194
Change-Id: Ia1e9a451eab39eb0dda7eb175bfd71c67f3e0a58
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
(cherry picked from commit 5d96c24be923d9011762de19bcfbade68b103759)
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
Usermode driver expect vulkan device id info from kernel.
Add new KGSL_PROP_VK_DEVICE_ID property support to provide
vk-device-id information.
Change-Id: Ib4f6872fcd3a956caeaad6e7c9f534d7c8e87305
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
Signed-off-by: Carlos Ayrton Lopez Arroyo <15030201@itcelaya.edu.mx>
Signed-off-by: onettboots <blackcocopet@gmail.com>
Usermode driver can query gpu model name to log it.
So add support for new gpu model property.
Change-Id: Ifc3a76c3e6856161e76dfbe26be2a950db71aa5e
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
Signed-off-by: Carlos Ayrton Lopez Arroyo <15030201@itcelaya.edu.mx>
Signed-off-by: onettboots <blackcocopet@gmail.com>
We would have different gpu model name for different hardware
specification. Add support to get gpu model properties from
device tree against gpu hardware configuration.
Change-Id: I85c4e1b1354ed63713535d5f01f6633138516de7
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
Signed-off-by: Carlos Ayrton Lopez Arroyo <15030201@itcelaya.edu.mx>
Signed-off-by: onettboots <blackcocopet@gmail.com>
Use linux thermal pressure API to notify scheduler about cpu frequency
mitigation on lmh violation. It enables to align lmh mitigation with
software scheduler.
Change-Id: I79866637b806d1ad3c78d6a2d786a4482e6039ce
Signed-off-by: Gopala Krishna Nuthaki <quic_gnuthaki@quicinc.com>
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
* These are deprecated on msm-5.4 and newer, also we won't debug this driver,
so there's no point in keeping them, remove them to align with upstream.
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
