On Sun, Dec 13, 2015 at 5:27 PM, Christoph Anton Mitterer <cales...@scientia.net> wrote: > On Fri, 2015-12-11 at 16:06 -0700, Chris Murphy wrote: >> For anything but a new and empty Btrfs volume > What's the influence of the fs being new/empty? > >> this hypothetical >> attack would be a ton easier to do on LVM and mdadm raid because they >> have a tiny amount of metadata to spoof compared to a Btrfs volume >> with even a little bit of data on it. > Uhm I haven't said that other systems properly handle this kind of > attack. ;-) > Guess that would need to be evaluated... > > >> I think this concern is overblown. > I don't think so. Let me give you an example: There is an attack[0] > against crypto, where the attacker listens via a smartphone's > microphone, and based on the acoustics of a computer where gnupg runs. > This is surely not an attack many people would have considered even > remotely possible, but in fact it works, at least under lab conditions.
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. > Apart from that, btrfs should be a general purpose fs, and not just a > desktop or server fs. > So edge cases like forensics (where it's common that you create bitwise > identical images) shouln't be forgotten either. 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. > > >> > >If your workflow requires making an exact copy (for the shelf or >> > > for >> > > an emergency) then dd might be OK. But most often it's used >> > > because >> > > it's been easy, not because it's a good practice. >> > Ufff.. I wouldn't got that far to call something here bad or good >> > practice. >> >> It's not just bad practice, it's sufficiently sloppy that it's very >> nearly user sabotage. That this is due to innocent ignorance, and a >> long standing practice that's bad advice being handed down from >> previous generations doesn't absolve the practice and mean we should >> invent esoteric work arounds for what is not a good practice. We have >> all sorts of exhibits why it's not a good idea. > Well if you don't give any real arguments or technical reasons (apart > from "working around software that doesn't handle this well") I > consider this just repetition of the baseless claim that long standing > practise would be bad. I already have, as have others. 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. The file system sees them both as dessert, without other distinction. So option a is to simply fail and let the user resolve the ambiguity. 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. But that's a lot of work for something that probably won't happen. What's more likely is they aren't just apparently identical, they are in fact identical because it's an LVM snapshot or a dd copy that's making them appear identical. That's not something btrfs can resolve alone. To automate the distinction, requires more information. If it's LVM, possibly LVM and Btrfs could work together where LVM LV UUID * Btrfs volume UUID = Btrfs volume UUID' (as in a derivative) and to treat it internally with a new temp UUID that's throw away. If it's a raw device, I still see this as the user's problem. They created it, they'll have to help resolve the ambiguity by yanking one of the drives. > Long story, short, I think we can agree, that - dd or not - corruptions > or attack vectors shouldn't be possible. Yes. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
