On-disk format robustness requirements for new filesystems
As suggested by its name (and its acronym), EROFS is a read-only filesystem. It was developed at Huawei, and is intended for use in Android systems. EROFS is meant to differ from existing read-only filesystems in the area of performance; it uses a special compression algorithm that creates fixed-length blocks that, it is claimed, allows random access to compressed data with a minimum of excess I/O and decompression work. Details can be found in this USENIX paper [PDF] published in July.
Gao has made several requests in recent times to move EROFS out of the staging tree; the latest was posted on August 17. It read:
(EMUI is Huawei's version of Android.)
It would seem that there is little opposition to this move in general. As part of reviewing the code, though, Richard Weinberger noticed that the code generally trusts the data it reads from disks, often failing to check it for reasonableness. He quickly found a way to create a malformed filesystem that would put the kernel into an infinite loop, creating a system that is a bit more read-only than anybody had in mind. The problem was fixed just as quickly, but not before starting a discussion on whether robustness against hostile filesystem images should be a requirement for new filesystems entering the kernel.
Nobody disagrees that it would be a good thing if a filesystem implementation would do the right thing when faced with a hostile (or merely corrupt) filesystem image; that would make it possible to allow unprivileged users to mount filesystems without fear of handing over the keys to the entire system, for example. But, as Ted Ts'o pointed out, heavily used, in-kernel filesystems like ext4 and XFS don't meet that standard now, so requiring new filesystems to reach that level of robustness is presenting them with a higher bar:
In the case of EROFS, as Chao Yu pointed out, the intended use case makes this kind of robustness less important. The Android system images shipped in this filesystem format will be verified with a system like dm-verity, so the filesystem implementation should not be confronted with anything other than signed and verified images. Even so, the EROFS developers agree that this kind of bug should be actively sought out and fixed.
It seems that views about robustness against bad images vary somewhat among
filesystem developers. With regard to these bugs in ext4, Ts'o said that
"while I try to address them, it is by no means considered a high
priority work item
". He characterized the approach of the XFS
developers as being similar. Christoph Hellwig disagreed
strongly with that claim, though, saying that XFS developers work hard
to handle corrupt filesystem images, "although there are of course no
guarantees
". Eric Biggers asserted
that dealing with robustness issues should be mandatory, "but I can
understand that we don't do a good job at it, so we shouldn't hold a new
filesystem to an unfairly high standard relative to other filesystems
".
Hellwig arguably took the strongest position with regard to the standards that should be applied to new filesystems:
What those higher standards should be was not spelled out. They probably do not extend to absolute robustness against corrupt filesystem images, but it seems that developers would like to see at least an effort made in that direction. As Biggers put it:
Whether EROFS meets the "looks robust" standard is a bit controversial at
the moment. On
the other hand, there is little doubt that the EROFS developers are willing
and able to fix bugs quickly as they are reported. For the purposes of
moving EROFS into the kernel proper, chances are that will be good enough.
Unless some other show-stopping issue comes up, this little snag seems
unlikely to keep this code from graduating out of the staging tree. Future
filesystem developers will want to take notice, though, that reviewers will
be paying more attention to robustness against on-disk image corruption
than they have in the past.
| Index entries for this article | |
|---|---|
| Kernel | Filesystems |