On 2019/8/20 16:46, Qu Wenruo wrote:
> [...]
>>
>> Yeah, it looks like we need searching more levels mapping to find the final
>> physical block address of inode/node/data in btrfs.
>>
>> IMO, in a little lazy way, we can reform and reuse existed function in
>> btrfs-progs which can find the
On 2019/8/21 9:48, Darrick J. Wong wrote:
> On Wed, Aug 21, 2019 at 09:34:02AM +0800, Chao Yu wrote:
>> On 2019/8/20 23:56, Theodore Y. Ts'o wrote:
>>> The reason why there needs to be at least some file system specific
>>> code for fuzz testing is because for efficiency's sake, you don't want
>>>
On Wed, Aug 21, 2019 at 09:34:02AM +0800, Chao Yu wrote:
> On 2019/8/20 23:56, Theodore Y. Ts'o wrote:
> > The reason why there needs to be at least some file system specific
> > code for fuzz testing is because for efficiency's sake, you don't want
> > to fuzz every single bit in the file system,
On 2019/8/20 23:56, Theodore Y. Ts'o wrote:
> The reason why there needs to be at least some file system specific
> code for fuzz testing is because for efficiency's sake, you don't want
> to fuzz every single bit in the file system, but just the ones which
> are most interesting (e.g., the
On Wed, Aug 21, 2019 at 12:35:08AM +0800, Gao Xiang wrote:
>
> For EROFS, it's a special case since it is a RO fs, and erofs mkfs
> will generate reproducable images (which means, for one dir trees,
> it only generates exact one result except for build time).
Agreed, and given that, doing the
Hi Ted,
On Tue, Aug 20, 2019 at 11:56:23AM -0400, Theodore Y. Ts'o wrote:
> On Tue, Aug 20, 2019 at 10:24:11AM +0800, Chao Yu wrote:
> > Out of curiosity, it looks like every mainstream filesystem has its own
> > fuzz/injection tool in their tool-set, if it's really such a generic
> >
On Tue, Aug 20, 2019 at 10:24:11AM +0800, Chao Yu wrote:
> Out of curiosity, it looks like every mainstream filesystem has its own
> fuzz/injection tool in their tool-set, if it's really such a generic
> requirement, why shouldn't there be a common tool to handle that, let
> specified
>
[...]
>
> Yeah, it looks like we need searching more levels mapping to find the final
> physical block address of inode/node/data in btrfs.
>
> IMO, in a little lazy way, we can reform and reuse existed function in
> btrfs-progs which can find the mapping info of inode/node/data according to
>
On 2019/8/20 10:38, Qu Wenruo wrote:
>
>
> On 2019/8/20 上午10:24, Chao Yu wrote:
>> On 2019/8/20 8:55, Qu Wenruo wrote:
>>> [...]
>> I have made a simple fuzzer to inject messy in inode metadata,
>> dir data, compressed indexes and super block,
>>
Hi Qu,
On Tue, Aug 20, 2019 at 02:04:46PM +0800, Qu Wenruo wrote:
> [...]
>
> And performance is another point.
> That tree-checker in btrfs is as fast/slow as CRC32.
> Not sure how it would be for dm-verity, but I guess it's slower than
> CRC32 if using any strong hash.
Just a word, dm-verity
[...]
>> The same tool exists for btrfs, although lacks the write ability, but
>> that dump is more comprehensive and a great tool to learn the on-disk
>> format.
>>
>>
>> And for the fuzzing defending part, just a few kernel releases ago,
>> there is none for btrfs, and now we have a full static
On Tue, Aug 20, 2019 at 11:33:51AM +0800, Miao Xie wrote:
>
>
> on 2019/8/20 at 8:55, Qu Wenruo wrote:
> > [...]
> I have made a simple fuzzer to inject messy in inode metadata,
> dir data, compressed indexes and super block,
>
on 2019/8/20 at 8:55, Qu Wenruo wrote:
> [...]
I have made a simple fuzzer to inject messy in inode metadata,
dir data, compressed indexes and super block,
https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?h=experimental-fuzzer
I am testing
On 2019/8/20 上午10:24, Chao Yu wrote:
> On 2019/8/20 8:55, Qu Wenruo wrote:
>> [...]
> I have made a simple fuzzer to inject messy in inode metadata,
> dir data, compressed indexes and super block,
>
On 2019/8/20 8:55, Qu Wenruo wrote:
> [...]
I have made a simple fuzzer to inject messy in inode metadata,
dir data, compressed indexes and super block,
https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?h=experimental-fuzzer
I am testing with
Hi Qu,
On Tue, Aug 20, 2019 at 08:55:32AM +0800, Qu Wenruo wrote:
> [...]
> >>> I have made a simple fuzzer to inject messy in inode metadata,
> >>> dir data, compressed indexes and super block,
> >>>
[...]
>>> I have made a simple fuzzer to inject messy in inode metadata,
>>> dir data, compressed indexes and super block,
>>> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?h=experimental-fuzzer
>>>
>>> I am testing with some given dirs and the following script.
>>>
Hi Darrick,
On Mon, Aug 19, 2019 at 09:09:23AM -0700, Darrick J. Wong wrote:
> On Mon, Aug 19, 2019 at 04:14:11AM +0800, Gao Xiang wrote:
> > Hi all,
> >
> > On Mon, Aug 19, 2019 at 02:16:55AM +0800, Gao Xiang wrote:
> > > Hi Hch,
> > >
> > > On Sun, Aug 18, 2019 at 10:47:02AM -0700, Christoph
On Mon, Aug 19, 2019 at 04:14:11AM +0800, Gao Xiang wrote:
> Hi all,
>
> On Mon, Aug 19, 2019 at 02:16:55AM +0800, Gao Xiang wrote:
> > Hi Hch,
> >
> > On Sun, Aug 18, 2019 at 10:47:02AM -0700, Christoph Hellwig wrote:
> > > On Sun, Aug 18, 2019 at 10:29:38AM -0700, Eric Biggers wrote:
> > > >
Hi Richard,
On Mon, Aug 19, 2019 at 09:35:43AM +0200, Richard Weinberger wrote:
> - Ursprüngliche Mail -
> > I have made a simple fuzzer to inject messy in inode metadata,
> > dir data, compressed indexes and super block,
> >
- Ursprüngliche Mail -
> On Sun, Aug 18, 2019 at 10:29:38AM -0700, Eric Biggers wrote:
>> Not sure what you're even disagreeing with, as I *do* expect new filesystems
>> to
>> be held to a high standard, and to be written with the assumption that the
>> on-disk data may be corrupted or
- Ursprüngliche Mail -
> I have made a simple fuzzer to inject messy in inode metadata,
> dir data, compressed indexes and super block,
> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?h=experimental-fuzzer
>
> I am testing with some given dirs and the
Hi all,
On Mon, Aug 19, 2019 at 02:16:55AM +0800, Gao Xiang wrote:
> Hi Hch,
>
> On Sun, Aug 18, 2019 at 10:47:02AM -0700, Christoph Hellwig wrote:
> > On Sun, Aug 18, 2019 at 10:29:38AM -0700, Eric Biggers wrote:
> > > Not sure what you're even disagreeing with, as I *do* expect new
> > >
> "linux-erofs" , "Al Viro"
> > , "Jaegeuk Kim" ,
> > "linux-kernel" , "Li Guifu"
> > , "Fang Wei" ,
> > "Pavel Machek" , "linux-fsdevel"
> > , "Andrew Morton"
> > , &
Hi Hch,
On Sun, Aug 18, 2019 at 10:47:02AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 10:29:38AM -0700, Eric Biggers wrote:
> > Not sure what you're even disagreeing with, as I *do* expect new
> > filesystems to
> > be held to a high standard, and to be written with the assumption
t; , "devel" , "Stephen
> Rothwell" , "Darrick"
> , "Christoph Hellwig" , "Amir
> Goldstein" ,
> "linux-erofs" , "Al Viro"
> , "Jaegeuk Kim" ,
> "linux-kernel" , "Li Guifu"
>
On Sun, Aug 18, 2019 at 10:29:38AM -0700, Eric Biggers wrote:
> Not sure what you're even disagreeing with, as I *do* expect new filesystems
> to
> be held to a high standard, and to be written with the assumption that the
> on-disk data may be corrupted or malicious. We just can't expect the
On Sun, Aug 18, 2019 at 07:06:40PM +0200, Richard Weinberger wrote:
> > So holding a file system like EROFS to a higher standard than say,
> > ext4, xfs, or btrfs hardly seems fair.
>
> Nobody claimed that.
Pointing out that erofs has issues in this area when Gao Xiang is
asking if erofs can be
On Sun, Aug 18, 2019 at 08:58:12AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote:
> > Note that of the mainstream file systems, ext4 and xfs don't guarantee
> > that it's safe to blindly take maliciously provided file systems, such
> > as those
On Sun, Aug 18, 2019 at 09:22:01AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote:
> > Ted's observation was about maliciously-crafted filesystems, though, so
> > integrity-only features such as metadata checksums are irrelevant. Also the
> >
- Ursprüngliche Mail -
> So holding a file system like EROFS to a higher standard than say,
> ext4, xfs, or btrfs hardly seems fair.
Nobody claimed that.
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
Hi Hch,
On Sun, Aug 18, 2019 at 09:22:01AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote:
> > Ted's observation was about maliciously-crafted filesystems, though, so
> > integrity-only features such as metadata checksums are irrelevant. Also the
>
On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote:
> Ted's observation was about maliciously-crafted filesystems, though, so
> integrity-only features such as metadata checksums are irrelevant. Also the
> filesystem version is irrelevant; anything accepted by the kernel code (even
>
On Sun, Aug 18, 2019 at 08:58:12AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote:
> > Note that of the mainstream file systems, ext4 and xfs don't guarantee
> > that it's safe to blindly take maliciously provided file systems, such
> > as those
Hi Ted,
On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote:
> On Sun, Aug 18, 2019 at 11:21:13AM +0200, Richard Weinberger wrote:
> > > Not to say that erofs shouldn't be worked on to fix these kinds of
> > > issues, just that it's not an unheard of thing to trust the disk image.
>
On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote:
> Note that of the mainstream file systems, ext4 and xfs don't guarantee
> that it's safe to blindly take maliciously provided file systems, such
> as those provided by a untrusted container, and mount it on a file
> system without
On Sun, Aug 18, 2019 at 11:21:13AM +0200, Richard Weinberger wrote:
> > Not to say that erofs shouldn't be worked on to fix these kinds of
> > issues, just that it's not an unheard of thing to trust the disk image.
> > Especially for the normal usage model of erofs, where the whole disk
> > image
Hi Richard,
On 2019-8-18 17:21, Richard Weinberger wrote:
> For normal use I see no problem at all.
> I fear distros that try to mount anything you plug into your USB.
>
> At least SUSE already blacklists erofs:
>
On Sun, Aug 18, 2019 at 11:03:53AM +0200, Richard Weinberger wrote:
> - Urspr??ngliche Mail -
> > I agree with you, but what can we do now is trying our best to fuzz
> > all the fields.
> >
> > So, what is your opinion about EROFS?
>
> All I'm saying is that you should not blindly trust
- Ursprüngliche Mail -
> You have looked at reiserfs lately, right? :)
Don't remind me of that. ;-)
> Not to say that erofs shouldn't be worked on to fix these kinds of
> issues, just that it's not an unheard of thing to trust the disk image.
> Especially for the normal usage model of
On Sun, Aug 18, 2019 at 11:03:53AM +0200, Richard Weinberger wrote:
> - Ursprüngliche Mail -
> > I agree with you, but what can we do now is trying our best to fuzz
> > all the fields.
> >
> > So, what is your opinion about EROFS?
>
> All I'm saying is that you should not blindly trust
- Ursprüngliche Mail -
> I agree with you, but what can we do now is trying our best to fuzz
> all the fields.
>
> So, what is your opinion about EROFS?
All I'm saying is that you should not blindly trust the disk.
Another thing that raises my attention is in superblock_read():
On Sun, Aug 18, 2019 at 10:16:50AM +0200, Richard Weinberger wrote:
> - Urspr?ngliche Mail -
> >> While digging a little into the code I noticed that you have very few
> >> checks of the on-disk data.
> >> For example ->u.i_blkaddr. I gave it a try and created a
> >> malformed filesystem
- Ursprüngliche Mail -
>> While digging a little into the code I noticed that you have very few
>> checks of the on-disk data.
>> For example ->u.i_blkaddr. I gave it a try and created a
>> malformed filesystem where u.i_blkaddr is 0xdeadbeef, it causes the kernel
>> to loop forever around
On Sun, Aug 18, 2019 at 08:04:11AM +0800, Gao Xiang wrote:
> On Sun, Aug 18, 2019 at 07:38:47AM +0800, Gao Xiang wrote:
> > Hi Richard,
> >
> > On Sun, Aug 18, 2019 at 01:25:58AM +0200, Richard Weinberger wrote:
>
> []
>
> > >
> > > While digging a little into the code I noticed that you have
On Sun, Aug 18, 2019 at 07:38:47AM +0800, Gao Xiang wrote:
> Hi Richard,
>
> On Sun, Aug 18, 2019 at 01:25:58AM +0200, Richard Weinberger wrote:
[]
> >
> > While digging a little into the code I noticed that you have very few
> > checks of the on-disk data.
> > For example ->u.i_blkaddr. I
Hi Richard,
On Sun, Aug 18, 2019 at 01:25:58AM +0200, Richard Weinberger wrote:
> - Urspr?ngliche Mail -
> >> How does erofs compare to squashfs?
> >> IIUC it is designed to be faster. Do you have numbers?
> >> Feel free to point me older mails if you already showed numbers,
> >> I have
- Ursprüngliche Mail -
>> How does erofs compare to squashfs?
>> IIUC it is designed to be faster. Do you have numbers?
>> Feel free to point me older mails if you already showed numbers,
>> I have to admit I didn't follow the development very closely.
>
> You can see the following
Hi Richard,
On Sat, Aug 17, 2019 at 11:19:50PM +0200, Richard Weinberger wrote:
> - Urspr?ngliche Mail -
> > Von: "Gao Xiang"
> > An: "Greg Kroah-Hartman" , "Al Viro"
> > , "linux-fsdevel"
> > , de...@driverdev.osuosl.org,
> > linux-er...@lists.ozlabs.org, "linux-kernel"
> >
> > CC:
- Ursprüngliche Mail -
> Von: "Gao Xiang"
> An: "Greg Kroah-Hartman" , "Al Viro"
> , "linux-fsdevel"
> , de...@driverdev.osuosl.org,
> linux-er...@lists.ozlabs.org, "linux-kernel"
>
> CC: "Andrew Morton" , "Stephen Rothwell"
> , "tytso" ,
> "Pavel Machek" , "David Sterba" , "Amir
>
50 matches
Mail list logo
