On Tue, May 05, 2020 at 05:59:14PM +0800, Qu Wenruo wrote: > After some more thought, there is a narrow window where the attacker can > reliably revert the fs to its previous transaction (but only one > transaction earilier). > > If the attacker can access the underlying block disk, then it can backup > the current superblock, and replay it to the disk after exactly one > transaction being committed. > > The fs will be reverted to one transaction earlier, without triggering > any hmac csum mismatch. > > If the attacker tries to revert to 2 or more transactions, it's pretty > possible that the attacker will just screw up the fs, as btrfs only > keeps all the tree blocks of previous transaction for its COW. > > I'm not sure how valuable such attack is, as even the attacker can > revert the status of the fs to one trans earlier, the metadata and COWed > data (default) are still all validated. > > Only nodatacow data is affected. I agree with the above, this looks like the only relialbe attack that can safely switch to previous transaction. This is effectively the consistency model of btrfs, to have the current and new transaction epoch, where the transition is done atomic overwrite of the superblock. And exactly at this moment the old copy of superblock can be overwritten back, as if the system crashed just before writing the new one. >From now on With each data/metadata update, new metadata blocks are cowed and allocated and may start to overwrite the metadata from the previous transaction. So the reliability of an undetected and unnoticed revert to previous transaction is decreasing. And this is on a live filesystem, the attacker would have to somehow prevent new writes, then rewrite superblock and force new mount. > To defend against such attack, we may need extra mount option to verify > the super generation? I probably don't understand what you mean here, like keeping the last committed generation somewhere else and then have the user pass it to mount?
