From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E6A6C3DA64 for ; Tue, 6 Aug 2024 04:36:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B492E6B0085; Tue, 6 Aug 2024 00:36:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF9136B0089; Tue, 6 Aug 2024 00:36:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C1026B008C; Tue, 6 Aug 2024 00:36:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7E2F96B0085 for ; Tue, 6 Aug 2024 00:36:46 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E2E341C3A51 for ; Tue, 6 Aug 2024 04:36:45 +0000 (UTC) X-FDA: 82420559970.11.D2EB370 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id 446CD1A0008 for ; Tue, 6 Aug 2024 04:36:44 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DBsLc8CW; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722918934; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bW1EtPhRAP4UCEW4YaGrn1r4s42wVj0u9tA4fYkhxR0=; b=ucvbDcwR6Rdbqml2XV10BSFkkI+cFqpvEzi1uetf/esTeqEe/QLIA8ICrDfQidUEZQmmK6 3kwcU7lrq73RIRQ9cd5o482Xv0UxIP8PIhnTe3jzWm21SvZfaemhZJUrXJlIfU7eHG4kMP 3iO0JkgWNrajnWVNJm0/JiDJRzZK2/Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722918934; a=rsa-sha256; cv=none; b=yqq5igUA33U0Iu++Uy8g1mKAYGsmgJl4410ZY/vhL/aXsByjnhA4DF+jTa3eO5KblnZ1RE jcY6SSQR0wH4gf6occlUunoav+W5a/LY2R091lK4Uzv7SyvQFjouAPPClMmV2Ny9qV+9Px Jb8oQNyz3tJ9lQunFCuLMkwHqimU3F0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DBsLc8CW; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CDA3360ECF; Tue, 6 Aug 2024 04:36:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 731C8C32786; Tue, 6 Aug 2024 04:36:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722919001; bh=AEC6gY1lKo7lrNwi6/dkJ8cvTL6jOqvIPqyEVQQrDUU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DBsLc8CW+m0tUz3OdSq3ElblJGpvKJpg0Y976MuXFKdowsVtsZ0w9qRFiKTxHtcbf XphFuYdd9VE5Svtg8qoWs9rq4AeVQ0W44dRNY4DrqgMol6icHhqGCbiL4o6C/8mQ3+ vcR2wj+laUp8DSotFyIGZ91cN4eq2PRgUR7uEEAYuQClFdFZu856IXhZh9Kvq9GrU7 BO1HBg+kRQnDihUO+cB7GTvQI0HQ/x5RfOYdEsWCZcVUmsdWbHubx03iITJcE5Xmz2 Vj7XqHrhdAPlsEwok/X6aGuNdtxwlXn1CuoctK8P+1x6m4kBcHmgaMWMb2VCx+ihu9 xX0HPxoh+w60A== Date: Mon, 5 Aug 2024 21:36:40 -0700 From: Kees Cook To: Andrew Zaborowski Cc: linux-edac@vger.kernel.org, linux-mm@kvack.org, Tony Luck , Eric Biederman , Borislav Petkov , x86@kernel.org Subject: Re: [RESEND][PATCH 1/3] x86: Add task_struct flag to force SIGBUS on MCE Message-ID: <202408052135.342F9455@keescook> References: <20240723144752.1478226-1-andrew.zaborowski@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240723144752.1478226-1-andrew.zaborowski@intel.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 446CD1A0008 X-Stat-Signature: 163xq6fki37ck4xwytxjo8haj1k4oybe X-Rspam-User: X-HE-Tag: 1722919004-229314 X-HE-Meta: U2FsdGVkX18oRTOlduphtCyNTwQqFqN6NB8kytUj68U/SGadKmKZyPmX8DEf01l7TT9oa/gpti1WeNVEgSdF0GR/ufNJc/trsRIoLrJ1le/1Ca2g9c4PD69l/M1d0QddS343L3wnwiI7bAwSCTwIvxPHXzHkIFGhd4DN6Uli/36zKJpXkCz3/5WYTM0/+R09e/PDnxwumYwhpUjxNMkOFnQ83kxoF5nx+vzYqZkNOND36l15gZ45eI+rSYo8f4oXgCjUoYO/efdbdqH9cCZv0SuCkKY66lYB/ZdhVjVsDDIodCNClqcqmknsD+D9Hcj+max8wdULQ15CCpKI78kVm9wDvJ3Jg6ZjiMJELyH442V2WHn3vumsxGr7W6INTzGU5SicZ2Ri4DovlDD4ycqK1SJJtDwGpm6qlKseS2WY4mg//aKDt5/dE9cA00KIFzrhCPN15W/b7bOgXhYaISjUlO6QMIDVa5Chv1QOKDvP7cGRoSAskJPkAgps6WjFqnNw0Z0lEdpThHgt3q6X+eTMX93ZJ9xTO9OA3BfDbn0crLVOJhMRNaGwu0txHzJn72m/O9qxeD/uOHMSkw5bCQwbrVzkI6FhTrNQC6fV2RL60YrKDKC5xFwFXhy3TGrjnDG78UezcgX++AT4k83B/V9k6cU8k+WCzmaGbFrX7iitCbaQKo3DxltAFB+DxJ0tAv3caorl577TgCY468EvGCHrc7XszNBdJXXn/61HxUm81KDts7xOf4EvQZy/4rN2KNNrp7ac9Z81n37kOpMm0MsEsT8175BrBv6cI9DBltam5c0L9G4+1x6jfLfnZdEE1O7Hr1ojyfPZA6m4QSntfvfE01o6QrAcn5el4ETaKNPu1r8BecIu4pwbKsBWgID+rLNSmgsIy9HB1fJxXCDBu3gCqQapZtpc3qenQzzKnvsPupFsEKzZoO9p6xEetcqdfskHet/5RcohP2w3FHMM8wQ MnHHYQOS Ixkm70tcWxZrYn58OaC43t8QbipXYWtYZ1gqj8AwNcTkj/2soUJJJjDq45G01HdfZosaVCa6eO0pjysm5awHK7PlHTlaO4/BM5B7PjWFVKYM3nshOmwXVv3zF2ul5ZBA30t0W7ri6iYDg8ar+mu8AcbfFfJJJHVh6tRXxvoMtjBqV2wjnWUgQJ8gy4BQAArTnB6b3cVnoczup7477y+ydHgmt6Ln04kKAJYFLo6ENWFB2pCZjlls9XYmKNg1dd4hw8NigmkuG5dcSpyez5T2Ikieh9LMT/9EnomPwmOuAspSF1Ckb/MyhHznkippCOUXxz3+hy0yfOimCW8qxAMkgbnlF7j4jSuH1ibsE X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jul 23, 2024 at 04:47:50PM +0200, Andrew Zaborowski wrote: > Uncorrected memory errors for user pages are signaled to processes > using SIGBUS or, if the error happens in a syscall, an error retval > from the syscall. The SIGBUS is documented in > Documentation/mm/hwpoison.rst#failure-recovery-modes > > But there are corner cases where we cannot or don't want to return a > plain error from the syscall. Subsequent commits covers two such cases: > execve and rseq. Current code, in both places, will kill the task with a > SIGSEGV on error. While not explicitly stated, it can be argued that it > should be a SIGBUS, for consistency and for the benefit of the userspace > signal handlers. Even if the process cannot handle the signal, perhaps > the parent process can. This was the case in the scenario that > motivated this patch. > > In both cases, the architecture's exception handler (MCE handler on x86) > will queue a call to memory_failure. This doesn't work because the > syscall-specific code sees the -EFAULT and terminates the task before > the queued work runs. > > To fix this: 1. let pending work run in the error cases in both places. > > And 2. on MCE, ensure memory_failure() is passed MF_ACTION_REQUIRED so > that the SIGBUS is queued. Normally when the MCE is in a syscall, > a fixup of return IP and a call to kill_me_never() are what we want. > But in this case it's necessary to queue kill_me_maybe() which will set > MF_ACTION_REQUIRED which is checked by memory_failure(). > > To do this the syscall code will set current->kill_on_efault, a new > task_struct flag. Check that flag in > arch/x86/kernel/cpu/mce/core.c:do_machine_check() > > Note: the flag is not x86 specific even if only x86 handling is being > added here. The definition could be guarded by #ifdef > CONFIG_MEMORY_FAILURE, but it would then need set/clear utilities. > > Signed-off-by: Andrew Zaborowski > --- > Resending through an SMTP server that won't add the company footer. > > This is a v2 of > https://lore.kernel.org/linux-mm/20240501015340.3014724-1-andrew.zaborowski@intel.com/ > In the v1 the existing flag current->in_execve was being reused instead > of adding a new one. Kees Cook commented in > https://lore.kernel.org/linux-mm/202405010915.465AF19@keescook/ that > current->in_execve is going away. Lacking a better idea and seeing > that execve() and rseq() would benefit from using a common mechanism, I > decided to add this new flag. > > Perhaps with a better name current->kill_on_efault could replace > brpm->point_of_no_return to offset the pain of having this extra flag. > --- > arch/x86/kernel/cpu/mce/core.c | 18 +++++++++++++++++- Since this touches arch/x86/, can an x86 maintainer review this? I can carry this via the execve tree... -Kees > include/linux/sched.h | 2 ++ > 2 files changed, 19 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c > index ad0623b65..13f2ace3d 100644 > --- a/arch/x86/kernel/cpu/mce/core.c > +++ b/arch/x86/kernel/cpu/mce/core.c > @@ -1611,7 +1611,7 @@ noinstr void do_machine_check(struct pt_regs *regs) > if (p) > SetPageHWPoison(p); > } > - } else { > + } else if (!current->kill_on_efault) { > /* > * Handle an MCE which has happened in kernel space but from > * which the kernel can recover: ex_has_fault_handler() has > @@ -1628,6 +1628,22 @@ noinstr void do_machine_check(struct pt_regs *regs) > > if (m.kflags & MCE_IN_KERNEL_COPYIN) > queue_task_work(&m, msg, kill_me_never); > + } else { > + /* > + * Even with recovery code extra handling is required when > + * we're not returning to userspace after error (e.g. in > + * execve() beyond the point of no return) to ensure that > + * a SIGBUS is delivered. > + */ > + if (m.kflags & MCE_IN_KERNEL_RECOV) { > + if (!fixup_exception(regs, X86_TRAP_MC, 0, 0)) > + mce_panic("Failed kernel mode recovery", &m, msg); > + } > + > + if (!mce_usable_address(&m)) > + queue_task_work(&m, msg, kill_me_now); > + else > + queue_task_work(&m, msg, kill_me_maybe); > } > > out: > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 61591ac6e..0cde1ba11 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -975,6 +975,8 @@ struct task_struct { > /* delay due to memory thrashing */ > unsigned in_thrashing:1; > #endif > + /* Kill task on user memory access error */ > + unsigned kill_on_efault:1; > > unsigned long atomic_flags; /* Flags requiring atomic access. */ > > -- > 2.43.0 > -- Kees Cook