linux-parisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: Rolf Eike Beer <eike-kernel@sf-tec.de>, linux-parisc@vger.kernel.org
Subject: Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000
Date: Tue, 2 Jul 2019 17:59:22 +0200	[thread overview]
Message-ID: <029de4f5-62db-7d74-7619-3c7888ce4f9c@gmx.de> (raw)
In-Reply-To: <ea25ddf3-0e9c-534f-1dc6-41169dc3edcd@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

>> This seems to be a minimal reproducer:
>> https://481768.bugs.gentoo.org/attachment.cgi?id=361728

That's a REALLY nasty bug!
I see at least two issues here: A Linux kernel bug and a gdb (userspace) bug.

The kernel bug is, that a userspace process (running gdb) is able to crash the machine.
The attached patch does fix the crashes by preventing userspace to change IAOQ values to point to the gateway page.
This is what made the kernel crash, which probably happened, when the kernel tried to switch_to() the process.
I'm still trying to figure out if there is a better patch, e.g. in the switch_to() function or similar.
So, I don't think it's the final patch.
Anyway, this patch can help to figure out what's else going wrong.

Then, the second issue is:
In gdb this crashes the machine: "set tp = { 0,0 }".
Correct would be: "set *tp = { 0,0 }", which does NOT crash the kernel and works correctly.
So, for the first test it seems that gdb tries to create a temporary variable on the stack for "tp" in the user process.
For that gdb analyzes the code and thus somehow starts executing the attached process.
I think some gdb-expert might be able to fix this, esp. since gdb now prints:
: The program being debugged stopped while in a function called from GDB.
: Evaluation of the expression containing the function
: (malloc) will be abandoned.
: When the function is done executing, GDB will silently stop.
Maybe gdb tries to call the "malloc" function to allocate memory?

gdb uses ptrace() to control the attached process. So, adding a
  printk("PTRACE_REQUEST_PARISC  req=0x%lx  addr=0x%lx  data=0x%lx\n", request, addr, data);
to arch_ptrace() in arch/parisc/kernel/ptrace.c helps to debug what gdb does.

Helge

[-- Attachment #2: p1 --]
[-- Type: text/plain, Size: 1371 bytes --]

diff --git a/arch/parisc/kernel/ptrace.c b/arch/parisc/kernel/ptrace.c
index a3d2fb4e6dd2..1b1af8a6508f 100644
--- a/arch/parisc/kernel/ptrace.c
+++ b/arch/parisc/kernel/ptrace.c
@@ -167,6 +175,14 @@ long arch_ptrace(struct task_struct *child, long request,
 		if ((addr & (sizeof(unsigned long)-1)) ||
 		     addr >= sizeof(struct pt_regs))
 			break;
+		/* Do not allow userspace to set IAOQ to gateway page. */
+		if (addr == PT_IAOQ0 || addr == PT_IAOQ1) {
+			if (data < GATEWAY_PAGE_SIZE) {
+				ret = 0; // return sucess to not disturb gdb
+				// printk("UGH!!!!!!!!!!!!!!!!!!!!\n");
+				break;
+			}
+		}
 		if ((addr >= PT_GR1 && addr <= PT_GR31) ||
 				addr == PT_IAOQ0 || addr == PT_IAOQ1 ||
 				(addr >= PT_FR0 && addr <= PT_FR31 + 4) ||
@@ -281,6 +297,14 @@ long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
 			addr = translate_usr_offset(addr);
 			if (addr >= sizeof(struct pt_regs))
 				break;
+			/* Do not allow userspace to set IAOQ to gateway page. */
+			if (addr == PT_IAOQ0 || addr == PT_IAOQ1) {
+				if (data < GATEWAY_PAGE_SIZE) {
+					ret = 0; // return sucess to not disturb gdb
+					// printk("UGH!!!!!!!!!!!!!!!!!!!!\n");
+					break;
+				}
+			}
 			if (addr >= PT_FR0 && addr <= PT_FR31 + 4) {
 				/* Special case, fp regs are 64 bits anyway */
 				*(__u64 *) ((char *) task_regs(child) + addr) = data;

  reply	other threads:[~2019-07-02 15:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-25  8:59 Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000 Rolf Eike Beer
2018-01-25 13:01 ` John David Anglin
2018-01-25 15:36   ` Rolf Eike Beer
2018-01-26 22:31     ` Helge Deller
2018-01-27 17:42       ` Rolf Eike Beer
2018-01-27 18:41         ` Helge Deller
2018-01-28 19:01           ` John David Anglin
2019-06-30 10:05 ` Rolf Eike Beer
2019-06-30 13:43   ` Rolf Eike Beer
2019-06-30 19:59     ` Helge Deller
2019-07-02 15:59       ` Helge Deller [this message]
2019-07-16 20:01         ` Helge Deller
2019-07-17 17:52           ` Rolf Eike Beer
2019-07-17 18:13             ` John David Anglin
2019-07-17 21:00             ` Helge Deller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=029de4f5-62db-7d74-7619-3c7888ce4f9c@gmx.de \
    --to=deller@gmx.de \
    --cc=eike-kernel@sf-tec.de \
    --cc=linux-parisc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).