On Thu, Apr 9, 2020 at 6:32 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > 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. "the used key has to be deployed at File System creation time and cannot easily be modified afterwards" Could a new HMAC be defined when adding a rw sprout device to a seed? i.e. in this case you'd need two HMACs, until the seed device is removed. Hmmm, maybe difficult. I don't think data checksums are recomputed on seed being removed; the balance replicated metadata block groups fairly intact including the csum tree. Regarding the key being stored in the TPM. I know the Windows 10 hardware requirements say a TPM 2.0 must be present and enabled. But I don't know to what degree such hardware is prevalent and supported by the kernel. -- Chris Murphy
