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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8CBCC433EF for ; Tue, 12 Jul 2022 18:09:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233338AbiGLSJX (ORCPT ); Tue, 12 Jul 2022 14:09:23 -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-Google-Smtp-Source: AGRyM1saSErCrTNPa4aZDOBLpDXpTNVhuuM81/gv5HZTdRRDXX80C5hVGqz1cHsM/BZOGLgxxSyeLeHDgNxkvUzb9zI= 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" 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.