On 2020/5/14 下午5:24, Johannes Thumshirn wrote: > From: Johannes Thumshirn <johannes.thumshirn@xxxxxxx> > > This series adds file-system authentication to BTRFS. > > Unlike other verified file-system techniques like fs-verity the > authenticated version of BTRFS does not need extra meta-data on disk. > > This works because in BTRFS every on-disk block has a checksum, for meta-data > the checksum is in the header of each meta-data item. For data blocks, a > separate checksum tree exists, which holds the checksums for each block. > > Currently BRTFS supports CRC32C, XXHASH64, SHA256 and Blake2b for checksumming > these blocks. This series adds a new checksum algorithm, HMAC(SHA-256), which > does need an authentication key. When no, or an incoreect authentication key > is supplied no valid checksum can be generated and a read, fsck or scrub > operation would detect invalid or tampered blocks once the file-system is > mounted again with the correct key. > > Getting the key inside the kernel is out of scope of this implementation, the > file-system driver assumes the key is already in the kernel's keyring at mount > time. > > There was interest in also using keyed Blake2b from the community, but this > support is not yet included. > > I have CCed Eric Biggers and Richard Weinberger in the submission, as they > previously have worked on filesystem authentication and I hope we can get > input from them as well. > > Example usage: > Create a file-system with authentication key 0123456 > mkfs.btrfs --csum "hmac(sha256)" --auth-key 0123456 /dev/disk > > Add the key to the kernel's keyring as keyid 'btrfs:foo' > keyctl add logon btrfs:foo 0123456 @u > > Mount the fs using the 'btrfs:foo' key > mount -t btrfs -o auth_key=btrfs:foo,auth_hash_name="hmac(sha256)" /dev/disk /mnt/point > > Note, this is a re-base of the work I did when I was still at SUSE, hence the > S-o-b being my SUSE address, while the Author being with my WDC address (to > not generate bouncing mails). > > Changes since v2: > - Select CONFIG_CRYPTO_HMAC and CONFIG_KEYS (kbuild robot) > - Fix double free in error path > - Fix memory leak in error path > - Disallow nodatasum and nodatacow when authetication is use (Eric) Since we're disabling NODATACOW usages, can we also disable the following features? - v1 space cache V1 space cache uses NODATACOW file to store space cache, althouhg it has inline csum, but it's fixed to crc32c. So attacker can easily utilize this hole to mess space cache, and do some DoS attack. - fallocate I'm not 100% sure about this, but since nodatacow is already a second class citizen in btrfs, maybe not supporting fallocate is not a strange move. Thanks, Qu > - Pass in authentication algorithm as mount option (Eric) > - Don't use the work "replay" in the documentation, as it is wrong and > harmful in this context (Eric) > - Force key name to begin with 'btrfs:' (Eric) > - Use '4' as on-disk checksum type for HMAC(SHA256) to not have holes in the > checksum types array. > > Changes since v1: > - None, only rebased the series > > Johannes Thumshirn (3): > btrfs: rename btrfs_parse_device_options back to > btrfs_parse_early_options > btrfs: add authentication support > btrfs: document btrfs authentication > > .../filesystems/btrfs-authentication.rst | 168 ++++++++++++++++++ > fs/btrfs/Kconfig | 2 + > fs/btrfs/ctree.c | 22 ++- > fs/btrfs/ctree.h | 5 +- > fs/btrfs/disk-io.c | 71 +++++++- > fs/btrfs/ioctl.c | 7 +- > fs/btrfs/super.c | 65 ++++++- > include/uapi/linux/btrfs_tree.h | 1 + > 8 files changed, 326 insertions(+), 15 deletions(-) > create mode 100644 Documentation/filesystems/btrfs-authentication.rst >
Attachment:
signature.asc
Description: OpenPGP digital signature
