Fair enough. I imagine the intersection of "people who know about filesystems" and "people who know about crypto" is pretty small anyway. There were solid reasons why fscrypt wasn't feasible - IIRC, it was because the XTS scheme that it uses ties a block's encryption to its physical location on disk, which breaks balancing. You could use the logical location within the file instead, but that's horrendously insecure (all files with the same cleartext would have the same ciphertext). My version gets round this by randomizing the initialization vector whenever an extent is created, and storing this with the metadata. It also works with reflink copies - there's no reason why you can't do this with encrypted files. Omar, or whoever, is there anything I can do to speed this along? I was careful not to repeat the mistakes that other people here have made while tackling the same issue previously, so it'd be a shame to let it go to waste. On 27/4/20 5:49 am, Chris Murphy wrote: > On Sun, Apr 26, 2020 at 8:25 AM Mark Harmstone <mark@xxxxxxxxxxxxx> wrote: >> Last thing I heard was that Omar Sandoval at Facebook was looking into it. I never heard anything back about my patches, though. > I think the biggest difficulty with that patchset isn't as much the > patchset, but the bandwidth of people who can review it. It was a > complex patchset and didn't use fscrypt. (For reasons that are > explained, but then also at least originally the Btrfs maintainers > wanted to initially implement an fscrypt/VFS approach. Maybe it's too > difficult.) > > I'm curious whether Omar is working on something and what the time > frame could plausibly be. In the meantime, other approaches are being > explored, based on LUKS encrypted loop mounted files, as in > https://systemd.io/HOME_DIRECTORY/ > > Btrfs has advantages here, including asynd discards and online fs > resize, in case someone wants to attempt to manage the ensuing fantasy > of sparse backing files. The loss of dedup and reflink doesn't seem to > be a problem because it can't be done with encrypted extents anyway. >
