* secure file deletion/SECRM support for JFFS2 and UBIFS
@ 2016-04-27 5:07 Chris Packham
2016-04-27 7:05 ` Richard Weinberger
0 siblings, 1 reply; 9+ messages in thread
From: Chris Packham @ 2016-04-27 5:07 UTC (permalink / raw)
To: linux-mtd; +Cc: Henry Shen
Hi,
We have a customer request for "secure file deletion" for our embedded
devices (kernel version 4.4.6). The first device is running JFFS2 on
parallel NOR flash but we expect to see the same requirement pop up on
our newer devices running UBIFS on top of NAND.
I found a couple of old threads related to UBIFS but they all appear to
have fallen silent. Nothing really for JFFS2.
For our application we're not really concerned about defeating
determined attackers who have access to the device and hardware that can
do detailed analysis on the transistors that make up the chip. But we
are trying to protect against casual attackers (or recipients of
re-furbished hardware) who can run 'dd'.
So I think for us it'd be enough to implement chattr +s and have the
file's data over written with a fixed value (e.g 0 for NOR flash) when
it's blocks are added to the garbage collection list.
Is that something people on this list would be interested in? I realize
JFFS2 is kind of in a twilight phase but we're really not able to
migrate some customers away from it.
Thanks,
Chris
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: secure file deletion/SECRM support for JFFS2 and UBIFS
2016-04-27 5:07 secure file deletion/SECRM support for JFFS2 and UBIFS Chris Packham
@ 2016-04-27 7:05 ` Richard Weinberger
2016-04-27 7:05 ` Richard Weinberger
0 siblings, 1 reply; 9+ messages in thread
From: Richard Weinberger @ 2016-04-27 7:05 UTC (permalink / raw)
To: Chris Packham; +Cc: linux-mtd, Henry Shen
Chris,
On Wed, Apr 27, 2016 at 7:07 AM, Chris Packham
<Chris.Packham@alliedtelesis.co.nz> wrote:
> Hi,
>
> We have a customer request for "secure file deletion" for our embedded
> devices (kernel version 4.4.6). The first device is running JFFS2 on
> parallel NOR flash but we expect to see the same requirement pop up on
> our newer devices running UBIFS on top of NAND.
>
> I found a couple of old threads related to UBIFS but they all appear to
> have fallen silent. Nothing really for JFFS2.
>
> For our application we're not really concerned about defeating
> determined attackers who have access to the device and hardware that can
> do detailed analysis on the transistors that make up the chip. But we
> are trying to protect against casual attackers (or recipients of
> re-furbished hardware) who can run 'dd'.
>
> So I think for us it'd be enough to implement chattr +s and have the
> file's data over written with a fixed value (e.g 0 for NOR flash) when
> it's blocks are added to the garbage collection list.
>
> Is that something people on this list would be interested in? I realize
> JFFS2 is kind of in a twilight phase but we're really not able to
> migrate some customers away from it.
This is definitely a nice feature.
But please keep in mind that you can overwrite data on flash. :-)
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: secure file deletion/SECRM support for JFFS2 and UBIFS
2016-04-27 7:05 ` Richard Weinberger
@ 2016-04-27 7:05 ` Richard Weinberger
2016-04-27 21:49 ` Chris Packham
0 siblings, 1 reply; 9+ messages in thread
From: Richard Weinberger @ 2016-04-27 7:05 UTC (permalink / raw)
To: Chris Packham; +Cc: linux-mtd, Henry Shen
On Wed, Apr 27, 2016 at 9:05 AM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
>> Is that something people on this list would be interested in? I realize
>> JFFS2 is kind of in a twilight phase but we're really not able to
>> migrate some customers away from it.
>
> This is definitely a nice feature.
> But please keep in mind that you can overwrite data on flash. :-)
Should be read "can't", of course...
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: secure file deletion/SECRM support for JFFS2 and UBIFS
2016-04-27 7:05 ` Richard Weinberger
@ 2016-04-27 21:49 ` Chris Packham
2016-04-27 21:55 ` Richard Weinberger
0 siblings, 1 reply; 9+ messages in thread
From: Chris Packham @ 2016-04-27 21:49 UTC (permalink / raw)
To: Richard Weinberger; +Cc: linux-mtd, Henry Shen
On 04/27/2016 07:06 PM, Richard Weinberger wrote:
> On Wed, Apr 27, 2016 at 9:05 AM, Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
>>> Is that something people on this list would be interested in? I realize
>>> JFFS2 is kind of in a twilight phase but we're really not able to
>>> migrate some customers away from it.
>>
>> This is definitely a nice feature.
>> But please keep in mind that you can overwrite data on flash. :-)
>
> Should be read "can't", of course...
>
You can't overwrite with arbitrary data. But for NOR flash at least you
_can_ overwrite with 0 (at least I think you can). In other words if the
erased state is 0xff you can write 0xaa you would not be able to write
0x55 without erasing the block first but you would be able to write 0x00.
I was hoping to avoid having to do an immediate erase but if I'm wrong
that's what we'd have to do.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: secure file deletion/SECRM support for JFFS2 and UBIFS
2016-04-27 21:49 ` Chris Packham
@ 2016-04-27 21:55 ` Richard Weinberger
2016-04-27 22:35 ` Chris Packham
0 siblings, 1 reply; 9+ messages in thread
From: Richard Weinberger @ 2016-04-27 21:55 UTC (permalink / raw)
To: Chris Packham; +Cc: linux-mtd, Henry Shen
Am 27.04.2016 um 23:49 schrieb Chris Packham:
> On 04/27/2016 07:06 PM, Richard Weinberger wrote:
>> On Wed, Apr 27, 2016 at 9:05 AM, Richard Weinberger
>> <richard.weinberger@gmail.com> wrote:
>>>> Is that something people on this list would be interested in? I realize
>>>> JFFS2 is kind of in a twilight phase but we're really not able to
>>>> migrate some customers away from it.
>>>
>>> This is definitely a nice feature.
>>> But please keep in mind that you can overwrite data on flash. :-)
>>
>> Should be read "can't", of course...
>>
>
> You can't overwrite with arbitrary data. But for NOR flash at least you
> _can_ overwrite with 0 (at least I think you can). In other words if the
> erased state is 0xff you can write 0xaa you would not be able to write
> 0x55 without erasing the block first but you would be able to write 0x00.
>
> I was hoping to avoid having to do an immediate erase but if I'm wrong
> that's what we'd have to do.
Well, UBIFS and JFFS2 work on generic MTD, so having a special hack for NOR
is not really what we want.
Thanks,
//richard
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: secure file deletion/SECRM support for JFFS2 and UBIFS
2016-04-27 21:55 ` Richard Weinberger
@ 2016-04-27 22:35 ` Chris Packham
2016-04-28 7:27 ` Richard Weinberger
0 siblings, 1 reply; 9+ messages in thread
From: Chris Packham @ 2016-04-27 22:35 UTC (permalink / raw)
To: Richard Weinberger; +Cc: linux-mtd, Henry Shen
On 04/28/2016 09:55 AM, Richard Weinberger wrote:
> Am 27.04.2016 um 23:49 schrieb Chris Packham:
>> On 04/27/2016 07:06 PM, Richard Weinberger wrote:
>>> On Wed, Apr 27, 2016 at 9:05 AM, Richard Weinberger
>>> <richard.weinberger@gmail.com> wrote:
>>>>> Is that something people on this list would be interested in? I realize
>>>>> JFFS2 is kind of in a twilight phase but we're really not able to
>>>>> migrate some customers away from it.
>>>>
>>>> This is definitely a nice feature.
>>>> But please keep in mind that you can overwrite data on flash. :-)
>>>
>>> Should be read "can't", of course...
>>>
>>
>> You can't overwrite with arbitrary data. But for NOR flash at least you
>> _can_ overwrite with 0 (at least I think you can). In other words if the
>> erased state is 0xff you can write 0xaa you would not be able to write
>> 0x55 without erasing the block first but you would be able to write 0x00.
>>
>> I was hoping to avoid having to do an immediate erase but if I'm wrong
>> that's what we'd have to do.
>
> Well, UBIFS and JFFS2 work on generic MTD, so having a special hack for NOR
> is not really what we want.
Agreed. I was hoping there was a similar trick for NAND which I'm less
familiar with. The fallback behavior of an immediate erase is still
doable but it has more corner cases that we'd need to be weary of.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: secure file deletion/SECRM support for JFFS2 and UBIFS
2016-04-27 22:35 ` Chris Packham
@ 2016-04-28 7:27 ` Richard Weinberger
2016-04-28 8:40 ` Ricard Wanderlof
0 siblings, 1 reply; 9+ messages in thread
From: Richard Weinberger @ 2016-04-28 7:27 UTC (permalink / raw)
To: Chris Packham; +Cc: linux-mtd, Henry Shen
Am 28.04.2016 um 00:35 schrieb Chris Packham:
>> Well, UBIFS and JFFS2 work on generic MTD, so having a special hack for NOR
>> is not really what we want.
>
> Agreed. I was hoping there was a similar trick for NAND which I'm less
> familiar with. The fallback behavior of an immediate erase is still
> doable but it has more corner cases that we'd need to be weary of.
Nope, on NAND you're forced to erase.
Also erase itself is a problem (at least on UBIFS), it does not erase blocks
synchronous and also not immediately after they are no longer needed.
So, you'd have to touch some code...
Blindly doing a synchronous erase will hurt the performance as you
block the callers.
Thanks,
//richard
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: secure file deletion/SECRM support for JFFS2 and UBIFS
2016-04-28 7:27 ` Richard Weinberger
@ 2016-04-28 8:40 ` Ricard Wanderlof
2016-04-28 8:49 ` Richard Weinberger
0 siblings, 1 reply; 9+ messages in thread
From: Ricard Wanderlof @ 2016-04-28 8:40 UTC (permalink / raw)
To: Richard Weinberger; +Cc: Chris Packham, Henry Shen, linux-mtd
On Thu, 28 Apr 2016, Richard Weinberger wrote:
> Am 28.04.2016 um 00:35 schrieb Chris Packham:
> >> Well, UBIFS and JFFS2 work on generic MTD, so having a special hack for NOR
> >> is not really what we want.
> >
> > Agreed. I was hoping there was a similar trick for NAND which I'm less
> > familiar with. The fallback behavior of an immediate erase is still
> > doable but it has more corner cases that we'd need to be weary of.
>
> Nope, on NAND you're forced to erase.
I know generally there is a recommendation not to overwrite bits already
set to 0 with 0 for NAND, but I can't remember if that is related to the
subsequent readability of surrounding data, or if may cause a future erase
not to perform properly, or actually physically damages the bit cell (or
there is some other reason).
If it's just related to the readability of surrounding bit cells, one
could imaging overwriting a page with zeros since we were not going to
read it anyway.
With MLC it's going to be a problem though due to bits being paired
between separate pages.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: secure file deletion/SECRM support for JFFS2 and UBIFS
2016-04-28 8:40 ` Ricard Wanderlof
@ 2016-04-28 8:49 ` Richard Weinberger
0 siblings, 0 replies; 9+ messages in thread
From: Richard Weinberger @ 2016-04-28 8:49 UTC (permalink / raw)
To: Ricard Wanderlof
Cc: Chris Packham, Henry Shen, linux-mtd,
Bean Huo 霍斌斌 (beanhuo),
Han Xu
Am 28.04.2016 um 10:40 schrieb Ricard Wanderlof:
>
> On Thu, 28 Apr 2016, Richard Weinberger wrote:
>
>> Am 28.04.2016 um 00:35 schrieb Chris Packham:
>>>> Well, UBIFS and JFFS2 work on generic MTD, so having a special hack for NOR
>>>> is not really what we want.
>>>
>>> Agreed. I was hoping there was a similar trick for NAND which I'm less
>>> familiar with. The fallback behavior of an immediate erase is still
>>> doable but it has more corner cases that we'd need to be weary of.
>>
>> Nope, on NAND you're forced to erase.
>
> I know generally there is a recommendation not to overwrite bits already
> set to 0 with 0 for NAND, but I can't remember if that is related to the
> subsequent readability of surrounding data, or if may cause a future erase
> not to perform properly, or actually physically damages the bit cell (or
> there is some other reason).
I have been told that overwriting data on NAND can lead to physically damage,
but don't ask for a reference. ;-)
Maybe NAND fracturing folks can give more details on this topic.
Thanks,
//richard
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-04-28 8:49 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-27 5:07 secure file deletion/SECRM support for JFFS2 and UBIFS Chris Packham
2016-04-27 7:05 ` Richard Weinberger
2016-04-27 7:05 ` Richard Weinberger
2016-04-27 21:49 ` Chris Packham
2016-04-27 21:55 ` Richard Weinberger
2016-04-27 22:35 ` Chris Packham
2016-04-28 7:27 ` Richard Weinberger
2016-04-28 8:40 ` Ricard Wanderlof
2016-04-28 8:49 ` Richard Weinberger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.