If you use the --logfile option but specify a filename
that will be created in a directory that is not writable,
for instance, a system directory such as /proc/sys/ or
your current directory happens to be a system directory
that you are running nwipe from while not specifying a
writable path for the log file then nwipe would exit with
a segfault.
This is now fixed and if the logfile cannot be created
or opened then an appropriate message is displayed and
nwipe is aborted.
This fixes a issue related to konsole and terminals based on Konsole,
like cool retro terminal. If you exit the terminal before exiting nwipe,
nwipe will then continue running in the background but detached from any
terminals input/output. This causes a call to halfdelay()/getch() to
return immediately, thus removing the delay and causing the thread to
run at full speed causing 100% CPU in a core. This requires nwipe to
then be killed manually. This patch is related to the last patch in
that both patches do much the same thing but the previous patch fixes
the problem when nwipe is sitting at the drive selection screen, while
this patch fixes the problem during a wipe.
This problem would only be seen in specific KDE konsole related
terminals and only if you do not exit nwipe by using nwipe's control c
to abort or use the space bar on completion of the wipe.
Much like the same check we perform in the nwipe_gui_select() function,
here we check that we are not looping any faster than as defined by the
halfdelay() function, typically this loop runs at 10 times a second.
This check makes sure that if the loop runs faster than double this
value i.e 20 times a second then the program exits. This check is
therefore determining whether the getch() function is returning
immediately rather than blocking for the defined period of 100ms.
Why is this necessary? Some terminals (konsole & deriviatives) that are
exited while nwipe is still running fail to terminate nwipe this causes
the halfdelay()/getch() functions to immediately fail causing the loop
frequency to drastically increase. We detect that speed increase here
and therefore close down nwipe. This doesn't affect the use of the tmux
terminal by which you can detach and reattach to running nwipe
processes. The tmux terminal will still work correctly when a nwipe
session is detached.
when Konsole terminal exited while nwipe is sitting at the
drive selection screen.
To avoid 100% CPU usage, check for a runaway condition caused by the
function "keystroke = getch() that immediately returns an error
condition. We check for an error condition because getch() returns a
ERR value when the timeout value "timeout( 250 );" expires as well as
when a real error occurs. We can't differentiate from normal operation
and a failure of the getch function to block for the specified period
of timeout. So here we check the while loop hasn't exceeded the number
of expected iterations per second ie. a timeout(250) block value of
250ms means we should not see any more than (1000/250) = 4 iterations.
We double this to 8 to allow a little tolerance. Why is this necessary?
It's been found that in KDE konsole and other terminals based on the QT
terminal engine exiting the terminal without first existing nwipe
results in nwipe remaining running but detached from any interface
which causes getch to fail and its associated timeout. So the CPU or
CPU core rises to 100%. Here we detect that failure and exit nwipe
gracefully with the appropriate error. This does not affect use of
tmux for attaching or detaching from a running nwipe session when
sitting at the selection screen. All other terminals correctly
terminate nwipe when the terminal itself is exited.
This fixes a problem where the drive temperature is not updated
automatically in the drive selection window only. The temperature
is however updated every correctly every 60 seconds during a wipe in
the wipe status window.
This bug would probably never be noticed by most people as usually the
drive temperature changes slowly and only rises once a wipe has started.
The only time I imagine it would have been noticed would have been if
the drive temperature was already high and you were trying to reduce the
temperature by cooling before starting a wipe.
This has now been corrected so that the temperature in the drive
selection window is updated every 60 seconds.
This patch fixes a minor display issue that occurs when
a user aborts a wipe before a wipe has started. It only occurs
if the user had selected one or more drives for wipe and then
aborted before starting the wipe. The spurious message only
occurs in a virtual terminal, i.e. /dev/tty1, /dev/tty2, /dev/console
It does not occur in terminal applications such as konsole, xterm,
terminator etc.
The spurious message that appears in the main window, states that
"/dev/sdxyz 100% complete" along with garbage values in the statistics
window. The message appears for a fraction of a second before being
replaced with the textual log information that correctly states that
the user aborted and no wipe was started.
Basically the gui status information update function tries to update
the data when the wipe hasn't even started. The fix is to only update
the statistics information only if a wipe has started by checking the
'global_wipe_status' value which indicates whether any wipe started. '1'
indicates that a wipe has started, else '0' if no wipe has started.
If the drive becomes non responsive during the wipe, the MB/s will
slowly drop towards 0MB/s and will display a FAILURE -1 error. The logs
will display errors and nwipe's return status will be non zero, however
the summary table may display erased rather than FAILURE, this is because
the wipe thread exited prematurely without setting the pass error.
This fixes the error by checking the context's result status, i.e non zero
on failure and if pass equals zero it makes pass equal to one. This is
then picked up by the summary table log code which then marks the status
correctly as FAILURE in the summary table.
https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
"... random passes before and after the erase process, and by performing the deterministic passes in random order ..."
"The deterministic patterns between the random writes are permuted before the write is performed, ..."
Each ISAAC call generates a block of integers, but only the first integer was used before the PRNG was called again.
This resulted in most of the random numbers being wasted and more calls to the PRNG than was necessary.
Also fixed some segmentation faults in ISAAC-64 code.
* remove redundant paragraphs and information especially regarding ShredOS
* move certain paragraphs around to streamline the readme and for better readability
* update links
* some minor changes
This was caused by inconsistent labeling of the
serial number by smartctl. In a majority of cases
smartctl would output serial number data using
the label "Serial Number:" however on a SAS
drive we found that smartctl output the label
as "Serial number:" i.e. differs with a lower
case 'n'. Unfortunately we were doing a case
sensitive search for "Serial Number" so the result
being the serial number was not found.
This patch converts both strings in the search
to lower case before searching.
In addition a new field was added to the
anonymize list, "logical unit id:" so when the
-q option is used "serial number", "lu wwn device id:"
and "logical unit id:" are all now anonymized in the
smartctl debug data.
If pthread_join failed, nwipe would report an error
but would also report that the thread had been
cancelled. This has been corrected so that only
the error message is displayed in a fault condition.
Particularly relevant to Debian which when logged in as root
doesn't put /sbin in the $PATH environment setting.
This might have caused temperatures to not be available on Debian
systems, but not necessarily on distros based on Debian like
Ubuntu which would have worked ok.
The format specifier didn't match the size of the variable that holds
c2[i]->device_sector_size which is an int. This didn't appear to cause
a problem with reporting in a 64 bit build. It does cause a problem in
a 32 bit build displaying a very large & incorrect number for sector,
block and device sizes.
This doesn't cause any issues with the overall function, simply
incorrect sector, block and device sizes in 32 bit builds as displayed
in the nwipe log.
I also changed the signed long long for c2[i]->device _size to a
unsigned long long as there is little point in a negative device size.
