On Thu, Apr 9, 2020 at 2:50 AM Johannes Thumshirn <Johannes.Thumshirn@xxxxxxx> wrote: > > On 09/04/2020 02:18, Chris Murphy wrote: > > 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? > > > > Correct, example deployments would be embedded devices, or container > images. I've written a paper [1] for the 2019 SUSE Labs Conference > describing some of the scenarios, if you're interested. "downside to this is, on every unmount, the new hash value needs to be stored safely" [in e.g. a TPM] Could this make the file system not crash safe? As in, would you use authenticated btrfs in a read-only context, like seed-device? Or some industrial application where you're very, very certain, that the use case never calls for unplanned power failure or forced power off by a user? Seems difficult to use it in a desktop or laptop use case. -- Chris Murphy
