On Thu, Apr 9, 2020 at 6:31 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > 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. Nevermind... :D \subsubsection{HMAC} I'm just gonna read the whole thing. -- Chris Murphy
