Great idea! I didn't think of that.

The header of the key would remain intact, but the value would be all 0s and the space would not be freed until garbage collection is called

Yep! That is exactly the way to do it. You can basically just copy the existing invalidate function and expand the amount of zeroes we set.

The only issue is that I'm not sure what guarantees flash hardware makes about recovering that data. It might be easier to recover compared to a full erase. But that's probably up to a board designer as an erase could have the same problems anyway

I have a pull request prepared that adds the Zeroize Key option. Thinking about the feature, we may not want to carry the option to both Invalidate and Zeroize.

• There is no way to recover a key after Invalidate Key has been called
• From the embedded implementation mindset, we would not want to carry extra code
• The extra commands would make the interface unnecessarily complex
• From a security standpoint, there is no instance to Invalidate rather than Zeroize

I believe it would be in TickV's best interest to outright replace Invalidate with Zeroize. What are your thoughts?

Zeroise will wear the flash more, so I think keeping both makes sense.

We could split them into separate HILs. As maybe not all future Tock KV implementations support zeroise

I understood wear occurs from erasing. Often writing is thought to cause wear because it is usually required to erase first. For TicKV, we use Sequential Writes to cascade down a Flash page (page being a subdivision of a Sector, the minimum erasable area).

Andrew's approach is to zeroize, not "Erase" in the Flash sense.

My understanding is similar to @wright-joe's, though I'm no low-level flash expert, unfortunately. There is certainly a question of whether "zeroize" should be an explicit part of the interface to KV stores, a guarantee that the interface provides, a default feature of a particular implementation, or something else. I suggest that, for the moment, a description in an RFC-style issue or a PR is a good starting point.

Both tradeoffs, in principle seem reasonable (either do a somewhat subtle backup and overwrite, as well as have zeroizable keys/values padded to a page). It's possible wear leveling is less of a concern in some case (e.g. if cryptographic keys are overwritten/erased, but rarely).

So helpful to understand the specific use case.

I just realised @AndrewImwalle isn't using Tock, so I guess this is completed for them!

I just realised @AndrewImwalle isn't using Tock, so I guess this is completed for them!

No, I think this is for Tock, so I guess this still needs to be used/exposed in the HIL/capsules/etc

Future KV stores might not support a zeroise

They may not need to. In particular, one implementation of a KV interface could promise to zeroize, but that need not be a promise of the high-level interface. An analogy is that unlink doesn't promise to erase data from disk, but some file-system implementations do, and it's reasonable to rely on that property end-to-end in a system.

and the extra wear on flash is not worth it for all use cases

I'm not sure we resolved that there is extra practical wear on flash. In particular, it doesn't change the number of page-erases that eventually happen.

I'm not sure we resolved that there is extra practical wear on flash.

Given that the erases are the high-voltage operation, I strongly suspect that writing zeros does NOT cause additional wear on the flash.

They may not need to. In particular, one implementation of a KV interface could promise to zeroize, but that need not be a promise of the high-level interface. An analogy is that unlink doesn't promise to erase data from disk, but some file-system implementations do, and it's reasonable to rely on that property end-to-end in a system.

That seems brittle for a crypto interface. I think we should explicitly say "this command zeroises OR returns an error". Having a command that might zeroise important data seems like a way to accidentally leak data.

Given that the erases are the high-voltage operation, I strongly suspect that writing zeros does NOT cause additional wear on the flash.

Reading https://www.ti.com/lit/an/slaa334b/slaa334b.pdf?ts=1698709005672 it does seem like writing doesn't have long term effects

Writing to the same row too many times can result in write disturb, and erased bits will be programmed as
well. This produces no physical damage and, after erase, the disturbed bits are programmable as before.
No long term effects are known.

I thought I remembered seeing that write does have some life cycle impact, but I can't seem to find it again.

Writing more data does take more time though, so there is a cost