Closed alphanis closed 3 years ago
@alphanis Does this happen every time you do the wipe using prng=isaac and does the log entry occur at the start or end of the drive or randomly somewhere in the middle? What size of drive, can you post the log data in hex? A .jpg snapshot will do. Can you post the entire log entry. You will need to save the log entry using the command line option and then copy back to the USB. What I need to determine is whether the verify failed due to an I/O error and the data you are seeing wasn't generated by the wipe but already existed on the drive or whether the data you are seeing matches the log typically generated by nwipe.
My first thought is that it's some bug in nwipe but I'll run some tests tonight and see if I can reproduce it.
@alphanis Confirmed, I've completed some tests on nwipe and can reproduce this bug.
I found it's specific to the following configuration ISAAC PRNG (it doesn't appear to error out with the default Mersenne Twister PRNG) and with 'All passes verified'. It doesn't occur with the default last pass verify.
I'll open a issue with nwipe and investigate. Thanks for reporting.
Addendum: It also only occurs if --prng=isaac is specified on the command line but not if you use nwipe's GUI to change from mersenne to isaac having not specified --prng on the command line.
@PartialVolume
I found it's specific to the following configuration ISAAC PRNG (it doesn't appear to error out with the default Mersenne Twister PRNG) and with 'All passes verified'. It doesn't occur with the default last pass verify.
Last pass verifying enables final blanking pass as I wrote:
- Disable final blanking pass. (BTW, you can see verifying option cannot be enabled when you do this. Is this intended?)
So I think nwipe would still write wrong prng data on disk and just skip verifying write pass. Final verifying would be successful because of final blanking.
I confirmed shredos writes wrong prng data also with default last pass verify. I've tested following order:
And this is the result.
As you can see, there are 4 KiB blocks. Each blocks begin with log text followed by bunch of 0x00, and 0x41F00100, 0xF1EF0100 in footer.
@alphanis Confirmed, this is also a bug in nwipe. I'm currently working on a fix. If you have time could you open an issue over on nwipe, don't worry about mentioning the grub.cfg in ShredOS as I can reproduce this on the command line in ubuntu as well using the command sudo ./nwipe -v --prng=isaac --verify=all /dev/loop29
.
You can also reproduce this issue without the verification errors by zeroing the drive, confirming it zero'ed with a hexeditor then putting --prng=isaac on the command line sudo ./nwipe -v --prng=isaac /dev/loop29
and in the GUI switching to PRNG, no verification and no final blanking. The wipe completes without errors however using the hexeditor I just see the zero'ed drive rather than the PRNG stream. If I then do a mersenne prng, no verification, no blanking, then check with the hexeditor for the prng stream it's there on the disc. If I then repeat the sudo ./nwipe -v --prng=isaac /dev/loop29
with no verification, no blanking I should see a different stream however what I see is the disc filled with zero's.
So the disc is being written as confirmed by the log but apparently not with the isaac prng. I suspect it's writing the uninitialized buffer, that should have been initialized with the prng stream which is probably why you are seeing random log messages.
As you previously mentioned, if you don't specify --prng=isaac on the command line but do a PRNG, isaac, no verify, no blanking, the stream gets written correctly. So the problem only shows itself when you put prng=isaac on the command line.
I hope to get this fixed over the next few days in nwipe and issue a 0.31 release that I'll pull into ShredOS, time permitting by the end of the weekend.
Thanks again for the detailed info, it was very helpful.
As the bug is specifically in nwipe rather than ShredOS, the conversation can be followed over at https://github.com/martijnvanbrummelen/nwipe/issues/318
Bug report.
shredos writes some kind of log data instead of actual prng data on drive.
To reproduce this bug:
menuentry "shredos" { linux /boot/shredos console=tty3 loglevel=3 nwipe_options="--prng isaac" }