Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]

On Wed, Mar 16 2016, Theodore Ts'o wrote:

> On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote:
>> 
>> Stale data escaping containment is a security issue. Enabling
>> generic kernel mechanisms to *enable containment escape* is
>> fundamentally wrong, and relying on userspace to Do The Right Thing
>> is even more of a gamble, IMO.
>
> We already have generic kernel mechanisms such as "the block device".   P

This is a bit of an 'off-the-wall' suggestion, but I agree that these
things that might be of value to user-space file servers do seem a lot
like block devices.  So why not make them look exactly like block
devices?

i.e. a new open flag O_BLOCKDEV which, when combined with O_CREAT
creates a thing that is managed in the filesystem much like a file, but
that appears to user-space like a block device.  The major/minor numbers
would be essentially meaningless - the filesystem wouldn't call
init_special_inode() like it does on normal block devices, it would
retain control itself.

That would make the content invisible to backups and rsync and all the
things that Dave has raised as potential concerns.  And it would be no
surprise if the contents included stale data because that is exactly
what you get when you create a new logical volume with LVM2.

The block device would initially be of size zero, but could be resized
using fallocate (which soon will work on block devices), which can
request zeros, leave holes, or with Teds new FALLOC flag (that would only
be permitted on block devices) could allocate uninitialized space.

Rules for using O_BLOCKDEV would still need to be clarified - mount
option, access to underlying block device, CAP_MKNOD .. whatever.

I think that being able to use a filesystem as a logical volume manager
is an extremely interesting idea.... we might even end up with a
filesystem interface on device-mapper :-)

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]