From: Denis Semakin <d.semakin@omprussia.ru>
To: snitzer <snitzer@redhat.com>
Cc: dm-devel <dm-devel@redhat.com>
Subject: Re: [PATCH] dm table: add support for secure erase forwarding [was: Re: Adaptation secure erase forwarding for 4.1x kernels]
Date: Fri, 23 Mar 2018 18:24:42 +0300 (MSK) [thread overview]
Message-ID: <582342829.319960.1521818682384.JavaMail.zimbra@omprussia.ru> (raw)
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.
>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.
>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.
>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.
Hopefully, I answered to all your question.
Denis
next reply other threads:[~2018-03-23 15:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-23 15:24 Denis Semakin [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-03-23 15:25 [PATCH] dm table: add support for secure erase forwarding [was: Re: Adaptation secure erase forwarding for 4.1x kernels] Denis Semakin
2018-03-23 15:25 Denis Semakin
2018-03-13 9:23 [PATCH] Adaptation secure erase forwarding for 4.1x kernels Denis Semakin
2018-03-22 15:10 ` [PATCH] dm table: add support for secure erase forwarding [was: Re: Adaptation secure erase forwarding for 4.1x kernels] Mike Snitzer
2018-03-23 8:14 ` Denis Semakin
2018-03-23 13:37 ` Denis Semakin
2018-03-23 14:47 ` Denis Semakin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=582342829.319960.1521818682384.JavaMail.zimbra@omprussia.ru \
--to=d.semakin@omprussia.ru \
--cc=dm-devel@redhat.com \
--cc=snitzer@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox