lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 12 Mar 2012 15:30:53 +0200
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	Joel Reardon <joel@...mbassador.com>
Cc:	linux-mtd@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] Adding Secure Deletion to UBIFS

On Fri, 2012-03-09 at 20:29 +0100, Joel Reardon wrote:
> To me, being able to set secure erase or not as a partition level setting
> makes alot of sense. The OS partition does not need it, but the user file data
> partition will have it, and UBI makes sense that wear levelling is done
> among all the partitions properly. Then taint status for files'
> sensitivity doesn't need to be maintained. The deployer simply chooses for
> this part of the FS, do they want secure deletion over the data or not,
> one time at the beginning. (Compare this to the decision on whether or
> not to encrypt their entire partition or later encrypting each file they
> make.)

Well, it makes sense. I do not insist on having a separate interface for
secure deletion. But duplication of the same information in the B-tree
slots and the data nodes the slots point to does not make much sense to
me.

I mostly look at this from the maintainability and upstreamability POW
and I see that despite on the clever ideas the changes broke backward
compatibility, patches are big and intrusive. From my point of view -
contributors come and go but I keep maintaining this beast :-)

> I'll remove the change to tree branch, and repost correctly the
> version change where only data node is effected.

But please, keep in mind my motivations and ensure that what I suggest
makes sense from your POW!

>  Btw, when I was
> developing it I used the last 8 bytes from the key as the key position,
> because the key was 16 bytes but only 8 were used. Could you comment on
> the last 8 bytes of ubifs keys?

I think you can use them. But is it possible to kill these things from
the data nodes themselves? We can always find it by looking up the index
by the data node key, right?

-- 
Best Regards,
Artem Bityutskiy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ