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 BC2FEC4345F for ; Wed, 1 May 2024 16:20:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A26C6B0088; Wed, 1 May 2024 12:20:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3532D6B0089; Wed, 1 May 2024 12:20:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21B306B008A; Wed, 1 May 2024 12:20:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0559E6B0088 for ; Wed, 1 May 2024 12:20:02 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A9FABC0B6C for ; Wed, 1 May 2024 16:20:01 +0000 (UTC) X-FDA: 82070338602.30.C27F3A9 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf12.hostedemail.com (Postfix) with ESMTP id D127F4000A for ; Wed, 1 May 2024 16:19:59 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=HcpfFG0s; spf=pass (imf12.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.178 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714580399; a=rsa-sha256; cv=none; b=ILycE7bZDAeuv++PxVINrc5gxSUV2dGDoFrVNNoGzuG8lcyexUgqNz0qMHC642x+hzeR6c rU+rz15nqlyasg+ifgiHQk+KL9eDHSM+b4AbWrzxYWu19Y5WXO8e4KxhDMbKv2Q+ifiXyz jDDAsCugc3she2/r6lnRZQi7LMrW+R0= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=HcpfFG0s; spf=pass (imf12.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.178 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714580399; 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=DLWObZ5roRvvXm2wJ4/mDw5Zfbke5H6gp1bKXRqe/6U=; b=pEGvlwQn3MSakGpyvqsQMHvHjuxUAqXBY7IGGgmjQPXHR093MBPLN2Tw94ETxYJbs0GGGM Eft7knGCEMvmussFML1xUZVTBsoWJLsiX4jnRwGCMRMa/vELW9kNjJN08EaiLtSik0OcOr LDHkBA1MqWQXxv3cT7hCdf6X+qIJzbI= Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-1ec92e355bfso7787415ad.3 for ; Wed, 01 May 2024 09:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1714580399; x=1715185199; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=DLWObZ5roRvvXm2wJ4/mDw5Zfbke5H6gp1bKXRqe/6U=; b=HcpfFG0sjrv6wa+k4vU11NxCtlq/xg76R7eD5hWRz8EBlOh25FZjyK12nhPSuQq9G6 GK6dYkSqgRisCLSCF04slcD9d/RTI5xaH7yTvKlBidb4cKnj5KjMxxC2uFhf0GeB7rBR 5dNHw8bOwsxid78Log7sevpBh8a9iKVXakDn4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714580399; x=1715185199; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DLWObZ5roRvvXm2wJ4/mDw5Zfbke5H6gp1bKXRqe/6U=; b=p1C0ZuXIfElFWGuZW9XZ7RfATjOOZRPHt92RSyFETb/yBbrHJknRiQcgL6qhPWn6vu EP55t2PEl9aZ71+hdazgGgaY+O4/M7prFTRMlakkoYgEYo+8ce2trY0REaUElI/3eS6j 2Et15BD++RJToduzP3kMqp2qwKRn0DBOm8LEmEIc6XXq6GpbkdTo+tUxeHSC+pA0Swmm 8v9ChQSF6Wn8iPcUc5tklvN7zz9qDaCAyxGd9HGiayXlt5FzZcEMaYt3BNk7xeD2JAKP uwfdLh5J5QCJAOzBLYMl8ALL8p0WPu7+uluUfP1nMfEVLXqd5fSpwqeWa7Wmg4Y2x8Qb Aflw== X-Forwarded-Encrypted: i=1; AJvYcCXkjRzXjIc38+UAwEFYOKFh8OIaM4Q1PckqsXUrC5e93nhcXP9YQ22J1QhMDHWAzfq26c9BCmM8bRJLs1IIt40/lhY= X-Gm-Message-State: AOJu0YwAOCxnHKsvsXdidBVkUiEgsOnQrMyBA6JolZtuzG5+3EJssx56 /JviNgG1yp/yuUiv1xogPFQpZngdaeE4/2q6kXUq1GjReYCCX47c1GJShYxTBg== X-Google-Smtp-Source: AGHT+IEHnYrLD6qYg1tPs21yTAG1nt/uGMqoBK+Ct7XcTlsInPqYvVnKh+a+qhzqWJH1d0IGV5dTNw== X-Received: by 2002:a17:90b:3ece:b0:2b2:c406:7d8d with SMTP id rm14-20020a17090b3ece00b002b2c4067d8dmr2934938pjb.16.1714580398579; Wed, 01 May 2024 09:19:58 -0700 (PDT) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id 192-20020a6301c9000000b0060795a08227sm12291552pgb.37.2024.05.01.09.19.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 May 2024 09:19:58 -0700 (PDT) Date: Wed, 1 May 2024 09:19:57 -0700 From: Kees Cook To: Andrew Zaborowski Cc: linux-edac@vger.kernel.org, linux-mm@kvack.org, Tony Luck , Borislav Petkov , Eric Biederman Subject: Re: [PATCH][RFC] exec: x86: Ensure SIGBUS delivered on MCE Message-ID: <202405010915.465AF19@keescook> References: <20240501015340.3014724-1-andrew.zaborowski@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240501015340.3014724-1-andrew.zaborowski@intel.com> X-Stat-Signature: m9hqfi13jpn4yeyxsnqbaucefjhwwdds X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D127F4000A X-HE-Tag: 1714580399-8135 X-HE-Meta: U2FsdGVkX198kJCkHZPBu3hbsCQDC3lfd/Q1uUvWnGwgxfuuj4tUQ/dMrJO0kgGQLhC9ZSGeRrGMdNkvj5AsDkYqbJo/27mKgsqyrCocwStWizBYouJzG562kFdAh3oot29YLcF6KYolPVdJHApcZggk4ym6FhH1+KfM50xWUFs2xqtKgKyUQBZ98btby8fsHX9tgza6o3IRIsolSunPO7Sn0FdR+IzmL0/qsFHiAX3cuPoQc4zR6aa/IEYQoyUxHCA9Ujcosa4s5T0v+1MuQC/TIY5PUrV37Dlb3ign/dMKDOEosYI7guU7Dv0kl1b22t+6PrLw+XBozd4uH5qfKktDO/XUVlaoW9S0Jg3pV0EYzBkJ2mVCwC5uayhL4k4MaGAzsXSSjZetyC7YjMdx+NxLXUH2dHICah0jt3icTiQkOAned9dZfyyLPkSHZK5Ce0zt1n3yMl1Gqok7UcEpTbNFi2hDFXJvVwS1HDy/CYgVUohQEBVKdqCj8n6hWKNySw9VQpTQud5tlzOEcu/w1oSBldbGxVsS4lD04EtQYybXWUPDB4l5sUhW1jLh+OqnA54SvPrq8eYkJtr3TJSDDPZWgwVQt2U9PFX/4ZQNHUnEQyfwtCeyw4vTHfzoM+v7De5sSdKsh+OuVx0mWUr1zfeVKFQWPHcxs5pMxm/NFYnXMsE3UgB+Fkxce8f9i1z5K0SaVvvejBzTMQSX5b+W40q4EEA1ff1+qLEsCKq3iKr9esC2gMouj87NlGBWVLjyX9MFrGmJp4sPzbN/o/FwBr/EOabo00E4wYKrnTQxLlCsoetV4HEI7Rr1qaf+tSibrSdsErixeTdiQByAIAlyOPj2tXeMGH3UUKFuDqejJEwMpf9rzJuvvf9LAGHUJaypHi6SsDXooTFfYTANvwVlQ+7FlQHDNozB7HseMAtapZFszLaLl7rSKvBsw1hFXSTzqbldwQsaKGoKvBxAGAW G1F2fn3B 5YLkNjEtiCuS7PnvnJGeGAm40E+/RJNxTzrDf89nbpr13m1jJo1KdySXBwywhFPluw0mWS1dcMMVGoTw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, 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 Wed, May 01, 2024 at 03:53:40AM +0200, Andrew Zaborowski wrote: > Uncorrected memory errors are signaled to processes using SIGBUS or an > error retval from a syscall. But there's a corner cases in execve where > a SIGSEGV will be delivered. Specifically this will happen if the binary > loader triggers a memory error reading user pages. The architecture's > handler (MCE handler on x86) may queue a call to memory_failure but that > won't run until the execve() returns. The binary loader is called after > bprm->point_of_no_return is set meaning that any error is handled by > bprm_execve() with a SIGSEGV to the process. Why is it needed to have a distinction between SIGBUS and SIGSEGV in this case? > To ensure it is terminated with a SIGBUS we 1. let pending work run in > the bprm_execve error case. > > And 2. 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 enough. But in this case > it's necessary to queue kill_me_maybe() which will set > MF_ACTION_REQUIRED. > > Reuse current->in_execve to make the decision. We're actually in the process of trying to remove[1] this flag, so I'd like to avoid adding new users of it. It sounds like it's desirable here because a choice is needed about kill_me_never() vs kill_me_maybe()? -Kees [1] https://lore.kernel.org/lkml/8fafb8e1-b6be-4d08-945f-b464e3a396c8@I-love.SAKURA.ne.jp/ > > Signed-off-by: Andrew Zaborowski > --- > arch/x86/kernel/cpu/mce/core.c | 14 ++++++++++++++ > fs/exec.c | 12 +++++++++--- > include/linux/sched.h | 2 +- > 3 files changed, 24 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c > index 84d41be6d06b..11effdff942c 100644 > --- a/arch/x86/kernel/cpu/mce/core.c > +++ b/arch/x86/kernel/cpu/mce/core.c > @@ -1593,6 +1593,20 @@ noinstr void do_machine_check(struct pt_regs *regs) > else > queue_task_work(&m, msg, kill_me_maybe); > > + } else if (current->in_execve) { > + /* > + * Cannot recover a task in execve() beyond point of no > + * return but stop further user memory accesses. > + */ > + 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); > } else { > /* > * Handle an MCE which has happened in kernel space but from > diff --git a/fs/exec.c b/fs/exec.c > index cf1df7f16e55..1bea9c252a11 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -1888,10 +1889,15 @@ static int bprm_execve(struct linux_binprm *bprm) > * If past the point of no return ensure the code never > * returns to the userspace process. Use an existing fatal > * signal if present otherwise terminate the process with > - * SIGSEGV. > + * SIGSEGV. Run pending work before that in case it is > + * terminating the process with a different signal. > */ > - if (bprm->point_of_no_return && !fatal_signal_pending(current)) > - force_fatal_sig(SIGSEGV); > + if (bprm->point_of_no_return) { > + task_work_run(); > + > + if (!fatal_signal_pending(current)) > + force_fatal_sig(SIGSEGV); > + } > > sched_mm_cid_after_execve(current); > current->fs->in_exec = 0; > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 3c2abbc587b4..8970a191d8fe 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -922,7 +922,7 @@ struct task_struct { > unsigned sched_rt_mutex:1; > #endif > > - /* Bit to tell TOMOYO we're in execve(): */ > + /* Bit to tell TOMOYO and x86 MCE code we're in execve(): */ > unsigned in_execve:1; > unsigned in_iowait:1; > #ifndef TIF_RESTORE_SIGMASK > -- > 2.39.3 > -- Kees Cook