openconfig
clarification needed for gnoi.factory_reset
Hi
Regards gnoi.factory_reset, please kindly help clarify the below 'zero_fill' option.
https://github.com/openconfig/gnoi/blob/1ece8ed91a0d5d283219a99eb4dc6c7eadb8f287/factory_reset/factory_reset.proto#L22
// Optionally allows for the Target to zero-fill permanent storage where state // data is stored.
message StartRequest { // Instructs the Target to zero fill persistent storage state data. bool zero_fill = 2; }
Was the intention just to reset/wipe the storage? or literally to populate 0's across the storage? The thing is, each media has it own way of wiping out the storage, some vendors may choose to write specific patterns, some may decide to write scrambled/random values, etc.
There is no guarantee that the wiped storage can always be zero-filled, unless someone explicitly write 0's all over the storage.
If the client's intention is just to reset the target to some inii state, but does not really requires to zero-fill the storage, is it possible to add the third option for such purprose. bool erase = 3
Hi @peichengATgit,
the intention is indeed to scramble the media in order to avoid potential forensics from being able to recover data. I agree with your statement that there may be different methods to perform this, zero filling is just one.
Regarding this specific RPC, it instructs the Target to fall back to its factory reset state. This includes storage. It may be that some platforms cannot really have their storage wiped as it keeps the bootable OS image, it is fine for those platforms to simply opt out from implementing the optional zero_fill knob. But once the RPC is called successfully, it is expected that the file system looks the same as it looked at factory defaults, e.g.: only a single OS image file.
Having said that, the proto file could use having this reasoning in the description. And perhaps a deprecation of the zero_fill, and a new optional scramble flag that allows the platform to decide what scrambling method to apply.
Thank Sam for the clarification.
When zero_fill=false, does that mean that 1/ the client does not need/care the target to wipe/scramble its storage, OR 2/ the client does not want the target to wipe/scramble any storage.
As you already mentioned above, if a Target has to keep the bootable OS image, then surely it cannot support 'zero_fill'. But even the action of 'keep the bootable OS image' can implement differently:
- option A: find someway to stage the OS image, wipe the storage, then copy the image back to storage
- option B: iterate the storage, explicitly delete the content from the storage other than the OS image.
We can imagine that "option A" could be more straight forward as it simply wipes out everything, while "option B" could use more knowledge about the device content, for example, to make sure to remove all kinds of scattered hidden partition/info, etc.
If the intent is the above case 1/, then the Target is able to choose either option A or B, whichever deems appropriate. If the intent is rather the above case 2/, then the target can only go with option B.
Can you please clarify?
Hi @peichengATgit,
it means 1/
The main approach of the proto is to abstract from the implementation details of the Target and have the Target manage its own internals. There are more options than the ones you list and likelly an equivalent or more number of options to solve them. The important thing here in regards to the zero_fill is that the intent is to scramble the storage that is holding any customer specific data like configuration, passwords etc. Unfortunatelly the name of "zero_fill" and the associated commentary were not particularly effective at clarifying this so this proto requires a bit more work in that aspect.
Cheers, Sam