diff --git a/kernel/Kbuild b/kernel/Kbuild index fd31bb517040..cc3610a819dd 100644 --- a/kernel/Kbuild +++ b/kernel/Kbuild @@ -61,6 +61,9 @@ endif ifeq ($(CONFIG_KSU_DEBUG),y) ccflags-y += -DCONFIG_KSU_DEBUG=1 endif +ifeq ($(CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHER),y) +ccflags-y += -DCONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHER=1 +endif endif ccflags-y += -I$(srctree)/security/selinux -I$(srctree)/security/selinux/include diff --git a/kernel/Kconfig b/kernel/Kconfig index c77016613edb..88e228117f10 100644 --- a/kernel/Kconfig +++ b/kernel/Kconfig @@ -35,4 +35,12 @@ config KSU_DISABLE_POLICY Escalation will always use the default full root profile, and non-root handling will follow the global umount policy only. +config KSU_X86_PATCH_SYSCALL_DISPATCHER + bool "Dynamically patch x64's hardened syscall dispatcher to support syscall hooks" + depends on KSU && X86_64 + default n + help + Dynamically patch x64's hardened syscall dispatcher to support syscall hooks. This is a + replacement for a kernel source code patch, and is useful for x86_64 LKM mode. + endmenu diff --git a/kernel/core/init.c b/kernel/core/init.c index e6e1b6842314..09b290a93d2d 100644 --- a/kernel/core/init.c +++ b/kernel/core/init.c @@ -27,7 +27,7 @@ #include "feature/selinux_hide.h" #include "infra/symbol_resolver.h" -#if defined(__x86_64__) +#if defined(__x86_64__) && !defined(CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHER) #include #include #ifndef X86_FEATURE_INDIRECT_SAFE @@ -85,7 +85,7 @@ module_param_named(norc, ksu_no_custom_rc, bool, 0); int __init kernelsu_init(void) { -#if defined(__x86_64__) +#if defined(__x86_64__) && !defined(CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHER) // If the kernel has the hardening patch, X86_FEATURE_INDIRECT_SAFE must be set if (!boot_cpu_has(X86_FEATURE_INDIRECT_SAFE)) { pr_alert("*************************************************************"); diff --git a/kernel/hook/patch_memory.h b/kernel/hook/patch_memory.h index b375e1397e4e..1c0b38320eb3 100644 --- a/kernel/hook/patch_memory.h +++ b/kernel/hook/patch_memory.h @@ -18,7 +18,7 @@ #include "asm/insn.h" // IWYU pragma: keep #endif #elif __x86_64__ -#include "asm/text-patching.h" // IWYU pragma: keep +#include #else #error "Unsupported arch" #endif diff --git a/kernel/hook/x86_64/syscall_hook.c b/kernel/hook/x86_64/syscall_hook.c index e693bc993dde..1601efe688e5 100644 --- a/kernel/hook/x86_64/syscall_hook.c +++ b/kernel/hook/x86_64/syscall_hook.c @@ -4,6 +4,7 @@ #include #include +#include #include #include "infra/symbol_resolver.h" #include "../patch_memory.h" @@ -13,6 +14,10 @@ sys_call_ptr_t *ksu_syscall_table = NULL; int ksu_dispatcher_nr = -1; +#ifndef __NR_syscalls +#define __NR_syscalls (__NR_syscall_max + 1) +#endif + // Hook registration table — read with READ_ONCE from tracepoint/dispatcher // context, written with WRITE_ONCE from init/exit context. static ksu_syscall_hook_fn syscall_hooks[__NR_syscalls]; @@ -198,18 +203,120 @@ bool ksu_has_syscall_hook(int nr) return READ_ONCE(syscall_hooks[nr]) != NULL; } -void __init ksu_syscall_hook_init(void) +// https://github.com/torvalds/linux/commit/1e3ad78334a69b36e107232e337f9d693dcc9df2 +// harden syscall table was introduced in 6.9, but it was backported to almost +// all of GKI kernel except 5.10 +#ifdef CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHER +static void *x64_sys_call_patch_addr; +static char x64_sys_call_patch_orig_insn[14]; + +static long my_x64_sys_call(const struct pt_regs *regs, unsigned int nr) +{ + return ksu_syscall_table[nr](regs); +} + +// avd 13-5.15 missing this commit: +// https://github.com/torvalds/linux/commit/fb13b11d53875e28e7fbf0c26b288e4ea676aa9f +// we need to patch the whole do_syscall_64 +#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 16, 0) +static void *do_syscall_64_patch_addr; +static char do_syscall_64_orig_insn[14]; + +static long (*syscall_enter_from_user_mode_fn)(struct pt_regs *regs, long syscall); +static void (*syscall_exit_to_user_mode_fn)(struct pt_regs *regs); + +static __always_inline bool my_do_syscall_x64(struct pt_regs *regs, int nr) +{ + /* + * Convert negative numbers to very high and thus out of range + * numbers for comparisons. + */ + unsigned int unr = nr; + + if (likely(unr < NR_syscalls)) { + unr = array_index_nospec(unr, NR_syscalls); + regs->ax = ksu_syscall_table[unr](regs); + return true; + } + return false; +} + +static void __nocfi my_do_syscall_64(struct pt_regs *regs, int nr) +{ + nr = syscall_enter_from_user_mode_fn(regs, nr); + nr = syscall_get_nr(current, regs); + + // AVD doesn't have x32 support after A13, we can ignore do_syscall_x32 + + if (!my_do_syscall_x64(regs, nr) && nr != -1) { + /* Invalid system call, but still a system call. */ + regs->ax = -ENOSYS; + } + + syscall_exit_to_user_mode_fn(regs); +} +#endif +#endif + +static void patch_abs_jump(const char *sym, void **patch_addr, void *target, char backup[14]) +{ + *patch_addr = (void *)find_kernel_symbol_exact(sym); + pr_info("%s=0x%lx\n", sym, (unsigned long)*patch_addr); + if (*patch_addr) { + pr_info("patching %s\n", sym); + // skip endbr64 + static const char endbr64_insn[] = { + // clang-format off + 0xf3, 0x0f, 0x1e, 0xfa + // clang-format on + }; + if (memcmp((void *)*patch_addr, endbr64_insn, sizeof(endbr64_insn)) == 0) { + pr_info("%s: skip endbr64\n", sym); + *patch_addr = (void *)((char *)(*patch_addr) + 4); + } + // clang-format off + char buf[] = { + // jmp *(%rip) = addr + 0xff, 0x25, 0x00, 0x00, 0x00, 0x00, + // addr: .quad 0 + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + }; + // clang-format on + *((void **)(buf + 6)) = target; + memcpy(backup, *patch_addr, sizeof(buf)); + int ret = ksu_patch_text(*patch_addr, buf, sizeof(buf), KSU_PATCH_TEXT_FLUSH_ICACHE); + if (ret) { + pr_err("patch %s err: %d\n", sym, ret); + *patch_addr = NULL; + } + } +} + +void __init __nocfi ksu_syscall_hook_init(void) { int ni_slot; memset(syscall_hooks, 0, sizeof(syscall_hooks)); ksu_syscall_table = (sys_call_ptr_t *)ksu_resolve_symbol_for_functable_hook("sys_call_table"); - pr_info("sys_call_table=0x%lx", (unsigned long)ksu_syscall_table); + pr_info("sys_call_table=0x%lx\n", (unsigned long)ksu_syscall_table); if (!ksu_syscall_table) return; +#ifdef CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHER + patch_abs_jump("x64_sys_call", &x64_sys_call_patch_addr, my_x64_sys_call, x64_sys_call_patch_orig_insn); +#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 16, 0) + syscall_enter_from_user_mode_fn = find_kernel_symbol_exact("syscall_enter_from_user_mode"); + syscall_exit_to_user_mode_fn = find_kernel_symbol_exact("syscall_exit_to_user_mode"); + pr_info("syscall_enter_from_user_mode: 0x%lx, syscall_exit_to_user_mode: 0x%lx\n", + (unsigned long)syscall_enter_from_user_mode_fn, (unsigned long)syscall_exit_to_user_mode_fn); + if (syscall_enter_from_user_mode_fn && syscall_exit_to_user_mode_fn) { + patch_abs_jump("do_syscall_64", &do_syscall_64_patch_addr, my_do_syscall_64, do_syscall_64_orig_insn); + } +#endif +#endif + // Find one ni_syscall slot for the dispatcher if (ksu_find_ni_syscall_slots(&ni_slot, 1) < 1) { pr_err("failed to find ni_syscall slot for dispatcher\n"); @@ -225,6 +332,27 @@ void __exit ksu_syscall_hook_exit(void) { int i; +#ifdef CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHER + int ret; + if (x64_sys_call_patch_addr) { + ret = ksu_patch_text((void *)x64_sys_call_patch_addr, x64_sys_call_patch_orig_insn, + sizeof(x64_sys_call_patch_orig_insn), KSU_PATCH_TEXT_FLUSH_ICACHE); + if (ret) { + pr_err("restore x64_sys_call err: %d\n", ret); + } + } + +#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 16, 0) + if (do_syscall_64_patch_addr) { + ret = ksu_patch_text((void *)do_syscall_64_patch_addr, do_syscall_64_orig_insn, sizeof(do_syscall_64_orig_insn), + KSU_PATCH_TEXT_FLUSH_ICACHE); + if (ret) { + pr_err("restore x64_sys_call err: %d\n", ret); + } + } +#endif +#endif + if (!ksu_syscall_table) goto clear_state; diff --git a/website/docs/.vitepress/locales/id_ID.ts b/website/docs/.vitepress/locales/id_ID.ts index d0e506d08c34..1ad2df3a8b4a 100644 --- a/website/docs/.vitepress/locales/id_ID.ts +++ b/website/docs/.vitepress/locales/id_ID.ts @@ -53,6 +53,7 @@ function sidebarGuide() { { text: 'Metamodule', link: '/id_ID/guide/metamodule.md' }, { text: 'Konfigurasi Modul', link: '/id_ID/guide/module-config.md' }, { text: 'Antisipasi dari bootloop', link: '/id_ID/guide/rescue-from-bootloop.md' }, + { text: 'Dukungan x86_64', link: '/id_ID/guide/x86_64-support' }, { text: 'FAQ', link: '/id_ID/guide/faq' }, ] } diff --git a/website/docs/.vitepress/locales/ja_JP.ts b/website/docs/.vitepress/locales/ja_JP.ts index c51b330546d6..dcedf55243fc 100644 --- a/website/docs/.vitepress/locales/ja_JP.ts +++ b/website/docs/.vitepress/locales/ja_JP.ts @@ -53,6 +53,7 @@ function sidebarGuide() { { text: 'メタモジュール', link: '/ja_JP/guide/metamodule.md' }, { text: 'モジュール設定', link: '/ja_JP/guide/module-config.md' }, { text: 'ブートループからの復旧', link: '/ja_JP/guide/rescue-from-bootloop.md' }, + { text: 'x86_64 サポート', link: '/ja_JP/guide/x86_64-support' }, { text: 'よくある質問', link: '/ja_JP/guide/faq' }, { text: '隠し機能', link: '/ja_JP/guide/hidden-features' }, ] diff --git a/website/docs/.vitepress/locales/pt_BR.ts b/website/docs/.vitepress/locales/pt_BR.ts index 6f7ecceec7f2..20b01b57139c 100644 --- a/website/docs/.vitepress/locales/pt_BR.ts +++ b/website/docs/.vitepress/locales/pt_BR.ts @@ -56,6 +56,7 @@ function sidebarGuide() { { text: 'Configuração de Módulo', link: '/pt_BR/guide/module-config.md' }, { text: 'Perfil do Aplicativo', link: '/pt_BR/guide/app-profile.md' }, { text: 'Resgate do bootloop', link: '/pt_BR/guide/rescue-from-bootloop.md' }, + { text: 'Suporte a x86_64', link: '/pt_BR/guide/x86_64-support' }, { text: 'Perguntas frequentes', link: '/pt_BR/guide/faq' }, { text: 'Recursos ocultos', link: '/pt_BR/guide/hidden-features' }, ] diff --git a/website/docs/.vitepress/locales/ru_RU.ts b/website/docs/.vitepress/locales/ru_RU.ts index e80fed32b84e..737d84b94491 100644 --- a/website/docs/.vitepress/locales/ru_RU.ts +++ b/website/docs/.vitepress/locales/ru_RU.ts @@ -54,6 +54,7 @@ function sidebarGuide() { { text: 'Конфигурация модулей', link: '/ru_RU/guide/module-config.md' }, { text: 'Профиль приложений', link: '/ru_RU/guide/app-profile.md' }, { text: 'Выход из циклической загрузки', link: '/ru_RU/guide/rescue-from-bootloop.md' }, + { text: 'Поддержка x86_64', link: '/ru_RU/guide/x86_64-support' }, { text: 'FAQ', link: '/ru_RU/guide/faq' }, { text: 'Скрытые возможности', link: '/ru_RU/guide/hidden-features' }, ] diff --git a/website/docs/.vitepress/locales/vi_VN.ts b/website/docs/.vitepress/locales/vi_VN.ts index cb5091075430..8895efb8a91e 100644 --- a/website/docs/.vitepress/locales/vi_VN.ts +++ b/website/docs/.vitepress/locales/vi_VN.ts @@ -51,6 +51,7 @@ function sidebarGuide() { { text: 'Thiết bị hỗ trợ không chính thức', link: '/vi_VN/guide/unofficially-support-devices.md' }, { text: 'Metamodule', link: '/vi_VN/guide/metamodule.md' }, { text: 'Cấu hình module', link: '/vi_VN/guide/module-config.md' }, + { text: 'Hỗ trợ x86_64', link: '/vi_VN/guide/x86_64-support' }, { text: 'FAQ - Câu hỏi thường gặp', link: '/vi_VN/guide/faq' }, ] } diff --git a/website/docs/.vitepress/locales/zh_CN.ts b/website/docs/.vitepress/locales/zh_CN.ts index b133bc1114e7..099d69c9099d 100644 --- a/website/docs/.vitepress/locales/zh_CN.ts +++ b/website/docs/.vitepress/locales/zh_CN.ts @@ -56,6 +56,7 @@ function sidebarGuide() { { text: '模块配置', link: '/zh_CN/guide/module-config.md' }, { text: 'App Profile', link: '/zh_CN/guide/app-profile.md' }, { text: '救砖', link: '/zh_CN/guide/rescue-from-bootloop.md' }, + { text: 'x86_64 支持', link: '/zh_CN/guide/x86_64-support' }, { text: '常见问题', link: '/zh_CN/guide/faq' }, { text: '隐藏功能', link: '/zh_CN/guide/hidden-features' }, ] diff --git a/website/docs/.vitepress/locales/zh_TW.ts b/website/docs/.vitepress/locales/zh_TW.ts index a61374c3df6f..78ccadc8bd86 100644 --- a/website/docs/.vitepress/locales/zh_TW.ts +++ b/website/docs/.vitepress/locales/zh_TW.ts @@ -56,6 +56,7 @@ function sidebarGuide() { { text: '模組配置', link: '/zh_TW/guide/module-config.md' }, { text: 'App Profile', link: '/zh_TW/guide/app-profile.md' }, { text: '搶救開機迴圈', link: '/zh_TW/guide/rescue-from-bootloop.md' }, + { text: 'x86_64 支援', link: '/zh_TW/guide/x86_64-support' }, { text: '常見問題', link: '/zh_TW/guide/faq' }, { text: '隱藏功能', link: '/zh_TW/guide/hidden-features' }, ] diff --git a/website/docs/guide/x86_64-support.md b/website/docs/guide/x86_64-support.md index aa71764875e7..c0c35ce35fe0 100644 --- a/website/docs/guide/x86_64-support.md +++ b/website/docs/guide/x86_64-support.md @@ -1,24 +1,41 @@ # x86_64 Support -KernelSU fully supports the `x86_64` architecture. However, due to recent upstream kernel security changes, integrating KernelSU on modern `x86_64` kernels requires manual patching to allow our unified syscall dispatcher to function correctly. +KernelSU fully supports the `x86_64` architecture. However, due to recent upstream kernel security changes, integrating KernelSU on modern `x86_64` kernels requires additional handling so our unified syscall dispatcher can function correctly. ## Why did it break? In newer kernel versions, a [commit](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2) was introduced to harden the syscall table. This change converted indirect branches within the system call path into a series of direct conditional branches. -KernelSU's `syscall_hook` mechanism relies on an indirect jump to route intercepted system calls to our unified dispatcher. Because the new hardening forces direct calls, the kernel blocks our dispatcher. If KernelSU attempts to load and hook the syscall table without the proper mitigations disabled, it will fail to route the calls and cleanly abort initialization to prevent a kernel panic. +KernelSU's `syscall_hook` mechanism relies on modifying entries in the syscall table so intercepted system calls can be routed to our unified dispatcher. Because the new hardening changes the syscall path, the kernel ignores those syscall table modifications. If KernelSU attempts to load and hook the syscall table without handling this limitation correctly, it will fail to route the calls and cleanly abort initialization to prevent a kernel panic. ## How to fix it? -To make KernelSU work on these newer kernels, you must apply a patch that allows you to bypass this specific syscall hardening. +There are two supported ways to handle this syscall hook issue on `x86_64`: + +1. Enable the kernel build option `KSU_X86_PATCH_SYSCALL_DISPATCHER`. +2. Continue using the original kernel source patch method. + +You only need to use one of them. Do not apply both at the same time. + +### Option 1: Enable `KSU_X86_PATCH_SYSCALL_DISPATCHER` + +KernelSU 3.2.6 introduced an official mechanism for `x86_64`: the build option `KSU_X86_PATCH_SYSCALL_DISPATCHER`. + +When this option is enabled, KernelSU dynamically patches the hardened syscall dispatcher at runtime so the syscall hook can work without requiring the previous kernel source patch set. This is the recommended approach if you are building a kernel with KernelSU 3.2.6 or newer. + +### Option 2: Apply the original kernel source patches + +If you do not want to enable `KSU_X86_PATCH_SYSCALL_DISPATCHER`, you can continue to use the original kernel patch approach. + +To make KernelSU work on these newer kernels, apply a patch that allows you to bypass this specific syscall hardening. ::: danger SECURITY WARNING -By applying these patches and disabling syscall hardening, you are intentionally bypassing a mitigation designed to protect against speculative execution vulnerabilities. +By using either of these two solutions, you are intentionally bypassing or weakening a mitigation designed to protect against speculative execution vulnerabilities. -This re-opens the indirect branch attack surface for system calls. **Do not apply these patches if you are running a production server or a system where strict side-channel security is critical.** This is intended for testing environments where root access via KernelSU is prioritized over this specific hardware vulnerability mitigation. +This re-opens the indirect branch attack surface for system calls. **Do not use either solution if you are running a production server or a system where strict side-channel security is critical.** These approaches are intended for testing environments where root access via KernelSU is prioritized over this specific hardware vulnerability mitigation. ::: -Choose & apply the patches that match your kernel version below. These patches will create a feature called `X86_FEATURE_INDIRECT_SAFE` and can be activated using the cmdline `syscall_hardening=off`. +Choose and apply the patches that match your kernel version below. These patches create a feature called `X86_FEATURE_INDIRECT_SAFE` and can be activated using the kernel cmdline `syscall_hardening=off`. ``` For kernel 6.6: @@ -33,3 +50,9 @@ For kernel 6.18: https://github.com/android-generic/kernel-zenith/commit/40b1c323d1ad29c86e041d665c7f089b9a3ccfb5 https://github.com/android-generic/kernel-zenith/commit/f5813e10b7630e1ccd86fc2c4cf30eef60b64a82 ``` + +## Which method should I choose? + +- If you are using KernelSU 3.2.6 or newer and can change the KernelSU build configuration, enable `KSU_X86_PATCH_SYSCALL_DISPATCHER`. +- If you prefer to keep your current kernel-side patch workflow, continue using the original source patches above. + diff --git a/website/docs/id_ID/guide/x86_64-support.md b/website/docs/id_ID/guide/x86_64-support.md new file mode 100644 index 000000000000..fe2887c01fdf --- /dev/null +++ b/website/docs/id_ID/guide/x86_64-support.md @@ -0,0 +1,57 @@ +# Dukungan x86_64 + +KernelSU mendukung arsitektur `x86_64` sepenuhnya. Namun, karena perubahan keamanan upstream kernel terbaru, integrasi KernelSU pada kernel `x86_64` modern memerlukan penanganan tambahan agar unified syscall dispatcher milik kita dapat berfungsi dengan benar. + +## Mengapa ini rusak? + +Pada versi kernel yang lebih baru, sebuah [commit](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2) diperkenalkan untuk memperketat syscall table. Perubahan ini mengubah branch tidak langsung dalam jalur system call menjadi serangkaian branch kondisional langsung. + +Mekanisme `syscall_hook` KernelSU bergantung pada modifikasi entri di syscall table agar system call yang dicegat dapat diarahkan ke unified dispatcher. Karena hardening baru mengubah jalur system call, kernel akan mengabaikan modifikasi pada syscall table tersebut. Jika KernelSU mencoba dimuat dan melakukan hook pada syscall table tanpa menangani pembatasan ini dengan benar, ia tidak akan dapat merutekan panggilan dan akan membatalkan inisialisasi untuk mencegah kernel panic. + +## Bagaimana cara memperbaikinya? + +Sekarang ada dua cara yang didukung untuk menangani masalah syscall hook pada `x86_64`: + +1. Aktifkan opsi build kernel `KSU_X86_PATCH_SYSCALL_DISPATCHER`. +2. Tetap gunakan metode patch kode sumber kernel yang lama. + +Anda hanya perlu memakai salah satunya. Jangan menerapkan keduanya sekaligus. + +### Opsi 1: Aktifkan `KSU_X86_PATCH_SYSCALL_DISPATCHER` + +KernelSU 3.2.6 memperkenalkan mekanisme resmi baru untuk `x86_64`, yaitu opsi build `KSU_X86_PATCH_SYSCALL_DISPATCHER`. + +Saat opsi ini diaktifkan, KernelSU akan melakukan patch dinamis pada hardened syscall dispatcher saat runtime sehingga syscall hook dapat bekerja tanpa memerlukan kumpulan patch kode sumber kernel lama. Ini adalah pendekatan yang direkomendasikan jika Anda membangun kernel dengan KernelSU 3.2.6 atau yang lebih baru. + +### Opsi 2: Terapkan patch kode sumber kernel lama + +Jika Anda tidak ingin mengaktifkan `KSU_X86_PATCH_SYSCALL_DISPATCHER`, Anda tetap dapat menggunakan pendekatan patch kernel yang lama. + +Agar KernelSU dapat bekerja pada kernel yang lebih baru ini, terapkan patch yang memungkinkan Anda melewati syscall hardening khusus ini. + +::: danger PERINGATAN KEAMANAN +Dengan menggunakan salah satu dari dua solusi ini, Anda secara sengaja melewati atau melemahkan mekanisme mitigasi yang dirancang untuk melindungi dari kerentanan speculative execution. + +Ini kembali membuka permukaan serangan indirect branch untuk system call. **Jangan gunakan salah satu dari dua solusi ini jika Anda menjalankan server produksi atau sistem yang membutuhkan keamanan side-channel yang ketat.** Solusi-solusi ini ditujukan untuk lingkungan pengujian, di mana akses root melalui KernelSU lebih diprioritaskan daripada mitigasi kerentanan perangkat keras tertentu ini. +::: + +Pilih dan terapkan patch yang sesuai dengan versi kernel Anda di bawah ini. Patch ini membuat fitur bernama `X86_FEATURE_INDIRECT_SAFE` dan dapat diaktifkan menggunakan parameter kernel cmdline `syscall_hardening=off`. + +``` +For kernel 6.6: +https://github.com/android-generic/kernel_common/commit/fe9a9b4c320577c30e1f22d04039e414c6a3cdec +https://github.com/android-generic/kernel_common/commit/df772e99e392f24b395ceaf7b26974e3e4828ee9 + +For kernel 6.12: +https://github.com/android-generic/kernel-zenith/commit/dd2c602268fdc81f4d3b662f6a15142ac0ec7bcd +https://github.com/android-generic/kernel-zenith/commit/7d99237ae5da61c19447138da3282ae37d43857b + +For kernel 6.18: +https://github.com/android-generic/kernel-zenith/commit/40b1c323d1ad29c86e041d665c7f089b9a3ccfb5 +https://github.com/android-generic/kernel-zenith/commit/f5813e10b7630e1ccd86fc2c4cf30eef60b64a82 +``` + +## Metode mana yang sebaiknya dipilih? + +- Jika Anda menggunakan KernelSU 3.2.6 atau lebih baru dan bisa mengubah konfigurasi build KernelSU, aktifkan `KSU_X86_PATCH_SYSCALL_DISPATCHER`. +- Jika Anda ingin mempertahankan alur kerja patch kernel saat ini, lanjutkan menggunakan patch kode sumber di atas. diff --git a/website/docs/ja_JP/guide/x86_64-support.md b/website/docs/ja_JP/guide/x86_64-support.md new file mode 100644 index 000000000000..db361e8a460a --- /dev/null +++ b/website/docs/ja_JP/guide/x86_64-support.md @@ -0,0 +1,57 @@ +# x86_64 サポート + +KernelSU は `x86_64` アーキテクチャを完全にサポートしています。ただし、upstream kernel の最近のセキュリティ変更により、最新の `x86_64` カーネルへ KernelSU を統合するには、統一された syscall dispatcher を正しく動作させるための追加対応が必要です。 + +## なぜ動かなくなったのですか? + +新しいカーネルバージョンでは、syscall table を強化するための [コミット](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2) が導入されました。この変更により、システムコール経路内の間接分岐が一連の直接条件分岐へ変換されました。 + +KernelSU の `syscall_hook` は、フックしたシステムコールを統一 dispatcher にルーティングするために syscall table のエントリ変更へ依存しています。新しい hardening はシステムコール経路を変更するため、カーネルはそれらの syscall table 変更を無視します。KernelSU がこの制限を正しく処理しないまま syscall table を hook しようとすると、呼び出しを正しくルーティングできず、kernel panic を防ぐために初期化を中断します。 + +## どうすればよいですか? + +`x86_64` の syscall hook 問題には 2 つの公式サポートされた方法があります。 + +1. カーネルのビルドオプション `KSU_X86_PATCH_SYSCALL_DISPATCHER` を有効にする。 +2. 従来どおりカーネルソースパッチ方式を使う。 + +必要なのはどちらか一方だけです。両方を同時に適用しないでください。 + +### 方法 1: `KSU_X86_PATCH_SYSCALL_DISPATCHER` を有効にする + +KernelSU 3.2.6 では、`x86_64` 向けの新しい公式メカニズムとして `KSU_X86_PATCH_SYSCALL_DISPATCHER` ビルドオプションが追加されました。 + +このオプションを有効にすると、KernelSU は hardened syscall dispatcher を実行時に動的パッチし、従来のカーネルソースパッチを要求せずに syscall hook を動作させます。KernelSU 3.2.6 以降でカーネルをビルドする場合は、この方法を推奨します。 + +### 方法 2: 従来のカーネルソースパッチを適用する + +`KSU_X86_PATCH_SYSCALL_DISPATCHER` を有効にしたくない場合は、これまでのカーネルパッチ方式を継続して使えます。 + +これらの新しいカーネルで KernelSU を動作させるには、この syscall hardening を回避できるパッチを適用してください。 + +::: danger セキュリティ警告 +この 2 つの方法のいずれかを使うことは、speculative execution 脆弱性への対策を意図的に回避または弱めることを意味します。 + +これにより、system call に対する間接分岐の攻撃面が再び開かれます。**本番サーバーや、厳格な side-channel セキュリティが重要なシステムでは、これら 2 つの方法のいずれも使わないでください。** これらの方法は、特定のハードウェア脆弱性対策よりも KernelSU による root アクセスを優先するテスト環境向けです。 +::: + +以下からカーネルバージョンに一致するパッチを選んで適用してください。これらのパッチは `X86_FEATURE_INDIRECT_SAFE` という機能を作成し、カーネルコマンドライン `syscall_hardening=off` で有効化できます。 + +``` +For kernel 6.6: +https://github.com/android-generic/kernel_common/commit/fe9a9b4c320577c30e1f22d04039e414c6a3cdec +https://github.com/android-generic/kernel_common/commit/df772e99e392f24b395ceaf7b26974e3e4828ee9 + +For kernel 6.12: +https://github.com/android-generic/kernel-zenith/commit/dd2c602268fdc81f4d3b662f6a15142ac0ec7bcd +https://github.com/android-generic/kernel-zenith/commit/7d99237ae5da61c19447138da3282ae37d43857b + +For kernel 6.18: +https://github.com/android-generic/kernel-zenith/commit/40b1c323d1ad29c86e041d665c7f089b9a3ccfb5 +https://github.com/android-generic/kernel-zenith/commit/f5813e10b7630e1ccd86fc2c4cf30eef60b64a82 +``` + +## どちらを選ぶべきですか? + +- KernelSU 3.2.6 以降を使っていて、KernelSU のビルド設定を変更できるなら `KSU_X86_PATCH_SYSCALL_DISPATCHER` を有効にしてください。 +- 現在のカーネルパッチ運用を維持したいなら、上記の従来のソースパッチを使い続けてください。 diff --git a/website/docs/pt_BR/guide/x86_64-support.md b/website/docs/pt_BR/guide/x86_64-support.md new file mode 100644 index 000000000000..c2938e054be7 --- /dev/null +++ b/website/docs/pt_BR/guide/x86_64-support.md @@ -0,0 +1,57 @@ +# Suporte a x86_64 + +O KernelSU oferece suporte completo à arquitetura `x86_64`. No entanto, devido a mudanças recentes de segurança no kernel upstream, integrar o KernelSU em kernels `x86_64` modernos exige um tratamento adicional para que nosso dispatcher unificado de syscall funcione corretamente. + +## Por que isso quebrou? + +Em versões mais novas do kernel, um [commit](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2) foi introduzido para reforçar a proteção da syscall table. Essa mudança converteu desvios indiretos no caminho de system call em uma série de desvios condicionais diretos. + +O mecanismo `syscall_hook` do KernelSU depende da modificação de entradas na syscall table para que syscalls interceptadas possam ser encaminhadas ao dispatcher unificado. Como o novo hardening muda o caminho das system calls, o kernel ignora essas modificações na syscall table. Se o KernelSU tentar carregar e aplicar hook na syscall table sem tratar corretamente essa limitação, ele não conseguirá encaminhar as chamadas e abortará a inicialização para evitar um kernel panic. + +## Como corrigir? + +Agora existem duas formas suportadas de lidar com esse problema de syscall hook em `x86_64`: + +1. Ativar a opção de compilação do kernel `KSU_X86_PATCH_SYSCALL_DISPATCHER`. +2. Continuar usando o método original com patches no código-fonte do kernel. + +Você só precisa usar uma delas. Não aplique ambas ao mesmo tempo. + +### Opção 1: Ativar `KSU_X86_PATCH_SYSCALL_DISPATCHER` + +O KernelSU 3.2.6 introduziu um novo mecanismo oficial para `x86_64`: a opção de build `KSU_X86_PATCH_SYSCALL_DISPATCHER`. + +Quando essa opção está ativada, o KernelSU aplica um patch dinâmico no dispatcher hardened de syscall em tempo de execução, permitindo que o syscall hook funcione sem exigir o conjunto anterior de patches no código-fonte do kernel. Essa é a abordagem recomendada se você estiver compilando um kernel com KernelSU 3.2.6 ou mais recente. + +### Opção 2: Aplicar os patches originais no código-fonte do kernel + +Se você não quiser ativar `KSU_X86_PATCH_SYSCALL_DISPATCHER`, ainda pode continuar usando a abordagem original com patches no kernel. + +Para fazer o KernelSU funcionar nesses kernels mais novos, aplique um patch que permita contornar esse hardening específico de syscall. + +::: danger AVISO DE SEGURANÇA +Ao usar qualquer uma dessas duas soluções, você está intencionalmente contornando ou enfraquecendo uma mitigação projetada para proteger contra vulnerabilidades de execução especulativa. + +Isso reabre a superfície de ataque de desvios indiretos para system calls. **Não use nenhuma dessas soluções se você estiver executando um servidor de produção ou um sistema em que a segurança contra side-channel seja crítica.** Essas abordagens se destinam a ambientes de teste, onde o acesso root via KernelSU é priorizado em relação a essa mitigação específica de vulnerabilidade de hardware. +::: + +Escolha e aplique os patches correspondentes à versão do seu kernel abaixo. Esses patches criam um recurso chamado `X86_FEATURE_INDIRECT_SAFE` e podem ser ativados com o parâmetro de linha de comando do kernel `syscall_hardening=off`. + +``` +For kernel 6.6: +https://github.com/android-generic/kernel_common/commit/fe9a9b4c320577c30e1f22d04039e414c6a3cdec +https://github.com/android-generic/kernel_common/commit/df772e99e392f24b395ceaf7b26974e3e4828ee9 + +For kernel 6.12: +https://github.com/android-generic/kernel-zenith/commit/dd2c602268fdc81f4d3b662f6a15142ac0ec7bcd +https://github.com/android-generic/kernel-zenith/commit/7d99237ae5da61c19447138da3282ae37d43857b + +For kernel 6.18: +https://github.com/android-generic/kernel-zenith/commit/40b1c323d1ad29c86e041d665c7f089b9a3ccfb5 +https://github.com/android-generic/kernel-zenith/commit/f5813e10b7630e1ccd86fc2c4cf30eef60b64a82 +``` + +## Qual método devo escolher? + +- Se você estiver usando KernelSU 3.2.6 ou mais recente e puder alterar a configuração de build do KernelSU, ative `KSU_X86_PATCH_SYSCALL_DISPATCHER`. +- Se preferir manter seu fluxo atual baseado em patches no kernel, continue usando os patches de código-fonte acima. diff --git a/website/docs/ru_RU/guide/x86_64-support.md b/website/docs/ru_RU/guide/x86_64-support.md new file mode 100644 index 000000000000..59ce56a12bf1 --- /dev/null +++ b/website/docs/ru_RU/guide/x86_64-support.md @@ -0,0 +1,57 @@ +# Поддержка x86_64 + +KernelSU полностью поддерживает архитектуру `x86_64`. Однако из-за недавних изменений безопасности в upstream kernel для интеграции KernelSU в современные ядра `x86_64` требуется дополнительная обработка, чтобы наш единый dispatcher системных вызовов работал корректно. + +## Почему это перестало работать? + +В более новых версиях ядра был добавлен [коммит](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2), усиливающий защиту syscall table. Это изменение преобразовало косвенные переходы в пути системных вызовов в серию прямых условных переходов. + +Механизм `syscall_hook` в KernelSU опирается на изменение записей в syscall table, чтобы перенаправлять перехваченные системные вызовы в единый dispatcher. Поскольку новое hardening-изменение меняет путь системных вызовов, ядро игнорирует такие изменения syscall table. Если KernelSU попытается загрузиться и установить hook на syscall table без корректной обработки этого ограничения, он не сможет маршрутизировать вызовы и безопасно прервет инициализацию, чтобы избежать kernel panic. + +## Как исправить? + +Есть два поддерживаемых способа решить проблему syscall hook на `x86_64`: + +1. Включить опцию сборки ядра `KSU_X86_PATCH_SYSCALL_DISPATCHER`. +2. Продолжить использовать исходный способ с патчами исходного кода ядра. + +Нужно выбрать только один из них. Не применяйте оба варианта одновременно. + +### Вариант 1: включить `KSU_X86_PATCH_SYSCALL_DISPATCHER` + +В KernelSU 3.2.6 был добавлен новый официальный механизм для `x86_64`: опция сборки `KSU_X86_PATCH_SYSCALL_DISPATCHER`. + +Когда эта опция включена, KernelSU динамически патчит hardened dispatcher системных вызовов во время выполнения, чтобы syscall hook работал без прежнего набора патчей исходного кода ядра. Это рекомендуемый вариант, если вы собираете ядро с KernelSU 3.2.6 или новее. + +### Вариант 2: применить исходные патчи к исходному коду ядра + +Если вы не хотите включать `KSU_X86_PATCH_SYSCALL_DISPATCHER`, можно продолжить использовать прежний подход с патчами ядра. + +Чтобы KernelSU работал на этих более новых ядрах, примените патчи, которые позволяют обойти именно это syscall hardening. + +::: danger ПРЕДУПРЕЖДЕНИЕ О БЕЗОПАСНОСТИ +Используя любой из этих двух способов, вы намеренно обходите или ослабляете механизм защиты, предназначенный для снижения риска уязвимостей speculative execution. + +Это снова открывает поверхность атаки через косвенные переходы для системных вызовов. **Не используйте ни один из этих способов, если вы используете production-сервер или систему, где критична строгая защита от side-channel атак.** Эти варианты предназначены для тестовых окружений, где root-доступ через KernelSU важнее данной конкретной аппаратной mitigation. +::: + +Выберите и примените патчи, соответствующие вашей версии ядра. Эти патчи создают возможность `X86_FEATURE_INDIRECT_SAFE`, которую можно активировать через параметр командной строки ядра `syscall_hardening=off`. + +``` +For kernel 6.6: +https://github.com/android-generic/kernel_common/commit/fe9a9b4c320577c30e1f22d04039e414c6a3cdec +https://github.com/android-generic/kernel_common/commit/df772e99e392f24b395ceaf7b26974e3e4828ee9 + +For kernel 6.12: +https://github.com/android-generic/kernel-zenith/commit/dd2c602268fdc81f4d3b662f6a15142ac0ec7bcd +https://github.com/android-generic/kernel-zenith/commit/7d99237ae5da61c19447138da3282ae37d43857b + +For kernel 6.18: +https://github.com/android-generic/kernel-zenith/commit/40b1c323d1ad29c86e041d665c7f089b9a3ccfb5 +https://github.com/android-generic/kernel-zenith/commit/f5813e10b7630e1ccd86fc2c4cf30eef60b64a82 +``` + +## Какой вариант выбрать? + +- Если вы используете KernelSU 3.2.6 или новее и можете изменить конфигурацию сборки KernelSU, включите `KSU_X86_PATCH_SYSCALL_DISPATCHER`. +- Если вы хотите сохранить текущий workflow с патчами ядра, продолжайте использовать исходные патчи выше. diff --git a/website/docs/vi_VN/guide/x86_64-support.md b/website/docs/vi_VN/guide/x86_64-support.md new file mode 100644 index 000000000000..7cad39ae492c --- /dev/null +++ b/website/docs/vi_VN/guide/x86_64-support.md @@ -0,0 +1,57 @@ +# Hỗ trợ x86_64 + +KernelSU hỗ trợ đầy đủ kiến trúc `x86_64`. Tuy nhiên, do các thay đổi bảo mật gần đây từ upstream kernel, việc tích hợp KernelSU trên các kernel `x86_64` hiện đại cần thêm xử lý để unified syscall dispatcher của chúng ta hoạt động chính xác. + +## Vì sao nó bị hỏng? + +Trong các phiên bản kernel mới hơn, một [commit](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2) đã được thêm vào để tăng cường bảo vệ syscall table. Thay đổi này chuyển các nhánh gián tiếp trong đường đi của system call thành một loạt nhánh điều kiện trực tiếp. + +Cơ chế `syscall_hook` của KernelSU dựa vào việc sửa đổi các mục trong syscall table để các system call bị chặn có thể được chuyển đến unified dispatcher. Vì cơ chế hardening mới thay đổi đường đi của system call, kernel sẽ bỏ qua các thay đổi đó đối với syscall table. Nếu KernelSU cố tải và hook syscall table mà không xử lý giới hạn này đúng cách, nó sẽ không thể định tuyến lời gọi và sẽ chủ động hủy khởi tạo để tránh kernel panic. + +## Cách khắc phục? + +Hiện có hai cách được hỗ trợ để xử lý vấn đề syscall hook trên `x86_64`: + +1. Bật tùy chọn biên dịch kernel `KSU_X86_PATCH_SYSCALL_DISPATCHER`. +2. Tiếp tục dùng phương pháp vá mã nguồn kernel như trước. + +Bạn chỉ cần dùng một trong hai. Không áp dụng cả hai cùng lúc. + +### Cách 1: Bật `KSU_X86_PATCH_SYSCALL_DISPATCHER` + +KernelSU 3.2.6 đã giới thiệu cơ chế chính thức mới cho `x86_64`: tùy chọn build `KSU_X86_PATCH_SYSCALL_DISPATCHER`. + +Khi tùy chọn này được bật, KernelSU sẽ tự động vá động hardened syscall dispatcher trong lúc chạy để syscall hook hoạt động mà không cần bộ vá mã nguồn kernel cũ. Đây là cách được khuyến nghị nếu bạn đang build kernel với KernelSU 3.2.6 hoặc mới hơn. + +### Cách 2: Áp dụng bộ vá mã nguồn kernel cũ + +Nếu bạn không muốn bật `KSU_X86_PATCH_SYSCALL_DISPATCHER`, bạn vẫn có thể tiếp tục dùng cách vá kernel như trước. + +Để KernelSU hoạt động trên các kernel mới này, hãy áp dụng bản vá cho phép bỏ qua cơ chế syscall hardening cụ thể này. + +::: danger CẢNH BÁO BẢO MẬT +Khi sử dụng một trong hai giải pháp này, bạn đang chủ động bỏ qua hoặc làm suy yếu một cơ chế giảm thiểu được thiết kế để chống lại các lỗ hổng speculative execution. + +Điều này sẽ mở lại bề mặt tấn công nhánh gián tiếp cho system call. **Không sử dụng một trong hai giải pháp này nếu bạn đang chạy máy chủ production hoặc hệ thống yêu cầu bảo mật side-channel nghiêm ngặt.** Các giải pháp này chỉ dành cho môi trường thử nghiệm, nơi quyền root thông qua KernelSU được ưu tiên hơn cơ chế giảm thiểu lỗ hổng phần cứng cụ thể này. +::: + +Hãy chọn và áp dụng các bản vá phù hợp với phiên bản kernel của bạn dưới đây. Các bản vá này tạo ra một tính năng có tên `X86_FEATURE_INDIRECT_SAFE` và có thể được kích hoạt bằng tham số dòng lệnh kernel `syscall_hardening=off`. + +``` +For kernel 6.6: +https://github.com/android-generic/kernel_common/commit/fe9a9b4c320577c30e1f22d04039e414c6a3cdec +https://github.com/android-generic/kernel_common/commit/df772e99e392f24b395ceaf7b26974e3e4828ee9 + +For kernel 6.12: +https://github.com/android-generic/kernel-zenith/commit/dd2c602268fdc81f4d3b662f6a15142ac0ec7bcd +https://github.com/android-generic/kernel-zenith/commit/7d99237ae5da61c19447138da3282ae37d43857b + +For kernel 6.18: +https://github.com/android-generic/kernel-zenith/commit/40b1c323d1ad29c86e041d665c7f089b9a3ccfb5 +https://github.com/android-generic/kernel-zenith/commit/f5813e10b7630e1ccd86fc2c4cf30eef60b64a82 +``` + +## Nên chọn cách nào? + +- Nếu bạn đang dùng KernelSU 3.2.6 trở lên và có thể thay đổi cấu hình build của KernelSU, hãy bật `KSU_X86_PATCH_SYSCALL_DISPATCHER`. +- Nếu bạn muốn giữ quy trình vá kernel hiện tại, hãy tiếp tục dùng bộ vá mã nguồn ở trên. diff --git a/website/docs/zh_CN/guide/x86_64-support.md b/website/docs/zh_CN/guide/x86_64-support.md new file mode 100644 index 000000000000..f651fa3e0983 --- /dev/null +++ b/website/docs/zh_CN/guide/x86_64-support.md @@ -0,0 +1,57 @@ +# x86_64 支持 + +KernelSU 完全支持 `x86_64` 架构。但由于上游内核近期的安全改动,在较新的 `x86_64` 内核上集成 KernelSU 时,需要额外处理,才能让统一的 syscall dispatcher 正常工作。 + +## 为什么会失效? + +在较新的内核版本中,引入了一个 [提交](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2) 来加固 syscall table。这个改动把系统调用路径中的间接跳转转换成了一系列直接条件分支。 + +KernelSU 的 `syscall_hook` 机制依赖对系统调用表的修改,从而把被拦截的系统调用路由到统一 dispatcher。由于新的加固机制改变了系统调用路径,内核会忽略这些对系统调用表的修改。若 KernelSU 在没有正确处理该限制的情况下加载并 hook syscall table,将无法正确路由调用,并会主动中止初始化,以避免内核 panic。 + +## 如何修复? + +现在有两种受支持的方式来处理 `x86_64` 上的 syscall hook 问题: + +1. 启用内核编译选项 `KSU_X86_PATCH_SYSCALL_DISPATCHER`。 +2. 继续使用原有的内核源码补丁方案。 + +二选一即可,不要同时使用两种方案。 + +### 方案 1:启用 `KSU_X86_PATCH_SYSCALL_DISPATCHER` + +KernelSU 3.2.6 为 `x86_64` 新增了官方机制,即编译选项 `KSU_X86_PATCH_SYSCALL_DISPATCHER`。 + +启用后,KernelSU 会在运行时动态 patch 已加固的 syscall dispatcher,使 syscall hook 可以正常工作,而不再依赖之前那组内核源码补丁。如果你使用的是 KernelSU 3.2.6 或更新版本,并且可以调整 KernelSU 的构建配置,建议优先采用这种方式。 + +### 方案 2:应用原有的内核源码补丁 + +如果你不想启用 `KSU_X86_PATCH_SYSCALL_DISPATCHER`,也可以继续沿用原有的内核补丁方案。 + +要让 KernelSU 在这些较新的内核上工作,需要应用补丁以绕过这项 syscall 加固。 + +::: danger 安全警告 +使用这两种方案中的任意一种,都意味着你在主动绕过或削弱一项用于防御推测执行漏洞的缓解措施。 + +这会重新暴露系统调用路径中的间接分支攻击面。**如果你的环境是生产服务器,或者对侧信道安全有严格要求,请不要使用这两种方案。** 这些方案仅适用于测试环境,前提是你更重视通过 KernelSU 获得 root 能力,而不是这项特定硬件漏洞缓解。 +::: + +请根据你的内核版本选择并应用下面对应的补丁。这些补丁会创建一个名为 `X86_FEATURE_INDIRECT_SAFE` 的特性,并可通过内核命令行参数 `syscall_hardening=off` 启用。 + +``` +For kernel 6.6: +https://github.com/android-generic/kernel_common/commit/fe9a9b4c320577c30e1f22d04039e414c6a3cdec +https://github.com/android-generic/kernel_common/commit/df772e99e392f24b395ceaf7b26974e3e4828ee9 + +For kernel 6.12: +https://github.com/android-generic/kernel-zenith/commit/dd2c602268fdc81f4d3b662f6a15142ac0ec7bcd +https://github.com/android-generic/kernel-zenith/commit/7d99237ae5da61c19447138da3282ae37d43857b + +For kernel 6.18: +https://github.com/android-generic/kernel-zenith/commit/40b1c323d1ad29c86e041d665c7f089b9a3ccfb5 +https://github.com/android-generic/kernel-zenith/commit/f5813e10b7630e1ccd86fc2c4cf30eef60b64a82 +``` + +## 应该选择哪种方案? + +- 如果你使用的是 KernelSU 3.2.6 或更新版本,且可以修改 KernelSU 构建配置,建议启用 `KSU_X86_PATCH_SYSCALL_DISPATCHER`。 +- 如果你希望继续保持现有的内核补丁工作流,则继续使用上面的源码补丁方案。 diff --git a/website/docs/zh_TW/guide/x86_64-support.md b/website/docs/zh_TW/guide/x86_64-support.md new file mode 100644 index 000000000000..2cfd9135869b --- /dev/null +++ b/website/docs/zh_TW/guide/x86_64-support.md @@ -0,0 +1,57 @@ +# x86_64 支援 + +KernelSU 完全支援 `x86_64` 架構。但由於上游核心近期的安全性變更,在較新的 `x86_64` 核心上整合 KernelSU 時,需要額外處理,才能讓統一的 syscall dispatcher 正常運作。 + +## 為什麼會失效? + +在較新的核心版本中,引入了一個 [提交](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2) 來加固 syscall table。這項變更將系統呼叫路徑中的間接跳轉轉換成一系列直接條件分支。 + +KernelSU 的 `syscall_hook` 機制依賴對系統呼叫表的修改,藉此將被攔截的系統呼叫路由到統一 dispatcher。由於新的加固機制改變了系統呼叫路徑,核心會忽略這些對系統呼叫表的修改。若 KernelSU 在沒有正確處理這項限制的情況下載入並 hook syscall table,將無法正確路由呼叫,並會主動中止初始化,以避免核心 panic。 + +## 如何修復? + +現在有兩種受支援的方式可處理 `x86_64` 上的 syscall hook 問題: + +1. 啟用核心編譯選項 `KSU_X86_PATCH_SYSCALL_DISPATCHER`。 +2. 繼續使用原本的核心原始碼補丁方案。 + +二選一即可,請不要同時使用兩種方案。 + +### 方案 1:啟用 `KSU_X86_PATCH_SYSCALL_DISPATCHER` + +KernelSU 3.2.6 為 `x86_64` 新增了官方機制,也就是編譯選項 `KSU_X86_PATCH_SYSCALL_DISPATCHER`。 + +啟用後,KernelSU 會在執行時動態 patch 已加固的 syscall dispatcher,讓 syscall hook 可以正常運作,而不再依賴先前那組核心原始碼補丁。如果你使用的是 KernelSU 3.2.6 或更新版本,且可以調整 KernelSU 的建置設定,建議優先採用這種方式。 + +### 方案 2:套用原本的核心原始碼補丁 + +如果你不想啟用 `KSU_X86_PATCH_SYSCALL_DISPATCHER`,也可以繼續沿用原本的核心補丁方案。 + +要讓 KernelSU 在這些較新的核心上運作,需要套用補丁以繞過這項 syscall 加固。 + +::: danger 安全警告 +使用這兩種方案中的任一種,都代表你正在主動繞過或削弱一項用於防禦推測執行漏洞的緩解措施。 + +這會重新暴露系統呼叫路徑中的間接分支攻擊面。**如果你的環境是正式生產伺服器,或對側通道安全有嚴格要求,請不要使用這兩種方案。** 這些方案僅適用於測試環境,前提是你更重視透過 KernelSU 取得 root 能力,而不是這項特定硬體漏洞緩解。 +::: + +請根據你的核心版本選擇並套用下列對應補丁。這些補丁會建立一個名為 `X86_FEATURE_INDIRECT_SAFE` 的特性,並可透過核心命令列參數 `syscall_hardening=off` 啟用。 + +``` +For kernel 6.6: +https://github.com/android-generic/kernel_common/commit/fe9a9b4c320577c30e1f22d04039e414c6a3cdec +https://github.com/android-generic/kernel_common/commit/df772e99e392f24b395ceaf7b26974e3e4828ee9 + +For kernel 6.12: +https://github.com/android-generic/kernel-zenith/commit/dd2c602268fdc81f4d3b662f6a15142ac0ec7bcd +https://github.com/android-generic/kernel-zenith/commit/7d99237ae5da61c19447138da3282ae37d43857b + +For kernel 6.18: +https://github.com/android-generic/kernel-zenith/commit/40b1c323d1ad29c86e041d665c7f089b9a3ccfb5 +https://github.com/android-generic/kernel-zenith/commit/f5813e10b7630e1ccd86fc2c4cf30eef60b64a82 +``` + +## 應該選哪種方案? + +- 如果你使用的是 KernelSU 3.2.6 或更新版本,且可以修改 KernelSU 建置設定,建議啟用 `KSU_X86_PATCH_SYSCALL_DISPATCHER`。 +- 如果你想維持既有的核心補丁工作流程,則繼續使用上面的原始碼補丁方案。