Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp707200imw; Wed, 13 Jul 2022 06:39:43 -0700 (PDT) X-Google-Smtp-Source: AGRyM1u9EFXaSxtsOfAgqkLFcT7X+vSY0K2m+rQX2rWDcfGfD3P7UOeyogQn/Rvj9q39qo7zqLh3 X-Received: by 2002:a05:6a00:1312:b0:528:2948:e974 with SMTP id j18-20020a056a00131200b005282948e974mr3275048pfu.79.1657719583324; Wed, 13 Jul 2022 06:39:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657719583; cv=none; d=google.com; s=arc-20160816; b=iX8FcDeh49beTWtuY7skGs4dbaOzfbwQdDOEDDlyJJ9XWrx/p0xQX1NNj5+V7Tbz6z o9HIF2B01tdi389hhQtI2KLkEthXhGPqwwhllATOdY2q6Jl43asQfhnAYFB4giSwyw1A /R02m+8eufm4o19kpxMPTGl/xEj0bwLBse4uYJjix4QlfsfUFN73Aa43a9GVTc6Zv347 a2q/lmrjK/ltgUJ94rAetHaBAPz4TwTyNfCui/B7+QgzOyJd46P9VwuoPMR/df5vd1At GrqQgjBRFQlbu7bgMSnZptv7jGLQIrJsF96HWMFg53uO9+CDfG769J84rLiaOE8KTBYI tzUA== 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=sgNHH7BFb0s4RwPxS2Qx5icxf3D9jQ1/BExnQlyRDHc=; b=i+z6QNqlPaFNbL+q1dZqoRbeuIycUVtL+6s6jl1RK0x8XXCAgjdxoFfkjDi+6eYavk zkQ3URKLlnG229S1YtFq32gUBjoToKnBT5V7MuXb1P5hpI+zJhrdt7f8WyXbIrNpF2yd cIN1OzkpWX7EZrOyTqUaUJYmVhwK8220C6nXTo23hwAwP4eGjq14a5xb4nTwPxhUtlsW F9ly30jsTYK66RHNu3vhhSF+lI1Ikl5cTgoa7OyjG5vDYIJPo/lgR00tBXM58nUmNjM0 S0rmbHHfnks0PQ3VTESeyPzDDIsu19YnhuWYH//2DmFDeaFoDxaHC6hhClkdD+1kqOlu 9dBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YiaLdmSj; 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=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c9-20020a63ea09000000b0040d98652e34si15962021pgi.558.2022.07.13.06.39.30; Wed, 13 Jul 2022 06:39:43 -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=@redhat.com header.s=mimecast20190719 header.b=YiaLdmSj; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230466AbiGMNbn (ORCPT + 99 others); Wed, 13 Jul 2022 09:31:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229563AbiGMNbk (ORCPT ); Wed, 13 Jul 2022 09:31:40 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 618451B2 for ; Wed, 13 Jul 2022 06:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657719098; 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: in-reply-to:in-reply-to:references:references; bh=sgNHH7BFb0s4RwPxS2Qx5icxf3D9jQ1/BExnQlyRDHc=; b=YiaLdmSjOLTC6wy4VdDYRSELm///nAQX8iuPEYML/OgbRLotEYM5enFxJUlgDo/b0wkT/+ LEdzKIaK4b5qcI4GmgdEj9Duw/eBgwMdpyDrRYH45z7pQKPYxA1n3XcMoqgc1cmDoIp2FP 77H2qQOCQk6+4TXftzpX3V5ZQ7wyRiA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-650-m6BergIANhONx7akHrV2ng-1; Wed, 13 Jul 2022 09:31:32 -0400 X-MC-Unique: m6BergIANhONx7akHrV2ng-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DC6EE801231; Wed, 13 Jul 2022 13:31:31 +0000 (UTC) Received: from wtfbox.lan (unknown [10.40.192.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 375F8400DFA6; Wed, 13 Jul 2022 13:31:30 +0000 (UTC) Date: Wed, 13 Jul 2022 15:31:27 +0200 From: Artem Savkov To: Alexei Starovoitov Cc: Song Liu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , bpf , Networking , open list , Andrea Arcangeli , dvacek@redhat.com Subject: Re: [RFC PATCH bpf-next 3/4] bpf: add bpf_panic() helper Message-ID: References: <20220711083220.2175036-1-asavkov@redhat.com> <20220711083220.2175036-4-asavkov@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 11:08:54AM -0700, Alexei Starovoitov wrote: > 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. Point taken, I'll remove sysctl knob in any further versions. > 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. The main goal is to get the memory dump, so crash_kexec() should be enough. However panic() is a bit more versatile and it's consequences are configurable to some extent. Are there any downsides to using it? > Why this destructive action cannot be delegated to user space? Going through userspace adds delays and makes it impossible to hit "exactly the right moment" thus making it unusable in most cases. I'll add this to the cover letter. > 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. Ok, I'll look into doing it this way. -- Regards, Artem