On 14/04/2020 06:06, Christoph Anton Mitterer wrote: > On Thu, 2020-04-09 at 08:50 +0000, Johannes Thumshirn wrote: >> Maybe having someone in the community being interested in this work >> can >> accelerate it's upstream acceptance. > > I think it would be great having something like this in btrfs. > > > If this was to be merged, it would perhaps make sense to have it > audited by a number of crypto experts. Sure. > And also, to clearly specify what it can to and what not: > - like how it behaves with other features of btrfs (compression, raid, > repair, etc.) > - limitations (e.g. fs-verity was just read-only, wasn't it?!) Yes fs-verify is read-only, this btrfs version of it is read-write if you have the key as it (ab)uses btrfs' internal checksums for the protection information and does not relay on merkle trees in extended attributes or other additional on-disk data. > - what exactly does it protect? > - "just" the content of files (i.e. a file with invalid HMAC will be > detected) > - file metadata (dates, names, permissions, owners, xattrs, etc) > - the file hirarchy (location of the files in the tree) > - would files removed/added (by an attacker) be detected It protects the file's contents as well as the metadata. Btrfs uses 'struct btrfs_header' as a start of every tree block. This header starts with a checksum, so the contents of every tree block are verified. The super-block also has a checksum, which is generated by the same scheme. Furthermore every data block (file content) is added to the checksum tree which also uses this checksum scheme. By exchanging the checksum to a keyed hash, one would need the key to make any modification to the file-system and as checksums are a first class citizen in btrfs no changes are needed to other features. If you mount your file system with nodatasum, you loose data verification though, but that's kind of obvious. Byte, Johannes
