On Fri, Jul 3, 2020 at 9:14 AM Josef Bacik <josef@xxxxxxxxxxxxxx> wrote: > > On 7/3/20 9:37 AM, Eric Sandeen wrote: > > Does btrfsck really never attempt to salvage a metadata block with a bad CRC by > > validating its fields? > > No, I suppose we could, I'll add it to the list. Generally speaking if there's > a bad checksum detected we just attempt to recover based on what we couldn't get > access to. However that's difficult if it's a node. If it's a leaf then > usually you just lose some metadata that can be inferred from other data. For > example if you lose a leaf in the extent tree, well we can add all that > information back once we've scanned the rest of the file system and know what > extents are missing in the extent tree. > > Same goes for directory items, we detect that we are missing directory items, > but we have references for them and so we add the missing directory items that > were lost from that corrupt block. > > But again, if you lose a node you lose access to many leaves, which makes it > more likely we'll lose somehting because we'll lose the other information we can > use to recover what was lost. The extent tree and checksum trees are exceptions > to this, since they can be rebuilt from scratch, provided everything else is fine. > > And then if we did decide to validate nodes, we _might_ be ok, but we might end > up with old versions of leaves because it happens to point at something that > appears to be correct, but isn't really. Our metadata changes all the time, so > it's not outside the realm of possiblities that the corruption points at a > seemlingly valid piece of metadata, but isn't and thus makes us do something > _really_ wrong. Thanks, Maybe it's reasonable to expect 'btrfs check --repair' to look for plausible alternatives when using non-crypto checksums that mismatch. But I'm not certain it's OK when using cryptographic checksums - how do you distinguish between incidental corruption and a malicious attack? The repair might be the attack vector. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
