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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 E458BC4361B for ; Sun, 6 Dec 2020 22:06:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A345423110 for ; Sun, 6 Dec 2020 22:06:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727943AbgLFWGa (ORCPT ); Sun, 6 Dec 2020 17:06:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58212 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726400AbgLFWG3 (ORCPT ); Sun, 6 Dec 2020 17:06:29 -0500 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BDE0C0613D1 for ; Sun, 6 Dec 2020 14:05:42 -0800 (PST) Received: by mail-lj1-x244.google.com with SMTP id o24so12964717ljj.6 for ; Sun, 06 Dec 2020 14:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jYOh6UMvSpP9mpiuIeBGwJObn/ShTIBfx66r2r2mm1Q=; b=TAWEe2AJ21/ymnfEhRmgmu7yS9XHy518Q0Mm5DQLt3/4L7ngyEHQB42xDYoOvsFn4E 2MSnx6QdhRf7wJVUsTk/bWruWfa9rYv16INpIYLjxSfPSmXd5ruwjlT5RArGqoUIIa+q nNUnf+1/NTNa3lit9cpVAAQfP1CZsocHbYWCdws/zUzNr3+1jjAcmwNes9M5HF/qO9K8 Y/PeHJEEFG8cWzsP4a2lxjNWPCDA58LflNFsS9LYRdm5IGqS9y3I/PygPG3CCIasyZhH IJ0uCHVuvVGVzLcBLLNU4fxbq9xMqo1VQee4uVS2Ip+zbbY54Tl0nl8V1MEkvCdCRHMc I8lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jYOh6UMvSpP9mpiuIeBGwJObn/ShTIBfx66r2r2mm1Q=; b=J9209L4hbYxcibvdwx6i3PHymQqlwdl+QaVLO7imkRD/zNNypawCBu5pNf3ISxzLDE r4RkXqA+9GOPFtdnXtGf0yHLNGQXmuXBgryQ2qwjSRmqRqTuwONr9YlshezEZtdO7/Zt idJjb1J3PBmsY8jOecSXn3q4OAc+DYwY1gYtTGp6DW3/OYB6MutQgYBmBCa4t0qsb0qt 4lKElHePYckC4J07IEkU5FGhWp6Fna1A3C8qZOVTjUXbj+e7tkcew3jcBraX9elUKzdD EowZ/YdMWfGj5Ih937XE34u+5sRPAQyBkMe3ren8Y02kbk7UvAKy874hlBo/h0J6ZPhN kI8w== X-Gm-Message-State: AOAM530I0Ii3SGSUg1PEim+8lVGTVTkXWlojwoyUtwW9Nt1lPvOhUsez 1ZaVzzDgd/PSQ7IaxuGOgExZtOk1z8Y+rpg4bFeiuQ== X-Google-Smtp-Source: ABdhPJzMyGRuC+Bc1bPrBXnAz61CoiHtimGEqIGvA/y8Fk53fi5E7rQbPAV55C71yQzmhgVm+doW7FJaRfoD34AL6J0= X-Received: by 2002:a2e:9216:: with SMTP id k22mr7564877ljg.138.1607292340737; Sun, 06 Dec 2020 14:05:40 -0800 (PST) MIME-Version: 1.0 References: <20201206131036.3780898-1-vladimir.kondratiev@intel.com> <16d6fdae-74ac-774c-9193-130dcfc5bc6c@intel.com> In-Reply-To: <16d6fdae-74ac-774c-9193-130dcfc5bc6c@intel.com> From: Jann Horn Date: Sun, 6 Dec 2020 23:05:14 +0100 Message-ID: Subject: Re: [NEEDS-REVIEW] [PATCH] do_exit(): panic() when double fault detected To: Dave Hansen , Vladimir Kondratiev Cc: Jonathan Corbet , Luis Chamberlain , Kees Cook , Iurii Zaikin , "Paul E. McKenney" , Andrew Morton , Randy Dunlap , Thomas Gleixner , Mauro Carvalho Chehab , Mike Kravetz , "Guilherme G. Piccoli" , Andy Shevchenko , Kars Mulder , Lorenzo Pieralisi , Kishon Vijay Abraham I , Arvind Sankar , Joe Perches , Rafael Aquini , "Eric W. Biederman" , Christian Brauner , Alexei Starovoitov , "Peter Zijlstra (Intel)" , Davidlohr Bueso , Michel Lespinasse , chenqiwu , Minchan Kim , Christophe Leroy , "open list:DOCUMENTATION" , kernel list , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 6, 2020 at 4:37 PM Dave Hansen wrote: > On 12/6/20 5:10 AM, Vladimir Kondratiev wrote: > > Double fault detected in do_exit() is symptom of integrity > > compromised. For safety critical systems, it may be better to > > panic() in this case to minimize risk. > > Does this fix a real problem that you have observed in practice? > > Or, is this a general "hardening" which you think is a good practice? > > What does this have to do specifically with safety critical systems? > > The kernel generally tries to fix things up and keep running whenever > possible, if for no other reason than it helps debug problems. If that > is an undesirable property for your systems, then I think you have a > much bigger problem than faults during exit(). > > This option, "panic_on_double_fault", doesn't actually panic on all > double-faults, which means to me that it's dangerously named. I wonder whether part of the idea here is that normally, when the kernel fixes up a kernel crash by killing the offending task, a service management process in userspace (e.g. the init daemon) can potentially detect this case because it looks as if the task died with SIGBUS or something. (I don't think that actually always works in practice though, since AFAICS kernel crashes only lead to the *task* being killed, not the entire process, and I think killing a single worker thread of a multithreaded process might just cause the rest of the userspace process to lock up. Not sure whether that's intentional or something that should ideally be changed.) But if the kernel gives up on going through with do_exit() (because it crashed in do_exit() before being able to mark the task as waitable), the process may, to userspace, appear to still be alive even though it's not actually doing anything anymore; and if the kernel doesn't tell userspace that the process is no longer functional, userspace can't restore the system to a working state. But as Dave said, this best-effort fixup is probably not the kind of behavior you'd want in a "safety critical" system anyway; for example, often the offending thread will have held some critical spinlock or mutex or something, and then the rest of the system piles on into a gigantic deadlock involving the lock in question and possibly multiple locks that nest around it. You might be better off enabling panic_on_oops, ideally with something like pstore-based logging of the crash, and then quickly bringing everything back to a clean state instead of continuing from an unstable state and then possibly blocking somewhere.