On Mon, 2015-12-14 at 13:55 -0700, Chris Murphy wrote: > I'm aware of this proof of concept. I'd put it, and this one, in the > realm of a targeted attack, so it's not nearly as likely as other > problems needing fixing. That doesn't mean don't understand it better > so it can be fixed. It means understand before arriving at risk > assessment let alone conclusions. Assessing the actual risk of any such attack vector is IMHO quite difficult... but at least past experience has shown countless times over and over again, that any system, where people already saw it would have issues, were sooner or later actively attacked.
Take all the things from online banking... TAN, iTAN... at some point the two-factor auth via mobileTAN were some people already warned, that this would be rather easy to attack... banks and proponents of the system said, that this is rather not realistic in practise. I think alone in Germany we had some 8 million Euros that were stolen by hacking mTANs last year. > I didn't. I did state there are edge cases, not normal use. My > criticism of dd for copying a volume is for general purpose copying, > not edge cases. Sure... but I guess we've never needed to argue about that. If a howto were to be written on "how to best copy a btrfs filesystem" and someone would say "me! take dd"... I'd be surely on your side, sayin "Naaahh... stupid... you copy empty blocks and that like". But here we talk about something completely different... namely all those cases where UUID collisions could happen, including those where a bit-identical copy is, for whichever reason, the best solution. > I already have, as have others. So far you've only said it would be bad practise as it wouldn't work well with filesystems that do use UUIDs. I agree with what Austin gave you as an answer upon that. > Does the user want cake or pie? The computer doesn't have that level > of granular information when there are two apparently bitwise > identical devices. I'm quite sure the computer has some concept of device path, and UUID isn't the only way to identify a device. If that was so, than any cloned ext4 would suffer from corruptions as well, as the fs would chose the device based on UUID. brtfs does of course more, especially in the multi-device case,... where it needs to differ devices based on their content, no on their path (which may be unstable). But such case can surely be detected, and as you said yourself below: > So option a is to simply fail and let the user > resolve the ambiguity. ... on could e.g. simply require the user to resolve the situation manually. And I guess that's exactly what I've wrote here several times in this thread, for mounting situations, for rebuild/fsck/repair/etc. sitations. > Option b is maybe to leveral btrfs check code > and find out if there's more to the story, some indication that one > of > the apparently identical copies isn't really identical. Can't believe that this would be possible... if they're bitwise identical, they're bitwise identical, the only thing that differs them is how they're connected, e.g. USB port 1, sata port 2, etc.. But as this is unstable (just swap two sata disks) it cannot be used. > That's not something btrfs can resolve alone. Sure, I've never demanded that. I always said "handle it gracefully" (i.e. no corruptions, no new mounts, fsck's, etc.), require the user to manually sort out things. Not automagically determine which of the devices are actually the right ones and use them. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
