On 2020/5/6 上午6:32, David Sterba wrote: > 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? > Yes, that's my original idea. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
