On 6/14/23 08:26, Christoph Hellwig wrote: > Subject: > Re: [PATCH v5 04/11] blksnap: header file of the module interface > From: > Christoph Hellwig <hch@xxxxxxxxxxxxx> > Date: > 6/14/23, 08:26 > > To: > Dave Chinner <david@xxxxxxxxxxxxx> > CC: > Sergei Shtepa <sergei.shtepa@xxxxxxxxx>, axboe@xxxxxxxxx, hch@xxxxxxxxxxxxx, corbet@xxxxxxx, snitzer@xxxxxxxxxx, viro@xxxxxxxxxxxxxxxxxx, brauner@xxxxxxxxxx, dchinner@xxxxxxxxxx, willy@xxxxxxxxxxxxx, dlemoal@xxxxxxxxxx, linux@xxxxxxxxxxxxxx, jack@xxxxxxx, ming.lei@xxxxxxxxxx, linux-block@xxxxxxxxxxxxxxx, linux-doc@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, Donald Buczek <buczek@xxxxxxxxxxxxx> > > > On Wed, Jun 14, 2023 at 08:25:15AM +1000, Dave Chinner wrote: >>> + * Return: 0 if succeeded, negative errno otherwise. >>> + */ >>> +#define IOCTL_BLKSNAP_SNAPSHOT_APPEND_STORAGE \ >>> + _IOW(BLKSNAP, blksnap_ioctl_snapshot_append_storage, \ >>> + struct blksnap_snapshot_append_storage) >> That's an API I'm extremely uncomfortable with. We've learnt the >> lesson *many times* that userspace physical mappings of underlying >> file storage are unreliable. >> >> i.e. This is reliant on userspace telling the kernel the physical >> mapping of the filesystem file to block device LBA space and then >> providing a guarantee (somehow) that the mapping will always remain >> unchanged. i.e. It's reliant on passing FIEMAP data from the >> filesystem to userspace and then back into the kernel without it >> becoming stale and somehow providing a guarantee that nothing (not >> even the filesystem doing internal garbage collection) will change >> it. > Hmm, I never thought of this API as used on files that somewhere > had a logical to physical mapping applied to them. > > Sergey, is that the indtended use case? If so we really should > be going through the file system using direct I/O. > Hi! Thank you, Dave, for such a detailed comment. Yes, everything is really as you described. This code worked quite successfully for the veeamsnap module, on the basis of which blksnap was created. Indeed, such an allocation of an area on a block device using a file does not look safe. We've already discussed this with Donald Buczek <buczek@xxxxxxxxxxxxx>. Link: https://github.com/veeam/blksnap/issues/57#issuecomment-1576569075 And I have planned work on moving to a more secure ioctl in the future. Link: https://github.com/veeam/blksnap/issues/61 Now, thanks to Dave, it becomes clear to me how to solve this problem best. swapfile is a good example of how to do it right. Fixing this vulnerability will entail transferring the algorithm for allocating the difference storage from the user-space to the blksnap code. The changes are quite significant. The UAPI will be changed. So I agree that the blksnap module is not good enough for upstream yet.
