linux-kernel - Ftrace code in the 2.6.29 kernel

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: <20090402045104.GA21896@Krystal>
Date:	Thu, 2 Apr 2009 00:51:04 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	ltt-dev@...ts.casi.polymtl.ca
Subject: Ftrace code in the 2.6.29 kernel

Hi Steven,

I am giving a look at the ftrace code, and I am a bit confused by the
way you handle reentrancy in ring_buffer.c. (this is the code in 2.6.29)
Please tell me if I missed important details :

1) you seem to have removed any sort of "nesting" check to allow NMI
handlers to run. Previously, I remember that you simply discarded the
event if a NMI handler appeared to run over the ring buffer code.

2) Assuming 1) is true, then __rb_reserve_next() called from
ring_buffer_lock_reserve() is protected by :

               local_irq_save(flags);
                __raw_spin_lock(&cpu_buffer->lock);

Which I think is the last thing you want to see in a NMI handler. It
sounds like this code is begging for a deadlock to occur if run in NMI
context. Or maybe you don't claim that this code supports NMI, but then
you should remove the following comment from ring_buffer.c :

rb_set_commit_to_write(struct ring_buffer_per_cpu *cpu_buffer)
{
        /*
         * We only race with interrupts and NMIs on this CPU.

So basically, if an NMI nests over that code, or if an instrumented
fault happens within the ring_buffer code, this would generate an
infinite recursive call chain of trap/tracing/trap/tracing...

So this is why I think I might have missed a sanity check somewhere.

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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/