Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4630426imw; Tue, 12 Jul 2022 11:17:55 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sNNgCL5+Ifw94/R9583krZy2jx73AM0g8k7DjOLUoxO2VdCvmCKB+Z2WTYAOg7e6aB2hNc X-Received: by 2002:a17:90b:164a:b0:1ee:dd88:f38c with SMTP id il10-20020a17090b164a00b001eedd88f38cmr5656444pjb.62.1657649874788; Tue, 12 Jul 2022 11:17:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657649874; cv=none; d=google.com; s=arc-20160816; b=y6KwXzdq/wYUSJfB4PA6ch5aKTMT/Cj7R5nYLkhA+d+gNUL92VM0eEmigFHP/qZdeG Qfa3Qm3noiYUJLoVQyvGO7T8oCbORew6uh07/J1FSGHHLSYSRg0r+pLPypkdAVdUUMl5 yods4+ySkKM+YXe2GBuHsGPWI16d+YitYXBsjx+xaQSa8iSho8qZNf+s40vSDKz8+AHs NxqzXBRtxEhtix3jc5y1kj+Hg5w4GVTRZ6Dla4x+M4OFqF7daM8bvUQFIoBkLm8HAGUH GpBuKyBa+W+OUIlJFCqDGUPaCDO97dnAdYw2RJzqdm3VsuoPqLILfYjR9Rb9XZYjLs6g COIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Yp1OmpY1y3vVYhTPvfPmHmX6dm6dSMFfYgW5f8nVVoA=; b=hZoJ7L34flZrFQKJCNr50Y1JzdTJHj4JEnMRSG045Hr7HweAOKaUEEk6bLbWUi4IkN 6R7lyi9o1XQbp9rBOR4uMUE1+4mYLGBn915r2t0s7VDZZtD7ymGH/UtjuQ0fY+g0p++u j3723EUn6fBB7ATz3sWtvw0JfTgr+xKsiFO1kdaOPMV1vnDMVdDro4KLl4YpTNPyD28T qidYRIx6x35QCPz07wtGNZG51OTjPadTY+Hs73f2O/xsS/S4FHSDddOul2buYJt3pOOx qMWi0upQ1eSJoLo5UvacpQCm4cCyUBUHwdSicRmWDfIbS2LEMU0y31KIGdYP3T64rxwh UATg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=V4mM+z6V; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e8-20020a17090301c800b0016c3d49b0e7si13564263plh.577.2022.07.12.11.17.41; Tue, 12 Jul 2022 11:17:54 -0700 (PDT) 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=@gmail.com header.s=20210112 header.b=V4mM+z6V; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231230AbiGLSJW (ORCPT + 99 others); Tue, 12 Jul 2022 14:09:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229800AbiGLSJI (ORCPT ); Tue, 12 Jul 2022 14:09:08 -0400 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39B972A712; Tue, 12 Jul 2022 11:09:07 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id k30so11135383edk.8; Tue, 12 Jul 2022 11:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yp1OmpY1y3vVYhTPvfPmHmX6dm6dSMFfYgW5f8nVVoA=; b=V4mM+z6VTxmp1Qzn39eT5HwOIxjSgejq39mLAAp1us24aatJLMZx+txxjyQgo0imyi kxFEYbZE+S0usVZnbvFjHdalXfPRZyrjPhw3FFSIk4g44jMrAbxMGf8YwMBTNDR5rayJ hxM3MYlmNOk8btngFeKDLxUYmd607gTbZbaHXaQ3iSjUsv7E/MWM027W1sS/cEGn4OB0 mJacaAin0xAn20hBpvslY5abMexQ+QodkAc3dbw+13FOes/x3O6MZMbzo4TavZ3x6oVr c4yG8Ra2baUE+5RmpqjBiKUYhagV3vHP9a+pKt5pErBz1tosJRPs78iYeosp5JKD6PlA b5mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Yp1OmpY1y3vVYhTPvfPmHmX6dm6dSMFfYgW5f8nVVoA=; b=0tszMNvOARll8wXRybmjSUI3HdPpTqDP0ycIlVn1B5NsoSnhSTJU1toMcJOVlKlQ3O xM1we5mSDAsaIcTOxvtw/jpJX4xn3UPKkO4pXNEaUkPel0iJ8WAufoVSxF0EAFJ9th5V hMJ+0+uDvqMMjTC26xQKd70AzmCTA3RqxzLyEv/nksIFF1y+omPlNP+nZWKJw2EyBqzQ GA8rkeNkstQQKVeMjWR6Qkq2/dxEzPfPSkhtzLMtzIS+F/GryDcPb+VBirJLv7JQuDfj NXP4PBRklnFEVQz5B6wxEpwuHcOOEdriDArfHz/bmlYVltpqzRLtkISij+YKURm/Irhh HC/g== X-Gm-Message-State: AJIora8u/3dE58kmzrSRY2mdM2jwS9389U7bSbYZHDLngkYJzGAHfolS FjeCJT9/uHWIMuj8SUBetAdjvpFJqPeclwmUpuc= X-Received: by 2002:a05:6402:350c:b0:43a:e25f:d73 with SMTP id b12-20020a056402350c00b0043ae25f0d73mr10720783edd.66.1657649345743; Tue, 12 Jul 2022 11:09:05 -0700 (PDT) MIME-Version: 1.0 References: <20220711083220.2175036-1-asavkov@redhat.com> <20220711083220.2175036-4-asavkov@redhat.com> In-Reply-To: From: Alexei Starovoitov Date: Tue, 12 Jul 2022 11:08:54 -0700 Message-ID: Subject: Re: [RFC PATCH bpf-next 3/4] bpf: add bpf_panic() helper To: Song Liu Cc: Artem Savkov , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , bpf , Networking , open list , Andrea Arcangeli Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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, Jul 12, 2022 at 10:53 AM Song Liu wrote: > > > > > +BPF_CALL_1(bpf_panic, const char *, msg) > > +{ > > + panic(msg); > > I think we should also check > > capable(CAP_SYS_BOOT) && destructive_ebpf_enabled() > > here. Or at least, destructive_ebpf_enabled(). Otherwise, we > may trigger panic after the sysctl is disabled. > > In general, I don't think sysctl is a good API, as it is global, and > the user can easily forget to turn it back off. If possible, I would > rather avoid adding new BPF related sysctls. +1. New syscal isn't warranted here. Just CAP_SYS_BOOT would be enough here. Also full blown panic() seems unnecessary. If the motivation is to get a memory dump then crash_kexec() helper would be more suitable. If the goal is to reboot the system then the wrapper of sys_reboot() is better. Unfortunately the cover letter lacks these details. Why this destructive action cannot be delegated to user space? btw, we should avoid adding new uapi helpers in most cases. Ideally all of them should be added as new kfunc-s, because they're unstable and we can rip them out later if our judgement call turns out to be problematic for whatever reason.