On Fri, Jul 3, 2020 at 9:14 AM Josef Bacik <jo...@toxicpanda.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to