linux-kernel - Re: [PATCH] kprobes/x86: opt: free optinsn cache when range check fails

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Aug 2014 15:49:34 +0800
From:	Wang Nan <wangnan0@...wei.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
CC:	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Andi Kleen" <ak@...ux.intel.com>,
	Pei Feiyue <peifeiyue@...wei.com>, <x86@...nel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kprobes/x86: opt: free optinsn cache when range check
 fails

On 2014/7/29 19:36, Masami Hiramatsu wrote:
> Hi Wang,
> 
> (2014/07/29 10:55), Wang Nan wrote:
>> On 2014/7/29 9:43, Masami Hiramatsu wrote:
>>> (2014/07/28 21:20), Wang Nan wrote:
>>>> This patch frees optinsn slot when range check error to prevent memory
>>>> leaks. Before this patch, cache entry in kprobe_insn_cache won't be
>>>> freed if kprobe optimizing fails due to range check failure.
>>>>
>>>> Signed-off-by: Wang Nan <wangnan0@...wei.com>
>>>
>>> Oops, thank you for finding it!
>>>
>>> Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
>>>
>>> BTW, would you really have hit this error?
>>> I'd like to know the case if this really happens.
>>
>> I'm not really hit it on x86_64. I found this problem when trying to implement kprobe opt on arm.
> 
> That's interesting :)
> 
>>
>> On arm, relative jump can only branch on/backward 64MB, which makes it a realistic problem.
> 
> Yeah, that is what I expected on RISC processor such as ARM.
> 
> Perhaps you'll need to overwrite 2 words, one is for "ldr pc, [pc, #-4]" and one is for
> the address data. In this case, you have no branch range limitation in 32bit mode. This
> requires branch destination checking for safety as x86 optprobe does.
> Plus, you'll have to use same technique of x86 to make a detour code and deferred
> optimization for overwriting multiple instructions. Put a breakpoint at the probe point,
> wait for synchronize_sched(), put the 2nd instruction(.data) and overwrite the breakpoint
> with the "ldr". :)
> 
> However, that is only for arm32.
> For ARM64, I'm not so sure about its ISA. I guess we need a scratchpad area for that..
> 
> Anyway, please CC to me when you've done the prototyping and sending RFC. I'll review
> and test it. :)
> 
> Thank you,
> 

Hi Masami,

I have posted my RFC patch on LKML and ARM mailing list, and also CC you.
Please see:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/277809.html

Please help me review my patch, Thank you!

>>
>>>
>>>> ---
>>>>  arch/x86/kernel/kprobes/opt.c | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
>>>> index f304773..f1314d0 100644
>>>> --- a/arch/x86/kernel/kprobes/opt.c
>>>> +++ b/arch/x86/kernel/kprobes/opt.c
>>>> @@ -338,8 +338,10 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe *op)
>>>>  	 * a relative jump.
>>>>  	 */
>>>>  	rel = (long)op->optinsn.insn - (long)op->kp.addr + RELATIVEJUMP_SIZE;
>>>> -	if (abs(rel) > 0x7fffffff)
>>>> +	if (abs(rel) > 0x7fffffff) {
>>>> +		__arch_remove_optimized_kprobe(op, 0);
>>>>  		return -ERANGE;
>>>> +	}
>>>>  
>>>>  	buf = (u8 *)op->optinsn.insn;
>>>>  
>>>>
>>>
>>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/