Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1629102pxb; Thu, 4 Mar 2021 16:55:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJy3yixxPpv9b3QSvbQz2L+IQ39aMGKgvb3dZeqZLTY7fEsWfdudAn6HDhVcIvgPLDe2a+a9 X-Received: by 2002:a05:6e02:1545:: with SMTP id j5mr6235512ilu.296.1614905741580; Thu, 04 Mar 2021 16:55:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614905741; cv=none; d=google.com; s=arc-20160816; b=ZgAljZrBa/RBIx1RqqmdoZ4bjzqgEuOsLDGk+AjmogcylL4RU7gGt/8BPhuu54eGSo WreA6GLvE9aEnrXsrJ47ezNyG/4gLodvoMuYpFhWw5UyxgCxGJqiVKxoGT5Mse2VCm7z Ymi7POtw0fhXbjuA8ZLFEOmeJ5pEyXh/ZFPHUbXvkYjVV4lZRE8zzy+5Nh5zXAe78cnT jeT/LzdYg6w5CjpRSfA3x3mk/Xe8jk+qhNrH+f7mDjXNLr+z9GLd8P1pKgxm+rYFJbqd NKHN1wxk5scGHoG9vURXfj2E802awTYyRaENwqQi0M/UfT3JgvhST/XWSxteJAylp8yC mLpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=tYl3O7ejSMpbvfxDcYOriJ9YGWWej97/f6WWs/Xr3OY=; b=D3+ZMaGRtLwcDKV1ORIW/YHkC9MQGBF3oAqi7K/GZNbRzPhz/wrbVHeK1VMkh3egBi hTwbbL2yPQ0qSUEmlgjMsBiKcXKQ0ilacxGxJAUARAfjvT+UxAPybKR9V4AZJ6qOevVB hjaDlGQ7v1ufZrD87g9fISvmtY5X0WmuDAiwL3NH1meg52TyxGeQv4AcS0KsGtEpap2S L7A8mVEnV5+3w5StqcXnT6IwjyhwZ1nN48a7yJzfCW5mZnVw1C3z85RGGanEcpo3e7Z9 oTLED5Hq7tBhtZFGM4aQ52qvhqX4aQhxgYJ4YRr1xby/VIhUlikQKkN1fhvbiDa4dOYf 6nLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BIxMAUc3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b12si1019130jav.20.2021.03.04.16.55.28; Thu, 04 Mar 2021 16:55:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BIxMAUc3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237505AbhCDTHJ (ORCPT + 99 others); Thu, 4 Mar 2021 14:07:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:38940 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236420AbhCDTGv (ORCPT ); Thu, 4 Mar 2021 14:06:51 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id B9F6B64F72; Thu, 4 Mar 2021 19:06:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614884770; bh=vqA9dPEA/Pj4CLPwidd/pKhz1PePmiTsy7RdjkNEADU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BIxMAUc3O0JyXVktHVhxRWwJbj3YU2UmNLhJE/rV0Hn03oMbbLx984rpZSihHyC+b pKtd+/g4J8+ts3O9xO0DPuYx6N0xSQ7SktBvqdf6DjwlQ1E4EvnmliajIVtjMdNlWg g3YFEoEOWN6QGVYBzuxsiCn6YBZkgq6mZrhxtS7nA98+8dqK7m9dhaxL1issGR6CI3 0oJ+PAdOkfHu+9eJmeOPw7xPzrkEPGLc73gkijKLTHHst8BbVvcpnxb5Xf5RMILzqt Nb7PpNr5Xi+ALMeDFaPCdpht/sXh6TxZQmcitgQkRQSrevbeDPDuz4UVU+flw6DWhz qjOp2xRtbz7qg== From: Andy Lutomirski To: x86@kernel.org Cc: LKML , Mark Rutland , Andy Lutomirski , Josh Poimboeuf Subject: [PATCH v3 04/11] x86/kthread,dumpstack: Set task_pt_regs->cs.RPL=3 for kernel threads Date: Thu, 4 Mar 2021 11:05:57 -0800 Message-Id: X-Mailer: git-send-email 2.29.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For kernel threads, task_pt_regs is currently all zeros, a valid user state (if kernel_execve() has been called), or some combination thereof during execution of kernel_execve(). If a stack trace is printed, the unwinder might get confused and treat task_pt_regs as a kernel state. Indeed, forcing a stack dump results in an attempt to display _kernel_ code bytes from a bogus address at the very top of kernel memory. Fix the confusion by setting cs=3 so that user_mode(task_pt_regs(...)) == true for kernel threads. Also improve the error when failing to fetch code bytes to show which type of fetch failed. This makes it much easier to understand what's happening. Cc: Josh Poimboeuf Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 4 ++-- arch/x86/kernel/process.c | 13 +++++++++++++ 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c index 55cf3c8325c6..9b7b69bb12e5 100644 --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -128,8 +128,8 @@ void show_opcodes(struct pt_regs *regs, const char *loglvl) /* No access to the user space stack of other tasks. Ignore. */ break; default: - printk("%sCode: Unable to access opcode bytes at RIP 0x%lx.\n", - loglvl, prologue); + printk("%sCode: Unable to access %s opcode bytes at RIP 0x%lx.\n", + loglvl, user_mode(regs) ? "user" : "kernel", prologue); break; } } diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 145a7ac0c19a..f6f16df04cb9 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -163,6 +163,19 @@ int copy_thread(unsigned long clone_flags, unsigned long sp, unsigned long arg, /* Kernel thread ? */ if (unlikely(p->flags & PF_KTHREAD)) { memset(childregs, 0, sizeof(struct pt_regs)); + + /* + * Even though there is no real user state here, these + * are were user regs belong, and kernel_execve() will + * overwrite them with user regs. Put an obviously + * invalid value that nonetheless causes user_mode(regs) + * to return true in CS. + * + * This also prevents the unwinder from thinking that there + * is invalid kernel state at the top of the stack. + */ + childregs->cs = 3; + kthread_frame_init(frame, sp, arg); return 0; } -- 2.29.2