[dm-devel] dm table: add support for secure erase forwarding [was: Re: Adaptation secure erase forwarding for 4.1x kernels]
Mike Snitzer
snitzer at redhat.com
Fri Mar 23 15:36:24 UTC 2018
On Fri, Mar 23 2018 at 4:14am -0400,
Denis Semakin <d.semakin at omprussia.ru> wrote:
> Hi.
> Soon or later everybody start to think about security.
> One of the most frequently requirement is 100% reliable data deletion from
> any device in case of compromising or loss or theft.
>
> For this, drive and memory cards manufacturers provide ERASE and TRIM features
> which can notice (inform) controller of the device to erase sectors
> (write down only zeros or one or random data). Features can be triggered
> by calling ioctl() requests or a mount options (like ext4 does). But this works
> only with whole device -- /dev/sdX, /dev/mmcblk0pX...
> But what if for some security reasons we need to secure delete a single file.
> A file-system layer provide this functionality... one may call __blkdev_issue_discard()
> with BLKDEV_DISCARD_SECURE flag.
> But...
> All this works well if there is no virtual layer (like device-mapper)
> between file-system and block-layer, because if device driver supports
> this feature it can set up related flag in request_queue flags.
>
> I have ext4 lvm partitions on my test instance and a drive which can
> secure erase sectors.
> Without lvm it works, with lvm it doesn't.
> That's the purpose if this patch - to provide the opportunity to secure erase
> given sectors (through device-mapper layer, forward request) that were assigned for regular file.
I was aware of all that. I understand that DM currently isn't setting
the QUEUE_FLAG_SECERASE, etc.
> >But I'm left skeptical that this is enough. Don't targets need to
> >explicitly handle these REQ_OP_SECURE_ERASE requests? Similar to how
> >REQ_OP_DISCARD is handled?
>
> I think yes, REQ_OP_DISCARD will not secure erase the data and it can be possible
> to get it from device.
Think you misunderstood me.
I meant that: DM must take special care to properly handle
REQ_OP_DISCARD. Particularly more complex targets like thinp, etc.
But even more basic targets (e.g. dm-stripe.c) have code to optimize
handling of REQ_OP_DISCARD. We'd likely want REQ_OP_SECURE_ERASE to be
using dm-stripe.c's REQ_OP_DISCARD optimization too.
> >I'd feel safer about having targets opt-in with setting (a new)
> >ti->num_secure_erase_bios.
>
> Well... May it make sense but I didn't see any reasons to add it in patch.
Thinking further, it is absolutely needed, otherwise dm-stripe.c won't
be able to use the optimization I mentioned above. In addition, other
targets shouldn't be getting REQ_OP_SECURE_ERASE unless there is a real
need. ti->num_secure_erase_bios will allow for a much safer and
controlled rollout of this support.
> >Which DM target(s) have you been wanting to pass REQ_OP_SECURE_ERASE
> >bios?
> I think first of all a linear target of course should have this. For others I'm not sure, I need
> to investigate.
I think "linear" and "striped" would be the ideal first targets to add
this support to.
I can work through adding the other changes at some point soon.
Mike
More information about the dm-devel
mailing list