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>] [day] [month] [year] [list]
Message-ID: <87d3b2040909020322i40c09445t4555ffe5cb5b3e13@mail.gmail.com>
Date:	Wed, 2 Sep 2009 12:22:14 +0200
From:	Frederic Riss <frederic.riss@...il.com>
To:	nico@....org, sagar.abhishek@...il.com
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Is ARM kprobes unregistration SMP safe?

[Sorry if you get that mail twice. Made a silly email typo in the
first version.]

Hi,

ARM kprobes are using an illegal instruction to trigger the kprobe
code. the trap handler looks like that:

asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
{
       unsigned int instr;

       pc = (void __user *)instruction_pointer(regs);

       instr = *(u32 *) pc;

       /*
        * It is possible to have recursive kprobes, so we can't call
        * the kprobe trap handler with the undef_lock held.
        */
       if (instr == KPROBE_BREAKPOINT_INSTRUCTION && !user_mode(regs)) {
               kprobe_trap_handler(regs, instr);
               return;
       }
       [...]
}

And in arch/arm/kernel/kprobes.c we have:

void __kprobes arch_disarm_kprobe(struct kprobe *p)
{
       *p->addr = p->opcode;
       flush_insns(p->addr, 1);
}

In an SMP system, I don't see what prevents a core to take the
undefined instruction exception while the other core is unregistering the
corresponding kprobe. With the right timing, at the time the exception
handler reads the patched instruction, it can have been 'unpatched' by
arch_disarm_kprobe, and thus fail the KPROBE_BREAKPOINT_INSTRUCTION
test. Shouldn't arch_disarm_kprobe use stop_machine or something like
that?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ