Messages in this thread | | | Date | Mon, 5 Sep 2022 17:09:16 +0200 | From | Peter Zijlstra <> | Subject | Re: CONFIG_RETHUNK int3 filling prevents kprobes in function body |
| |
On Sun, Sep 04, 2022 at 11:07:13PM +0900, Masami Hiramatsu wrote: > Hi Peter, > > I found that the CONFIG_RETHUNK code (path_return) fills the unused bytes > with int3 for padding. Unfortunately, this prevents kprobes on the function > body after the return code (e.g. branch blocks placed behind the return.)
Prior to that CONFIG_SLS would already use "ret; int3"
> This is because kprobes decodes function body to ensure the probed address > is an instruction boundary, and if it finds the 0xcc (int3), it stops > decoding and reject probing because the int3 is usually used for a > software breakpoint and is replacing some other instruction. Without > recovering the instruction, it can not continue decoding safely.
I can't follow this logic. Decoding the single byte int3 instruction is trivial. If you want a sanity check, follow the branches you found while decoding the instruction starting at +0.
> Can we use another instruction for padding instead of INT3? (e.g. NOP or UD2)
No. NOP is not a trap instruction and UD2 is longer than it needs to be.
| |