On Wed, Apr 8, 2020 at 5:17 AM Johannes Thumshirn <Johannes.Thumshirn@xxxxxxx> wrote: > > On 07/04/2020 20:02, Chris Murphy wrote: > > Hi, > > > > What's the status of this work? > > https://lore.kernel.org/linux-btrfs/20191015121405.19066-1-jthumshirn@xxxxxxx/ > > It's done but no-one was interested in it and as I haven't received any > answers from Dave if he's going to merge it, I did not bring it to > attention again. After all it was for a specific use-case SUSE has/had > and I left the company. I'm thinking of a way to verify that a non-encrypted generic boot+startup data hasn't been tampered with. That is, a generic, possibly read-only boot, can be authenticated on the fly. Basically, it's fs-verity for Btrfs, correct? Other use cases? > If there is still interest in this work I can re-base my branches [1][2] > and add blake2b as well, this /should/ be trivially done. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/jth/linux.git/log/?h=btrfs-integrity > [2] https://github.com/morbidrsa/btrfs-progs/tree/mkfs-hmac I think 'btrfs check' also needs to be fed the hmac in order to verify checksums and also rewrite out a new csum or extent tree and do repairs? > I just don't want to spend time on it again when it's not going to be > merged in the end (for what ever reason). Sure. Seems reasonable. -- Chris Murphy
