Comments (5)
Here is the new activeness safety check design that I'm thinking about:
- kpatch_register doesn't use stop_machine any more, and just calls kpatch_apply directly.
- kpatch_apply_patch protects the activeness safety check and updates to the function list with a
write_lock_irqsave(&kpatch_lock)
. - The ftrace handler's reading of the function list will be protected with a
read_lock(&kpatch_lock)
. This means that even if the trace handler is called during the activeness safety check, it will wait for the check to complete and will not cause it to fail. - The activeness safety check includes:
- For tasks not currently running on a CPU, check their backtraces
- For a task currently running on a CPU, run the backtrace check for that task with
stop_one_cpu_nowait()
on that CPU, so that the task is removed from the CPU before the backtrace check. - The tricky part here is ensuring that the entirety of each backtrace check occurs while the task is not running, otherwise we could get a corrupt stack or a false positive. This may need some coordination with the scheduler (or using something like
task_rq_lock()
, which is currently only an internal scheduler function).
The for_each_thread loop doesn't have to be atomic, because any future entries into kpatched functions will be paused by the read lock.
If the write lock is taken, and an NMI happens on a CPU other than the writer, and the NMI handler tries to call a kpatched function, it will spin on the kpatch_lock until the writer releases the lock.
If an NMI happens on the CPU with the writer (i.e. NMI interrupts the activeness safety and func list update), and the NMI handler tries to call a kpatched function, we will have to detect that scenario (in NMI and read_trylock fails) and panic.
The goal of this new design is to avoid using stop_machine if at all possible.
from kpatch.
@jpoimboe Hmm, why would you like to avoid using stop_machine and use lock? I don't think it's a good idea to dance with schedulers.
Instead, here I have another option to support NMI with stop_machine. This will involves CAS(compare and swap) but no lock.
- prepare an atomic conflict_counter. And add an updating flag in kpatch_func.
- when registering the patch, updating flag on each new kpatch_func set true.
- right before stop_machine, clear the conflict_counter.(Actually, a trick is here, run a stop_machine ensures all running interrupt(including NMI) handlers exit until stop_machine callback runs)
- in the stop_machine, after checked activeness and copied new kpatch_func list, do atomic CAS on conflict_counter to set 2 if it is 0.
- if the CAS failed and conflict_counter should be 1, there may be at least one concurrently running NMI handler hits the new kpatch_func, this patch should be failed. Rollback and return -EBUSY
- if the CAS succeeded, clear updating flag of all new kpatch_func and return 0.
On the other hand, the kpatch_ftrace_handler() does;
- search kpatch_func by ip address
- if failed to find kpatch_func, and if in_nmi() is true, goto step 5.
- if we hits an updating kpatch_func and conflict_counter is not 2, goto step 5.
- modify regs->ip and return
- do atomic CAS on conflict_counter to set 1 if it is 0.
- if the CAS is succeeded or the conflict_counter is 1, return without modifying regs->ip
- if the CAS is failed and the conflict_counter is 2, go back to step 1 to retry
With this method, you can avoid using locks and no need to PANIC on patching too. :)
from kpatch.
Oops, I missed push the close button... sorry.
from kpatch.
I want to avoid using stop_machine, if possible, because it can introduce a lot of latency into the system, especially for systems with many CPUs. Also I've heard rumors that stop_machine is planned to be removed from the kernel someday.
However, I agree that my non-stop_machine design has problems: it relies on locking the scheduler, it creates a small possibility of panic on NMI, and it requires modifications to the kernel.
For now, I think your proposal is the way to go. I can work on implementing it, but I'll be at the Collaboration Summit next week, so it might be a few weeks. So feel free to submit a pull request ;-)
If we get a lot of complaints about latencies, or if stop_machine gets removed from the kernel, we'll have to revisit this issue someday.
from kpatch.
Fixed with #108.
from kpatch.
Related Issues (20)
- Do we need more robust archeticture protection HOT 4
- kpatch-build: verify_patch_files might miss a parameter HOT 2
- ERROR in find_local_syms, couldn't find matching XXX local symbols in vmlinux symbol table HOT 14
- Can you add support for Rocky and Alma? HOT 1
- relocation with type R_X86_64_GOTPCREL is not supported HOT 5
- Arch Compile kpatch-git test failed HOT 4
- Regarding "statically allocated data" again HOT 2
- kpatch-build error when modifying an object file's only syscall
- nowhere to find the definition of klp_register_patch HOT 5
- x86 paravirt code uses alternatives v6.8+ HOT 1
- special-static.patch can fail to build on s390x / upstream v6.8 HOT 6
- CONFIG_FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY not supported on ppc64le HOT 6
- function __pfx_new_sync_read has no fentry/mcount call, unable to patch HOT 6
- Unchanged and unpatchable function moves from .text to .text.unlikely HOT 5
- Why did the kpatch-build script export the KPATCH-BUILD environment variable from the BUILD directory to the SOURCE directory? HOT 3
- CONFIG_WERROR=y and CONFIG_LD_ORPHAN_WARN_LEVEL="error" break kpatch-build HOT 2
- linux 6.9.0-rc6 can't find special struct paravirt_patch_site size HOT 6
- fair.o: changed section .data..read_mostly not selected for inclusion HOT 9
- find_local_syms: 218: couldn't find matching cm.c local symbols in ib_mad symbol table HOT 5
- Kernel Warning: Unpatched return thunk in use. This should not happen! HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kpatch.