On 25 Sep 2019, at 8:07, Colin Walters wrote: > On Wed, Sep 25, 2019, at 3:11 AM, Dave Chinner wrote: >> >> We're talking about user data read/write access here, not some >> special security capability. Access to the data has already been >> permission checked, so why should the format that the data is >> supplied to the kernel in suddenly require new privilege checks? > > What happens with BTRFS today if userspace provides invalid compressed > data via this interface? Does that show up as filesystem corruption > later? If the data is verified at write time, wouldn't that be losing > most of the speed advantages of providing pre-compressed data? The data is verified while being decompressed, but that's a fairly large fuzzing surface (all of zstd, zlib, and lzo). A lot of people will correctly argue that we already have that fuzzing surface today, but I'd rather not make a really easy way to stuff arbitrary bytes through the kernel decompression code until all the projects involved sign off. -chris
