linux-kernel - [RFC v5 - RESEND] debug: prevent entering debug mode on panic/exception.

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: <1422441574-24005-1-git-send-email-kiran.kumar@linaro.org>
Date:	Wed, 28 Jan 2015 16:09:34 +0530
From:	Kiran Raparthy <kiran.kumar@...aro.org>
To:	linux-kernel@...r.kernel.org
Cc:	Colin Cross <ccross@...roid.com>,
	Jason Wessel <jason.wessel@...driver.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	kgdb-bugreport@...ts.sourceforge.net,
	Android Kernel Team <kernel-team@...roid.com>,
	John Stultz <john.stultz@...aro.org>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	Kiran Raparthy <kiran.kumar@...aro.org>
Subject: [RFC v5 - RESEND] debug: prevent entering debug mode on panic/exception.

From: Colin Cross <ccross@...roid.com>

debug: prevent entering debug mode on panic/exception.

On non-developer devices, kgdb prevents the device from rebooting
after a panic.

Incase of panics and exceptions, to allow the device to reboot, prevent entering
debug mode to avoid getting stuck waiting for the user to interact with debugger.

To avoid entering the debugger on panic/exception without any extra configuration,
panic_timeout is being used which can be set via /proc/sys/kernel/panic at run time
and CONFIG_PANIC_TIMEOUT sets the default value.

Setting panic_timeout indicates that the user requested machine to perform
unattended reboot after panic. We dont want to get stuck waiting for the user
input incase of panic.

Cc: Jason Wessel <jason.wessel@...driver.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: kgdb-bugreport@...ts.sourceforge.net
Cc: linux-kernel@...r.kernel.org
Cc: Android Kernel Team <kernel-team@...roid.com>
Cc: John Stultz <john.stultz@...aro.org>
Cc: Sumit Semwal <sumit.semwal@...aro.org>
Signed-off-by: Colin Cross <ccross@...roid.com>
[Kiran: Added context to commit message.
panic_timeout is used instead of break_on_panic and
break_on_exception to honor CONFIG_PANIC_TIMEOUT
Modified the commit as per community feedback]
Signed-off-by: Kiran Raparthy <kiran.kumar@...aro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@...aro.org>
---
 kernel/debug/debug_core.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 1adf62b..0012a1f 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -689,6 +689,14 @@ kgdb_handle_exception(int evector, int signo, int ecode, struct pt_regs *regs)
 
 	if (arch_kgdb_ops.enable_nmi)
 		arch_kgdb_ops.enable_nmi(0);
+	/*
+	 * Avoid entering the debugger if we were triggered due to an oops
+	 * but panic_timeout indicates the system should automatically
+	 * reboot on panic. We don't want to get stuck waiting for input
+	 * on such systems, especially if its "just" an oops.
+	 */
+	if (signo != SIGTRAP && panic_timeout)
+		return 1;
 
 	memset(ks, 0, sizeof(struct kgdb_state));
 	ks->cpu			= raw_smp_processor_id();
@@ -821,6 +829,15 @@ static int kgdb_panic_event(struct notifier_block *self,
 			    unsigned long val,
 			    void *data)
 {
+	/*
+	 * Avoid entering the debugger if we were triggered due to a panic
+	 * We don't want to get stuck waiting for input from user in such case.
+	 * panic_timeout indicates the system should automatically
+	 * reboot on panic.
+	 */
+	if (panic_timeout)
+		return NOTIFY_DONE;
+
 	if (dbg_kdb_mode)
 		kdb_printf("PANIC: %s\n", (char *)data);
 	kgdb_breakpoint();
-- 
1.8.2.1

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