linux-kernel - Re: Did we really need to clear the IF flag at prepare

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]

Message-ID: <4B4D65B1.3010204@redhat.com>
Date:	Wed, 13 Jan 2010 01:18:25 -0500
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Dongdong Deng <libfetion@...il.com>
CC:	linux-kernel@...r.kernel.org, ananth@...ibm.com,
	anil.s.keshavamurthy@...el.com, davem@...emloft.net,
	arjan@...radead.org, jkenisto@...ibm.com
Subject: Re: Did we really need to clear the IF flag at prepare_singlestep()
 of 	x86 kprobes?

Dongdong Deng wrote:
> Hi Kprobe experts,
> 
> I have a doubt about the handling "X86_EFLAGS_IF" at prepare_singlestep(),
> Could you give me some suggestions?
> 
> 
> arch/x86/kernel/kprobes.c:
> 406 static void __kprobes prepare_singlestep(struct kprobe *p, struct
> pt_regs *regs)
> 407 {
> 408    clear_btf();
> 409    regs->flags |= X86_EFLAGS_TF;
> 410    regs->flags &= ~X86_EFLAGS_IF;
>   ...
> }
> 
> 
> for 410 line: Kprobe is intend to disable interrupt during the single step.
> 
> I think it is enough that just setting X86_EFLAGS_TF as following reasons.
> 
> 
> ******************
> Reason 1: "debug trap" was initalized as an interrupt gate
> 
> arch/x86/kernel/traps.c:892: set_intr_gate_ist(1, &debug, DEBUG_STACK);
> 
> The "debug trap" was initalized as an interrupt gate, thereby during the
> hanld function of debug exceptions, the X86_EFLAGS_IF have been
> cleared automatically.
> 
> 
> ******************
> Reason 2: the priority among debug exceptions and interrupts
> 
> Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume
> 3A, page 5-11:
> 
> If more than one exception or interrupt is pending at an instruction
> boundary, the
> processor services them in a predictable order. Table 5-2 shows the
> priority among
> classes of exception and interrupt sources.
>           Table 5-2. Priority Among Simultaneous Exceptions and Interrupts
> Priority       Description
> 1 (Highest)    Hardware Reset and Machine Checks
>                - RESET
>                - Machine Check
> 2              Trap on Task Switch
>                - T flag in TSS is set
> 3              External Hardware Interventions
>                - FLUSH
>                - STOPCLK
>                - SMI
>                - INIT
> 4              Traps on the Previous Instruction
>                - Breakpoints
>                - Debug Trap Exceptions (TF flag set or data/I-O breakpoint)
> 5             Nonmaskable Interrupts (NMI)
> 6             Maskable Hardware Interrupts
> 
> 
> From the table we could see debug exceptions lies in priority 4 and
> external interrupt lies
> in priority 6.
> 
> Thereby the processor will handle Debug Trap Exceptions first, then
> handle external interrupt.

Hi Dongdong,

Hmm, can that be applied on other x86 compat cpus too?
And, when is the debug trap exception actually happened?

1: int3 ->
2:  -> pre_kprobe_handler
3:  -> prepare_singlestep
4: <- iret
5: execute instruction
6: debug trap ->
7: -> post_kprobe_handler
...

If we have an interrupt before step4, does that interrupt
really executed *after* step5? or step4?

If the processor really tries to execute interrupt
right after step5, your logic seems correct, but if it
is done right after step4, clearing IF seems correct.

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@...hat.com

--
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/