mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: christian.melki@t2data.com
Cc: "ptxdist@pengutronix.de" <ptxdist@pengutronix.de>
Subject: Re: [ptxdist] [PATCH] util-linux: add option for building blkdiscard
Date: Thu, 23 Jan 2025 23:02:26 +0100	[thread overview]
Message-ID: <ed05f1ca-3188-45f6-a028-fb784e6ee8a4@pengutronix.de> (raw)
In-Reply-To: <9872fef0-f5c6-41cb-894e-b67e884492a8@t2data.com>

Hello Christian,

On 23.01.25 22:55, Christian Melki wrote:
> On 1/23/25 9:54 PM, Ahmad Fatoum wrote:
>> We currently only have an option for BusyBox blkdiscard, but that one
>> lacks some options like -z for zeroing the block device.
>>
>> This can be important as regular discard on an eMMC isn't guaranteed
>> to clear data.
>>
>> Add a util-linux blkdiscard option to address this.
>>
> 
> Zeroing is certainly not guaranteed to do anything useful either to the
> physical media. A normal FTL getting a full block zero will only move
> the read index for that LBA to some zeroed return block index and do
> nothing else (fast zeroed read, with no read perturbation from real media).
> Depending on how one views the discarded blocks, it might also put the
> zeroed block on the discard list anyway.
> If you still can read real data from a zeroed (reindexed) or discarded
> block you have other security issues with the device.
> Having lower level access to the device with intentional holes isn't
> going to protect you from leaking by anything, including key changes to
> some transparent AES-XTS blocks.
> If you mistrust the device, your best bet is going to be forcing fast
> prng data on all accessible blocks, including whatever sideband blocks
> you can get at. With no reusage between blocks, the drive won't have any
> other choice than to write over data. It's slow though.
> Smart drives will see various reoccuring fill patterns and create fast
> read indexes for those too.

My particular need for blkdiscard -z is not for mangling key material.
I just want to clear the block device, so software that checks for partition
magic doesn't see stale data. I am aware that this is no substitute for
a blkdiscard -s (which busybox also supports) or randomized overwrite,
but this is beyond what I need.

Thanks,
Ahmad

> 
> regards,
> Christian
> 
>> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> ---
>>  rules/util-linux.in   | 10 ++++++++++
>>  rules/util-linux.make |  3 ++-
>>  2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/rules/util-linux.in b/rules/util-linux.in
>> index 8bf035f3901e..83e075852689 100644
>> --- a/rules/util-linux.in
>> +++ b/rules/util-linux.in
>> @@ -62,6 +62,16 @@ config UTIL_LINUX_ADDPART
>>  	help
>>  	  The addpart utility.
>>  
>> +config UTIL_LINUX_BLKDISCARD
>> +	bool
>> +	depends on !BUSYBOX_BLKDISCARD || ALLYES
>> +	prompt "blkdiscard"
>> +	help
>> +	  blkdiscard is used to discard device sectors.
>> +
>> +comment "BusyBox' blkdiscard is selected!"
>> +	depends on BUSYBOX_BLKDISCARD
>> +
>>  config UTIL_LINUX_CFDISK
>>  	bool
>>  	select UTIL_LINUX_FDISKS
>> diff --git a/rules/util-linux.make b/rules/util-linux.make
>> index 579c165e6edb..02d83715c6f1 100644
>> --- a/rules/util-linux.make
>> +++ b/rules/util-linux.make
>> @@ -54,7 +54,7 @@ UTIL_LINUX_CONF_OPT	:= \
>>  	-Dbuild-agetty=$(call ptx/endis, PTXCONF_UTIL_LINUX_AGETTY)d \
>>  	-Dbuild-bash-completion=disabled \
>>  	-Dbuild-bfs=disabled \
>> -	-Dbuild-blkdiscard=disabled \
>> +	-Dbuild-blkdiscard=$(call ptx/endis, PTXCONF_UTIL_LINUX_BLKDISCARD)d \
>>  	-Dbuild-blkpr=disabled \
>>  	-Dbuild-blkzone=disabled \
>>  	-Dbuild-blockdev=disabled \
>> @@ -197,6 +197,7 @@ UTIL_LINUX_LIB-$(PTXCONF_UTIL_LINUX_LIBFDISK)		+= fdisk
>>  
>>  # disk-utils
>>  UTIL_LINUX_BIN-$(PTXCONF_UTIL_LINUX_ADDPART)		+= sbin/addpart
>> +UTIL_LINUX_BIN-$(PTXCONF_UTIL_LINUX_BLKDISCARD)		+= sbin/blkdiscard
>>  UTIL_LINUX_BIN-$(PTXCONF_UTIL_LINUX_CFDISK)		+= sbin/cfdisk
>>  UTIL_LINUX_BIN-$(PTXCONF_UTIL_LINUX_DELPART)		+= sbin/delpart
>>  UTIL_LINUX_BIN-$(PTXCONF_UTIL_LINUX_RESIZEPART)		+= sbin/resizepart
> 
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



  reply	other threads:[~2025-01-23 22:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-23 20:54 Ahmad Fatoum
2025-01-23 21:55 ` Christian Melki
2025-01-23 22:02   ` Ahmad Fatoum [this message]
2025-01-27  8:35 ` [ptxdist] [APPLIED] " Michael Olbrich
2025-01-27 10:46   ` Michael Olbrich

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=ed05f1ca-3188-45f6-a028-fb784e6ee8a4@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=christian.melki@t2data.com \
    --cc=ptxdist@pengutronix.de \
    /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