On Tue, Jun 12, 2018 at 11:30:45PM +0000, Xu, Wen wrote: > Hi Dave, > > I feel I can get your point a bit. Anyway recently I am fuzzing > log section of XFS. I reported four new bugs to mail list today. > They are all memory corruption issues, and I think some of them > are enough to be used to perform controlled write and code > execution. And I feel these bugs are not complex ones but exist > there that cannot simply be covered by CRC protection? If CRCs are enabled, then they fail when there are random bit corruptions in the journal. That stops these *storage errors* from causing further problems. Fuzzing filesystems was originally introduced to modelling storage errors and determine where the filesystem error handling was deficient. However, since "fuzzing" was taken over by the security crowd yeas ago, it's all about malicious actors. I don't know how many times I have to say "we cannot defend against malicious actors" before that sinks in. Again: CRCs are intended to mitigate the threat model of storage level errors causing problems, not to defeat /malicious attackers/. Modelling malicous users by random bit perturbation without CRC protection exposes fundamental architectural trust model deficiencies we cannot fix, and playing whack-a-mole with /malicious fuzzing/ does not change that. Existing filesystems cannot win that game, and it does nothing to protect users against emerging storage error models and trends. I care about data storage, not malicious actors. > In my > humble opinions, CRC protection mainly hardens the integrity of > the metadata instead of eliminating malicious metadata leading to > unexpected behaviors. Key word in that statement: /malicious/ > I am not very sure considering my limited > knowledge on XFS but you can take a look on them and see the > severity of these issues. They are input checking problems, and log recovery does not have robust input checking. That's why it has CRC protection - so we can detect storage based errors to avoid parsing broken input. We really need to improve the log recovery input verification, but it's way more complex than any other subsystem we currently do verification on. Untangling that mess will take time, resources and careful planning. It's not a fast fix, but we'll get there. In the mean time, throwing large numbers of "malicious actor" fuzzer bugs at us doesn't help anyone. If you want to do really useful fuzzing, try finding problems that the v5 filesystem CRC checking doesn't detect and protect against. That's something directly useful to us and hence XFS users, because it indicates structures on disk we haven't fully protected from typical storage based bit corruptions. Put simply: I don't really care about bugs from "malicious image corruption". I care about bugs that arise from storage errors that we don't already catch, and that means v5 filesystems need to be the focus of filesystem fuzzing.... I *really* don't want to have to say this again. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
