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 F3B44C7618E for ; Mon, 24 Apr 2023 15:33:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232011AbjDXPdM (ORCPT ); Mon, 24 Apr 2023 11:33:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231965AbjDXPdI (ORCPT ); Mon, 24 Apr 2023 11:33:08 -0400 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8C277A8B for ; Mon, 24 Apr 2023 08:32:55 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-506bdf29712so34424561a12.0 for ; Mon, 24 Apr 2023 08:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1682350374; x=1684942374; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uAia9ZoCM3Ngt40DYLr2QLseOj/p7pPYWNkC2fjWJmw=; b=qWrSGUzCxRq8qH9ciyQYay96/ootXHgah+P6qqyhGbCAQ2pJ8/OxJrzulk56To27uy 09RLg/kTfw37Y4n+Y6DBPHrqNJM86jTGeI+B59T2u0X1ivH2gkzn4r7IIy7tcMBPzleL 451KVjoReU+5shixxVPasIdCw/4ump/BEaTRo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682350374; x=1684942374; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uAia9ZoCM3Ngt40DYLr2QLseOj/p7pPYWNkC2fjWJmw=; b=UGlfLSBfdV/+bX9VdgVS1VtQDO/f3vYZY+qScCtpkDdwEocIQ+PV98POur5uvOBaxA 8zr45EU4j43/oiLkXZnnTiR2mknKUg88oJ1E4TZGKQHWulADm8qKYTOv/Ym14LM12nIj kM27iXAV+7rzrdOmkd0pclo83iRHgOUEw5fho6DMt8LuzF0c9byKw9oBxk9ovaidyoy+ kb8VzRqofBSP3kM9oiX7ZBiWBSEKTUVupbDJpsTT8NvNA+tNbTUQqCrgCezpduoVuAGP R+3k91A2CMryYf4SeHO6qyMRuOojQ6TvCBe2DGNuYzqlJnXRoBrsbQa/RCS9P07rzvQg bKLg== X-Gm-Message-State: AAQBX9exXsZZJCLuJS4Z1iwvWff9XRbn9HCBgi0BeRMP7iHyna4KsPO0 YDsFgecOkGCYJu/Lq6kNUIHX7Z1bGIkutIgBeSSKgA== X-Google-Smtp-Source: AKy350ZlEFYElE3Cz+YrZZbx+udm5MYxX+58hoksQpdxqtGw8JQgjq/51zlo+VJfHxiyRLGkhE1nZhNtsXCZO/Kgvz0= X-Received: by 2002:a17:906:d1cb:b0:957:9ddd:8809 with SMTP id bs11-20020a170906d1cb00b009579ddd8809mr8178755ejb.35.1682350374328; Mon, 24 Apr 2023 08:32:54 -0700 (PDT) MIME-Version: 1.0 References: <20230418014037.2412394-1-drosen@google.com> In-Reply-To: <20230418014037.2412394-1-drosen@google.com> From: Miklos Szeredi Date: Mon, 24 Apr 2023 17:32:42 +0200 Message-ID: Subject: Re: [RFC PATCH bpf-next v3 00/37] FUSE BPF: A Stacked Filesystem Extension for FUSE To: Daniel Rosenberg Cc: bpf@vger.kernel.org, Alexei Starovoitov , Amir Goldstein , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org, Daniel Borkmann , John Fastabend , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , Jonathan Corbet , Joanne Koong , Mykola Lysenko , kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 18 Apr 2023 at 03:40, Daniel Rosenberg wrote: > > These patches extend FUSE to be able to act as a stacked filesystem. This > allows pure passthrough, where the fuse file system simply reflects the lower > filesystem, and also allows optional pre and post filtering in BPF and/or the > userspace daemon as needed. This can dramatically reduce or even eliminate > transitions to and from userspace. I'll ignore BPF for now and concentrate on the passthrough aspect, which I understand better. The security model needs to be thought about and documented. Think about this: the fuse server now delegates operations it would itself perform to the passthrough code in fuse. The permissions that would have been checked in the context of the fuse server are now checked in the context of the task performing the operation. The server may be able to bypass seccomp restrictions. Files that are open on the backing filesystem are now hidden (e.g. lsof won't find these), which allows the server to obfuscate accesses to backing files. Etc. These are not particularly worrying if the server is privileged, but fuse comes with the history of supporting unprivileged servers, so we should look at supporting passthrough with unprivileged servers as well. My other generic comment is that you should add justification for doing this in the first place. I guess it's mainly performance. So how performance can be won in real life cases? It would also be good to measure the contribution of individual ops to that win. Is there another reason for this besides performance? Thanks, Miklos