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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2443C433ED for ; Mon, 17 May 2021 22:27:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AAC4C6113C for ; Mon, 17 May 2021 22:27:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343699AbhEQW3I (ORCPT ); Mon, 17 May 2021 18:29:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245485AbhEQW3I (ORCPT ); Mon, 17 May 2021 18:29:08 -0400 Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17CF6C061756 for ; Mon, 17 May 2021 15:27:51 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id d16so5939192pfn.12 for ; Mon, 17 May 2021 15:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Rp32pfq2apMKFD0ftnAk36tGqKQeEKqsfO9eY//kHYc=; b=xns74opwRYa0qABV6xUZeE1bv2ry92IPk5pmjoweWSy+Mv14Ck6iWu2C3LxzOpI4F4 P8UzQnEK9lvjXYKntbotLorv7NgYMAa3KWvkbE88jCeRL5Ja/xUnttYkozCfVtKm12U9 9f7fMz+WCB29dtnmv59r9fcRaq52W5c41oPScFY1QL9JUlu7VRM/AxJ68k3gWCXhOhkN mr5ElxOnEkwrsIX0hvtKdak0KfEpc3wZg0ZZFCGYiZh7nvIMhHDWWW6QXdWulEQGiFiK L/ePwWBt4gHSlTMzhoJmx0m3Qe/PdAIWSrgB0tI62w9ak23bU4EwuvOItL3rfZTFErda fOmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Rp32pfq2apMKFD0ftnAk36tGqKQeEKqsfO9eY//kHYc=; b=i+bfozFMrwhu4AmpwLz40Zal59OlW0ZEjE2gyDqwRghBMhGgbIx6nWOGpxJgOj7d7M aG7d//KfkPVpRLrtOQB+DltVI2oNIZUpWr4tQnVGksi8W0nfGqLfB4ql7tfvXj8yRwZU hjbLyJJRPAqbRctNzLjDBr0lN/zLUhshmqKLBnshsFdg/9zbWwGzYqv4hVhRk8nrzG2J 4MtibY7TAAU75GEewhntIlBc6fPtwEG8kttGLSJRNqRIKyeNQf7DVQiiwBr+t0MKm09q bJpzCHHQksqeHnu9e4eGKA+PrXpwKqZkLpyzF+YDH1tQjWcoD/BMfdbPW8r6+Kjgza0X bFFg== X-Gm-Message-State: AOAM531VXSxxW8/uhZREQO6kATxip6fFUXBoHJ7QxZ5W/2wekBFgvvmv yZEdsaq8U5LllukcUHnYOyqeIg== X-Google-Smtp-Source: ABdhPJwOZsAr2depBcBQRACkwV3/LDqsgKuuVe+GhYd6PJVSRn7rMWArZoOkvFJopxNLE04qjlmIGw== X-Received: by 2002:a63:7158:: with SMTP id b24mr1708763pgn.310.1621290470509; Mon, 17 May 2021 15:27:50 -0700 (PDT) Received: from relinquished.localdomain ([2620:10d:c090:400::5:19a9]) by smtp.gmail.com with ESMTPSA id q18sm10915649pfj.131.2021.05.17.15.27.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 May 2021 15:27:49 -0700 (PDT) Date: Mon, 17 May 2021 15:27:48 -0700 From: Omar Sandoval To: Linus Torvalds , "Theodore Y. Ts'o" , Jaegeuk Kim , Eric Biggers Cc: linux-fsdevel , linux-btrfs , Al Viro , Christoph Hellwig , Dave Chinner , Jann Horn , Amir Goldstein , Aleksa Sarai , Linux API , Kernel Team Subject: Re: [PATCH RERESEND v9 0/9] fs: interface for directly reading/writing compressed data Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Mon, May 17, 2021 at 02:32:47PM -0700, Linus Torvalds wrote: > On Mon, May 17, 2021 at 11:35 AM Omar Sandoval wrote: > > > > Patches 1-3 add the VFS support, UAPI, and documentation. Patches 4-7 > > are Btrfs prep patches. Patch 8 adds Btrfs encoded read support and > > patch 9 adds Btrfs encoded write support. > > I don't love the RWF_ENCODED flag, but if that's the way people think > this should be done, as a model this looks reasonable to me. > > I'm not sure what the deal with the encryption metadata is. I realize > there is currently only one encryption type ("none") in this series, > but it's not clear how any other encryption type would actually ever > be described. It's not like you can pass in the key (well, I guess > passing in the key would be fine, but passing it back out certainly > would not be). A key ID from a keyring? > > So there's presumably some future plan for it, but it would be good to > verify that that plan makes sense.. What I'm imagining for fscrypt is: 1. Add ENCODED_IOV_ENCRYPTION_* types for fscrypt. Consumers at least need to be able to distinguish between encryption policy versions, DIRECT_KEY policies, and IV_INO_LBLK_{64,32} policies, and maybe other details. 2. Use RWF_ENCODED only for the data itself. 3. Add new fscrypt ioctls to get and set the encryption key. The interesting part is (3). If I'm reading the fscrypt documentation correctly, in the default mode, each file is encrypted with a per-file key that is a function of the master key for the directory tree and a per-file nonce. Userspace manages the master key, we have a FS_IOC_GET_ENCRYPTION_NONCE ioctl, and the key derivation function is documented. So, userspace already has all of the pieces it needs to get the encryption key, and all of the information it needs to decrypt the data it gets from RWF_ENCODED if it so desires. On the set/write side, the user can set the same master key and policy with FS_IOC_SET_ENCRYPTION_POLICY, and we'd need something like an FS_IOC_SET_ENCRYPTION_NONCE ioctl (possibly with a requirement that it be set when the file is empty). I think that's it. The details will vary for the other fscrypt policies, but that's the gist of it. I added the fscrypt maintainers to correct me if I missed something. Thanks, Omar