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 X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E204C47404 for ; Wed, 2 Oct 2019 20:58:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 756A221783 for ; Wed, 2 Oct 2019 20:58:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="YM7PrqwY" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728967AbfJBU6t (ORCPT ); Wed, 2 Oct 2019 16:58:49 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:40451 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728055AbfJBU6s (ORCPT ); Wed, 2 Oct 2019 16:58:48 -0400 Received: by mail-pf1-f194.google.com with SMTP id x127so207556pfb.7 for ; Wed, 02 Oct 2019 13:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=KX5XeevGScIhOFues3GQkV78ozucGw/LYZ1l8L5X6bo=; b=YM7PrqwY/F7Vm9PudRT17T2mqcMDRwHbIT7qw3mpkzdEEzHkANg4PLltdxVjuLFB4q mOMigow1C99Fxn3258qWATdkH6FCy/iw8I1WAaM+BP4aM7NWNDxHcJANq1Drp3mh+m2H /aEO9TVSFVtczdY6PmO9rseb3o8Dna0PVSt1s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=KX5XeevGScIhOFues3GQkV78ozucGw/LYZ1l8L5X6bo=; b=kW1+iYfDhNtj+W8l8CFNgPhzK2VOy97ZrQHXv64QnY3vm1qJKE80f6GWpHnY5u1foE svnu2ww+guK6WKFsIpNxtTOgLiCK7+HPjQ1kk30yzyCKae7O15foh+8iCLa3R2FjL3V+ TTseZqwGcXMPBT/iY6C5zrVZcuSxa8jcHYOhm/moc5TpRnfABn09ItxqIJj8LY4YVLXX CYfdN0Tq2n07QIKNMir/VkdhepezXeOPViejEBFdpoVwYjPNuXjTjzfUvQA1tU6XXQnR iahLC882wHwKD78RkHFFxqDbjldxlNrF5oLJrYRfuIk1SnVoxoRxo/sYOf2pXxYzdwap 6qQQ== X-Gm-Message-State: APjAAAVJnEIxH4z3InaN6NjM/lRjt0UIZ3l2JQkICIPf/UxUQiO9ULVE z97bjLSKl4fU5vw5Uo2oKlZ1Tg== X-Google-Smtp-Source: APXvYqyKNOmRPkS1Q8AKw0jUMUMu27C3e3zFkbZCALS8GZ9yijv6oqy5W8ctOfywkUEq/6vs+Euvuw== X-Received: by 2002:aa7:97b0:: with SMTP id d16mr7065724pfq.54.1570049927960; Wed, 02 Oct 2019 13:58:47 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id p190sm354504pfb.160.2019.10.02.13.58.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Oct 2019 13:58:47 -0700 (PDT) Date: Wed, 2 Oct 2019 13:58:46 -0700 From: Kees Cook To: Will Deacon Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, contact@xogium.me, Russell King , Greg Kroah-Hartman , Ingo Molnar , Andrew Morton , stable@vger.kernel.org, Feng Tang , Petr Mladek , Steven Rostedt , Sergey Senozhatsky Subject: Re: [PATCH] panic: Ensure preemption is disabled during panic() Message-ID: <201910021355.E578D2FFAF@keescook> References: <20191002123538.22609-1-will@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191002123538.22609-1-will@kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 02, 2019 at 01:35:38PM +0100, Will Deacon wrote: > Calling 'panic()' on a kernel with CONFIG_PREEMPT=y can leave the > calling CPU in an infinite loop, but with interrupts and preemption > enabled. From this state, userspace can continue to be scheduled, > despite the system being "dead" as far as the kernel is concerned. This > is easily reproducible on arm64 when booting with "nosmp" on the command > line; a couple of shell scripts print out a periodic "Ping" message > whilst another triggers a crash by writing to /proc/sysrq-trigger: > > | sysrq: Trigger a crash > | Kernel panic - not syncing: sysrq triggered crash > | CPU: 0 PID: 1 Comm: init Not tainted 5.2.15 #1 > | Hardware name: linux,dummy-virt (DT) > | Call trace: > | dump_backtrace+0x0/0x148 > | show_stack+0x14/0x20 > | dump_stack+0xa0/0xc4 > | panic+0x140/0x32c > | sysrq_handle_reboot+0x0/0x20 > | __handle_sysrq+0x124/0x190 > | write_sysrq_trigger+0x64/0x88 > | proc_reg_write+0x60/0xa8 > | __vfs_write+0x18/0x40 > | vfs_write+0xa4/0x1b8 > | ksys_write+0x64/0xf0 > | __arm64_sys_write+0x14/0x20 > | el0_svc_common.constprop.0+0xb0/0x168 > | el0_svc_handler+0x28/0x78 > | el0_svc+0x8/0xc > | Kernel Offset: disabled > | CPU features: 0x0002,24002004 > | Memory Limit: none > | ---[ end Kernel panic - not syncing: sysrq triggered crash ]--- > | Ping 2! > | Ping 1! > | Ping 1! > | Ping 2! > > The issue can also be triggered on x86 kernels if CONFIG_SMP=n, otherwise > local interrupts are disabled in 'smp_send_stop()'. > > Disable preemption in 'panic()' before re-enabling interrupts. Is this perhaps the correct solution for what commit c39ea0b9dd24 ("panic: avoid the extra noise dmesg") was trying to fix? Either way: Reviewed-by: Kees Cook -Kees > > Cc: Russell King > Cc: Greg Kroah-Hartman > Cc: Ingo Molnar > Cc: Kees Cook > Cc: Andrew Morton > Cc: > Link: https://lore.kernel.org/r/BX1W47JXPMR8.58IYW53H6M5N@dragonstone > Reported-by: Xogium > Signed-off-by: Will Deacon > --- > kernel/panic.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/panic.c b/kernel/panic.c > index 47e8ebccc22b..f470a038b05b 100644 > --- a/kernel/panic.c > +++ b/kernel/panic.c > @@ -180,6 +180,7 @@ void panic(const char *fmt, ...) > * after setting panic_cpu) from invoking panic() again. > */ > local_irq_disable(); > + preempt_disable_notrace(); > > /* > * It's possible to come here directly from a panic-assertion and > -- > 2.23.0.444.g18eeb5a265-goog > -- Kees Cook