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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 1FE67C433E0 for ; Wed, 17 Feb 2021 04:02:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D875364DF3 for ; Wed, 17 Feb 2021 04:02:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231146AbhBQECL (ORCPT ); Tue, 16 Feb 2021 23:02:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230315AbhBQECD (ORCPT ); Tue, 16 Feb 2021 23:02:03 -0500 Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 330FCC06174A for ; Tue, 16 Feb 2021 20:01:23 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id r75so13626957oie.11 for ; Tue, 16 Feb 2021 20:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ANgvTqrvC4DYjYxx38a/+PMAicbVz5b6Nwaxc/uQPMQ=; b=C3t1nILohbrhkHK56M6sxztXLC0ekqKf5XN2B42h4bPgZjFjsLYRlqrX41R0icBFbj 4frrCwvtcZl93sjX2NYaSX69P4IEgzh1gWH+u2eAhyEwLX/FaJ6TmIZuVLhEiGDmWbw0 ROSYd3+Uvika7xvhNOielJv6PfZodFHGEzOukBEAY3CDfhGvmqZb/9JTk4lj6ho0aAKJ cOMbYTSc6olEX8V+IbX7Qr2M/KVoT6izB/4laj5m/ONpqhjV2DBK3FI0UmeT7vSrG7w4 mcNn0PxUaIkY2r+slJUPy8KsiUc8EXfM0n8RmJsgiZ+7SsGjeCQc9asLWCqtLG0sDB78 Lxxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ANgvTqrvC4DYjYxx38a/+PMAicbVz5b6Nwaxc/uQPMQ=; b=Jp6L0RMHw5bFLNdr3/n4Qr5R87jZBWmBmoFZWRzAvDk4xgYKWtOWv6CiLYfrtOK6dd cc2RFYrH4GgNWkCY+dg7emqfzJ8ASLd2fwyMmgLCmZbAPsLi47RCP2lrgTjOLqldg7MK vng49gQ2NuzNzrxZPJVPfVe5JXcfLvsqW3atNm/XFg0u64HePBRLI5dJEqMQ6GDIn0e7 iQQAbI0lhnkainPYfwHjLQyVHyuBky1zPw5XJEecBbLdo0IQiO8Wyh6hdg0kv6UT7dx9 p2uf2xLaXrQfGtxXnZa29BMnywP6f3GgDrQEB3kCbWqPL7VIrc72VGw9Oz46GuhKZ5uE 7q0A== X-Gm-Message-State: AOAM533j+TGjC2B/OY2Uh54T9m1VB+VNrI8VKV+FoZm/eqLuunukWo/L 2TvTLbZLGxJyCAZrHJ1qYjrWQh0jXjZEPBoAofRHpA== X-Google-Smtp-Source: ABdhPJzt+PsCGGMNvePij/bC62mS3vzVF5T1CaJyFch91VEq5u081INTOdXf/2FCoVKb9I4DFfP4cYezPdgLU9UOO8M= X-Received: by 2002:aca:2812:: with SMTP id 18mr3477701oix.65.1613534482325; Tue, 16 Feb 2021 20:01:22 -0800 (PST) MIME-Version: 1.0 References: <20210203090745.4103054-2-drosen@google.com> <56BC7E2D-A303-45AE-93B6-D8921189F604@dilger.ca> <42511E9D-3786-4E70-B6BE-D7CB8F524912@dilger.ca> In-Reply-To: From: Daniel Rosenberg Date: Tue, 16 Feb 2021 20:01:11 -0800 Message-ID: Subject: Re: [PATCH 1/2] ext4: Handle casefolding with encryption To: "Theodore Ts'o" Cc: Andreas Dilger , Eric Biggers , Ext4 Developers List , Linux Kernel Mailing List , linux-fsdevel , Gabriel Krisman Bertazi , kernel-team@android.com, Paul Lawrence Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I'm not sure what the conflict is, at least format-wise. Naturally, there would need to be some work to reconcile the two patches, but my patch only alters the format for directories which are encrypted and casefolded, which always must have the additional hash field. In the case of dirdata along with encryption and casefolding, couldn't we have the dirdata simply follow after the existing data? Since we always already know the length, it'd be unambiguous where that would start. Casefolding can only be altered on an empty directory, and you can only enable encryption for an empty directory, so I'm not too concerned there. I feel like having it swapping between the different methods makes it more prone to bugs, although it would be doable. I've started rebasing the dirdata patch on my end to see how easy it is to mix the two. At a glance, they touch a lot of the same areas in similar ways, so it shouldn't be too hard. It's more of a question of which way we want to resolve that, and which patch goes first. I've been trying to figure out how many devices in the field are using casefolded encryption, but haven't found out yet. The code is definitely available though, so I would not be surprised if it's being used, or is about to be. -Daniel On Tue, Feb 9, 2021 at 8:03 PM Theodore Ts'o wrote: > > On Tue, Feb 09, 2021 at 08:03:10PM -0700, Andreas Dilger wrote: > > Depending on the size of the "escape", it probably makes sense to move > > toward having e2fsck migrate from the current mechanism to using dirdata > > for all deployments. In the current implementation, tools don't really > > know for sure if there is data beyond the filename in the dirent or not. > > It's actually quite well defined. If dirdata is enabled, then we > follow the dirdata rules. If dirdata is *not* enabled, then if a > directory inode has the case folding and encryption flags set, then > there will be cryptographic data immediately following the filename. > Otherwise, there is no valid data after the filename. > > > For example, what if casefold is enabled on an existing filesystem that > > already has an encrypted directory? Does the code _assume_ that there is > > a hash beyond the name if the rec_len is long enough for this? > > No, we will only expect there to be a hash beyond the name if > EXT4_CASEFOLD_FL and EXT4_ENCRYPT_FL flags are set on the inode. (And > if the rec_len is not large enough, then that's a corrupted directory > entry.) > > > I guess it is implicit with the casefold+encryption case for dirents in > > directories that have the encryption flag set in a filesystem that also > > has casefold enabled, but it's definitely not friendly to these features > > being enabled on an existing filesystem. > > No, it's fine. That's because the EXT4_CASEFOLD_FL inode flag can > only be set if the EXT4_FEATURE_INCOMPAT_CASEFOLD is set in the > superblock, and EXT4_ENCRYPT_FL inode flag can only be set if > EXT4_FEATURE_INCOMPAT_ENCRYPT is set in the superblock, this is why it > will be safe to enable of these features, since merely enabling the > file system features only allows new directories to be created with > both CASEFOLD_FL and ENCRYPT_FL set. > > The only restriction we would have is a file system has both the case > folding and encryption features, it will *not* be safe to set the > dirdata feature flag without first scanning all of the directories to > see if there are any directories that have both the casefold and > encrypt flags set on that inode, and if so, to convert all of the > directory entries to use dirdata. I don't think this is going to be a > significant restriction in practice, though. > > - Ted > > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >