Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp6255877rwb; Tue, 22 Nov 2022 10:44:38 -0800 (PST) X-Google-Smtp-Source: AA0mqf5ycroWmXmdmlvpTaPbsf8wzhiYoBxmcUR+tDAMQzNofrbB+SEFzVqRMlo6oUfOdTy/4Zc7 X-Received: by 2002:a05:6402:248e:b0:461:e2ab:912d with SMTP id q14-20020a056402248e00b00461e2ab912dmr5839678eda.93.1669142678628; Tue, 22 Nov 2022 10:44:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669142678; cv=none; d=google.com; s=arc-20160816; b=jlNpaz28MrKXVsTmtWAZGCeNIPn/2HjriPYmVf6rXHMPW763swRqQMFJWptMjkUMPB VbxbcA1tpnkHqPiNLuf+t11g95mDu83MM8jhhtdcaSpv41tUkpKLknx7i5dYr4ox9MVX sWM4JxZRxXhIt7TYsph3HGkqUP/Ak2h/3Fp4FQegcFHsGQjZRMTOfb6KyBs/QmpFTF6+ FB4UmN9XG2Skn11v1LAo9HpYBHMWwkeNw407wTr8bD8KNeWY1TFXkra+07ELqhI6mFeF npJcK32SoV7ufhp6mDZUsPJ3IpMc95YyJoPpUDXKXqh//Bh7Q8PVcjkkr4PmU4k0L40O 2GtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=NOAwg1GH4Aeud6ZcXb4+YxTLG8/FMKmU+z9fzWBgP3k=; b=bdOtq23dn+UDQLkEBn5HrGMXG+t53qtvsOGXXmcZDEhdXmIJQoqaXgGyGRGTtZwynv cDngFYyWI/h90NU7Uk/+GBFKlbkJrfNlfYavqcQ1tLMUW9zVsRmMaSvIaX9uhCn9+8WI SN9gCBXJofepVUTBrflINPcHZ3XMFtesPPiuTPnRtPDgC3ZwaunC9LQuCljSe4PnbITy cb36tL7nhddFVDYDVNnBlHn/pcrKkt0b09HihZi4i/mfHs6Et8p+yRGSeZbCoBfQMXQc C+MHErYlc7FUP3S1hMfNkLmcPUhaSoNFcH+mQw9Z9/qiUGhODXeTfmysUYni2Jf+BuCn 87hg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=qp5uxKNc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hz1-20020a1709072ce100b007894b9de062si12449942ejc.631.2022.11.22.10.44.16; Tue, 22 Nov 2022 10:44:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=qp5uxKNc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233919AbiKVSQt (ORCPT + 90 others); Tue, 22 Nov 2022 13:16:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232665AbiKVSQr (ORCPT ); Tue, 22 Nov 2022 13:16:47 -0500 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A9A9729A7 for ; Tue, 22 Nov 2022 10:16:46 -0800 (PST) Received: from zn.tnic (p200300ea9733e79b329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e79b:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 8DE8F1EC0532; Tue, 22 Nov 2022 19:16:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1669141004; h=from:from: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; bh=NOAwg1GH4Aeud6ZcXb4+YxTLG8/FMKmU+z9fzWBgP3k=; b=qp5uxKNc8hFWbLuZTSNGhTNaXhPQw44nS0DXtgX0NCNpNRop6+HVtwrYiB6pfAMnfExyFH 00BXwUkTQnFOx6f6RDtIXaRvbQV1PsKg3LpvdrFSFclXU5rqR4LXFslZWKQTTs8sQexlZt +w7tP0L+oPMj/ttVfn/pxqe8UA7Z3c8= Date: Tue, 22 Nov 2022 19:16:40 +0100 From: Borislav Petkov To: Chris Mason Cc: Alexei Starovoitov , Steven Rostedt , LKML , Linus Torvalds , Masami Hiramatsu , Andrew Morton , Peter Zijlstra , Kees Cook , Josh Poimboeuf , KP Singh , Mark Rutland , Florent Revest , Greg Kroah-Hartman , Christoph Hellwig Subject: Re: [PATCH] error-injection: Add prompt for function error injection Message-ID: References: <20221121104403.1545f9b5@gandalf.local.home> <3fa8ec60-dd96-c41f-ea46-8856bf855949@meta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3fa8ec60-dd96-c41f-ea46-8856bf855949@meta.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 22, 2022 at 12:42:33PM -0500, Chris Mason wrote: > I think there are a few different sides to this: > > - it makes total sense that we all have wildly different ideas about > which tools should be available in prod. Making this decision more fine > grained seems reasonable. > > - fault injection for testing: we have a stage of qualification that > does error injection against the prod kernel. It helps to have this > against the debug kernel too, but that misses some races etc. I always > just assumed distros and partners did some fault injection tests against > the prod kernel builds? That's what the debug kernel flavor is for. At least on SLES. That's why we have the MCE injection module in the debug flavor and not in the production one. For the very same reason. > - overriding return values for security fixes: also not a common thing, > but it's a tool we've used. There are usually better long term fixes, > but it happens. Yeah, that's what live patching is for. > In other words, I really do care about the concerns you're expressing > here, and I'm usually first in line to complain when random people make > my job harder. I'm just not seeing these issues with BPF, and I see > them actively trying to increase safety over time. So this might be your opinion and I respect it but your first paragraph was spot on: to *have* the option to decide whether a company wants to support that in production or not. I'm sure it makes sense for you in your production scenarios but it doesn't for us. At least not at this point. And I think this should be disabled in our kernels for now. When the team decides someday that they wanna deal with bug reports of people doing fault injection, then sure by all means. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette