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

Message-ID: <ce2c83091001120309q19d58b45kc27610fc31ce01dc@mail.gmail.com>
Date:	Tue, 12 Jan 2010 19:09:35 +0800
From:	Dongdong Deng <libfetion@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	ananth@...ibm.com, anil.s.keshavamurthy@...el.com,
	davem@...emloft.net, mhiramat@...hat.com, arjan@...radead.org,
	jkenisto@...ibm.com
Subject: Did we really need to clear the IF flag at prepare_singlestep() of 
	x86 kprobes?

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.




******************

Combining those reasons: maybe we could remove "regs->flags &= ~X86_EFLAGS_IF;".

(It just a example about X86_EFLAGS_IF and kprobe here.)
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 5b8c750..dfd719a 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -407,7 +407,6 @@ static void __kprobes prepare_singlestep(struct
kprobe *p, struct pt_regs *regs)
{
       clear_btf();
       regs->flags |= X86_EFLAGS_TF;
-       regs->flags &= ~X86_EFLAGS_IF;
       /* single step inline if the instruction is an int3 */
       if (p->opcode == BREAKPOINT_INSTRUCTION)
               regs->ip = (unsigned long)p->addr;



What do you think about it?

I know I must be make a mistake here, could you correct me?


Thanks,
Dongdong.
--
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/