linux-kernel - Re: Query: ARM64: Behavior of el1_dbg exception while executing el0

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-next>] [day] [month] [year] [list]

Message-ID: <54B00C39.1070809@redhat.com>
Date:	Fri, 09 Jan 2015 22:43:29 +0530
From:	Pratyush Anand <panand@...hat.com>
To:	Will Deacon <will.deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	William Cohen <wcohen@...hat.com>,
	Steve Capper <steve.capper@...aro.org>,
	David Long <dave.long@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Query: ARM64: Behavior of el1_dbg exception while executing el0_dbg



On Friday 09 January 2015 09:16 PM, Will Deacon wrote:
> On Thu, Jan 08, 2015 at 05:28:37PM +0000, Pratyush Anand wrote:
>> On Thursday 08 January 2015 09:53 PM, Will Deacon wrote:
>>> On Thu, Jan 08, 2015 at 01:15:58PM +0000, Pratyush Anand wrote:
>>>> I am trying to test following scenario, which seems valid to me. But I
>>>> am very new to ARM64 as well as to debugging tools, so seeking expert's
>>>> comment here.
>>>>
>>>> -- I have inserted a kprobe to the function uprobe_breakpoint_handler
>>>> which is called from elo_dbg
>>>> (el0_dbg->do_debug_exception->brk_handler->call_break_hook->uprobe_breakpoint_handler)
>>>>
>>>> -- kprobe is enabled.
>>>>
>>>> -- an uprobe is inserted into a test application and enabled.
>>>>
>>>> So, when uprobe is enabled and test code execution reaches to probe
>>>> instruction, it executes uprobe breakpoint instruction and el0_dbg
>>>> exception is raised.
>>>>
>>>> When control reaches to start of uprobe_breakpoint_handler and it
>>>> executes first instruction (which has been replaced with a kprobe
>>>> breakpoint instruction), el1_dbg exception is raised.
>>>
>>> Hmm, debug exceptions should be masked at this point so I don't see why
>>> you're taking the second debug exception.
>>>
>>
>> So, you mean to say that when an exception which has been taken from
>> lower exception level (EL0) is being executed, then we keep masked also
>> the exception from current exception level (EL1)...
>
> Yeah, if you look at entry.S then you'll see that neither el0_dbg or el1_dbg
> re-enable debug exceptions (masked automatically by the CPU after taking the
> exception) until *after* the handling has completed. This is to prevent
> recursive debug exceptions, which I don't see how we can reasonable handle.

May be I am missing something, but my observation on silicon is 
different. Please have a look at git log of HEAD of following branch, 
which says that el1_dbg exception has been raised while el0_dbg was 
executing. Do not know what I am missing..

https://github.com/pratyushanand/linux/tree/ml_arm64_uprobe_devel_debug_kprobe_insertion_at_uprobe_breakpoint_handler



>
>> If, so then how to handle it. One way is that I assign a __kprobe
>> qualifier to uprobe_breakpoint_handler and uprobe_single_step_handler,
>> so that an user can not insert a kprobe there. But, that does not seem
>> to be a good idea, because it will only prevent these two functions to
>> be probed. What about the functions which is being called by these
>> functions like uprobe_pre_sstep_notifier & uprobe_post_sstep_notifier
>> which lie in generic kernel code. So, may be we need something in
>> debug-monitor, which handles this situation, no?
>
> I'm not sure how to solve it, but we certainly can't allow debug exceptions
> to trigger on the debug exception handling path. The first thing to do would
> be finding out where they are getting re-enabled.

As of now I will put uprobe_breakpoint_handler and 
uprobe_single_step_handler symbols under NOKPROBE_SYMBOL.

Other than these, we should also put functions like brk_handler, 
do_dbg_exception (all those which comes in debug exception handling 
path) under NOKPROBE_SYMBOL, as they have been done in 
arch/x86/kernel/traps.c

In my opinion uprobe_pre_sstep_notifier and uprobe_post_sstep_notifier 
should also be put under NOKPROBE_SYMBOL. Adding linux-kernel to comment.

~Pratyush
>
> Will
>
--
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/