linux-kernel - [PATCH 0/2] ftrace: handle NMIs safely

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]

Date:	Thu, 30 Oct 2008 16:08:31 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	linux-kernel@...r.kernel.org
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [PATCH 0/2] ftrace: handle NMIs safely

The robustness of ftrace has been the focus of the code modification in
2.6.28. There is one remaining issue that needed to be addressed.
This was the case of NMIs.

To state the problem: if a process on one CPU is modifying code that is
being executed on another CPU, that CPU will have undefined results,
and possibly issue a GPF.  To cover this with dynamic ftrace, it calls
kstop_machine to prevent the other CPUs from issuing interrupts or
executing any other process. The problem we have is that this does not
protect us against NMIs.

Discussing this with Arjan and Ingo, we came up with this RCU like solution.
When the patcher wants to modify code, it must do the following steps:

1) load the instruction pointer to modify into an IP buffer and the
   contents that will be modified into a "code" buffer.
2) set a write_bit flag.
3) wait for any running NMIs to finish.
4) modify the code.
5) clear the write bit flag.
6) wait for any running NMIs to finish
7) return the status of the write.

In the NMI handler, the first thing it will do is to check if the
write_bit is set, and if so, the NMI performs the write.
We do not worry about multiple writers writing to the code at the
same time, they are all writing the same thing.

The idea is that executing code will not have a problem if another
CPU has a process writing to that code with the same value as
what is in the code. In-other-words, the code does not change.

To help verify this, I wrote this module and let it run for a while:

-----------------------------------------------
#include <linux/module.h>
#include <linux/kthread.h>

#define WRITE_SIZE 50

static int write_thread(void *arg)
{
	unsigned char *ptr = (unsigned char *)schedule;
	static unsigned char write_buf[WRITE_SIZE];

	memcpy(write_buf, ptr, WRITE_SIZE);

	while (!kthread_should_stop()) {
		memcpy(ptr, write_buf, WRITE_SIZE);
		msleep(1);
	}

	return 0;
}

static struct task_struct *writer;

static int __init writer_torture_init(void)
{
	int ret;

	writer = kthread_run(write_thread, NULL, "write_tortured");
	ret = PTR_ERR(writer);

	if (IS_ERR(writer)) {
		writer = NULL;
		return ret;
	}

	return 0;
}

static void writer_torture_exit(void)
{
	if (writer)
		kthread_stop(writer);
}

module_init(writer_torture_init);
module_exit(writer_torture_exit);

MODULE_AUTHOR("Steven Rostedt");
MODULE_DESCRIPTION("Write code torture");
MODULE_LICENSE("GPL");
-----------------------------------------------

Do not run the dynamic ftrace while running this module ;-)

The second patch adds stats to the dyn_ftrace_total_info that adds
 NR-times-nmi-detect NR-times-NMI-wrote

-- Steve

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