Unusual Question

[Ian Smith]

In freebsd-questions Digest, Vol 684, Issue 3, Message: 5
On 12 Jul 2017 01:53:56 -0700 Doug Hardie <bc979 at lafn.org> wrote:
 > > On 9 July 2017, at 06:14, Ian Smith <smithi at nimnet.asn.au> wrote:
[..]
 > > # sysctl kern.geom.debugflags=16
 > > 
 > > purge at will.  if=/dev/random for the more paranoid :)

'Scuse delay, just got this (remote) server back after 4 days down from 
a broken phone connection somewhere along a bush track .. fixed today.

 > Today was the experimentation.  I had an old system here at the house 
 > with 8.2 on it.  So I started with a dd in=/dev/ada0 out=/dev/null to 
 > find out how many blocks were on the device.  Once I had that number, 

# gpart show ada0 | head -1	# is a quick way :)
=>       63  125045361  ada0  MBR  (59G)

 > I then ran dd if=/dev/random of=/dev/ada0 skip=<number of blocks 
 > minus a few>.  I typed oskip, but somehow the o didn't make it 
 > through the keyboard.  When it finished, I realized the error.

There is no oskip; I have to check dd(1) every time myself .. there's:
     iseek=n  Seek on the input file n blocks.  This is synonymous with
              skip=n.
     oseek=n  Seek on the output file n blocks.  This is synonymous with
              seek=n.

So yes, it skipped over Gigs of /dev/random, then wrote over all ada0.

 > So I had an install memstick for 11.0 and put it on as I wanted to 
 > try camcontrol sanitize.  Unfortunately, it reports an error 
 > accessing my drive.

I wonder if that also needs setting kern.geom.debugflags=16? ala geom(4)?

 > I then used dd if=/dev/ada0 skip=<same large  > number> | od -c.
 > Then I wrote down the first few bytes of the output.  They were 
 > non-zero.  I was a bit surprised by that since the last partition is 
 > swap and it was never used.  But perhaps that was left over from the 
 > random write.

Which would tend to indicate that the earlier dd ran to completion.  I 
see no reason to suppose that it wouldn't have.

 > From here on I have pictures of the output.  This is a 
 > dumb terminal and I will attempt to enter in the data since the list 
 > doesn't accept attachments.
 > 
 > dd if=/dev/zero of=/dev/ada0 bs=32k
 > dd: /dev/ada0: short write on character device
 > dd: /dev/ada0: end of device
 > 2442211+0 records in
 > 2442210+1 records out
 > nnnn bytes transferred.....

The 'short write' message is expected if the last output block != 32k

 > ls -l
 > <directory listing>
 > pwd
 > /bin/pwd: Exec format error.  Binary file not executable.
 > who
 > /usr/bin/who: Exec format error. Binary file not executable.

If you'd run pwd and who prior to clobbering the drive, they'd most 
likely be cached, and so available.  You'll get the same effect if you 
remove and replace a memstick (or USB external drive) you booted off; 
what was cached in memory works, fresh disk accesses will fail, though 
mount still shows the mount existing.  Pre-9.x or so it'd panic ..

 > dd if=/dev/ada0 skip=1000 count=5 | od -c
 > 0000000  \0 \0 \0 \0 ...
 > *
 > 0005000
 > 5+0 records in
 > 5+0 records out
 > 
 > dd if=/dev/ada0 skip=10000 count=500 | od -c
 > 0000000  \0 \0 \0 \0 ...
 > *
 > 0764000
 > 500+0 records in
 > 500+0 records out
 > nnnn bytes transferred...

 > I didn't capture this but I did run the dd with the oskip of the big 
 > number and it showed all zeros.

There is no oskip.  oseek (aka skip) would work.

 > I believe that dd, od and some of the current directory blocks were 
 > still remaining in memory.  However, the drive was definitely zapped.  

Yes, as indicated above.

 > It did write to the end of the drive.  However, I suspect that if 
 > something else was running during the dd and it tried to access the 
 > drive things could have come to a halt before the zap completed.  At 

It could, but unless it actually panic'd the box the dd should finish, 
i.e. just some other process/es crashing shouldn't interfere with it.

 > this point I tried to do a shutdown command and got the same Exec 
 > format error.  However, hitting the reset switch did cause a 
 > shutdown.  It seemed to be a normal shutdown as there were messages 
 > on the console, but I was not expecting it to work and only saw them 
 > for a brief second before the display was shut off.

I think this sort of work - especially to a remote server - is safest 
done in single-user mode, either via boot menu, where available, or by 
'shutdown now' from multi-user, with no daemons running that might want 
to write logs, or even to console over ssh where possible.  See below.

 > I would like to have tried camcontrol sanitize as that appears to be 
 > handled completely in the drive and controller.  It would complete 
 > regardless of what happened to the OS.  I couldn't use it anyway on 
 > the production systems as they are only at 8.3 and the sanitize 
 > command was added in 11.0.

It looks interesting, if slightly scary :)  No 11.x here either.

 > Net result:  I am not sure if the first production drive actually 
 > completed the zap.  It might have, but there is no way to tell.  

Well, when you reinstall something on that drive, you can inspect the 
end of the disk for zeroes - if that's what you wrote - or random data.
If MBR formatted, nothing will (initially) write near the end, and if 
GPT, nothing except for the last 34 sectors having the secondary GPT.

 > However, it was not important as it does not hold any sensitive data.  
 > It was tried first to see what would happen.  I will make sure 
 > nothing is running but sshd and dd when I do it on the critical 
 > systems.  I am considering starting the dd with a nohup and then 
 > killing sshd before it gets very far.  I think that has the best 
 > possibility of completing properly.

Yes, killing sshd early would be safest, but I'd start on a fresh boot, 
as (or dropped to) single-user, and stop services that log, notably nptd 
then syslogd at least.  Pre-run commands you want to use, here likely 
just dd, to cache them.  There's no reason any swap would be used after 
booting - it's not like you're running X or anything big - but you could 
run swapoff(8) to be sure.

In my experience, FreeBSD fiercely caches everything it can in memory 
and is reluctant to swap out anyway, so I think those fears unfounded, 
though I think getting dd(1) to write more to console (thus, via ssh) 
would increase the odds of something getting wedged - in fact the dd 
option 'status=none' is likely worth considering.

You might best run it/them from a little script, avoiding chances of 
fat-fingering .. maybe something like:

#!/bin/sh
# exterminate.sh :)
service stop ntpd		# add one for any others running
service stop syslogd		# avoid writes to /var/log etc
dd if=/dev/zero of=/dev/null count=1 # prime dd; random if preferred

(sleep 10 && \
 dd if=/dev/zero of=/dev/ada0 bs=1m status=none 2>&1 >/dev/null) &

service sshd stop
sleep 3600			# well, it shouldn't take an hour ..
echo "is anybody listening?"	# uh-oh ..
shutdown -p now			# oh, it's all gone wrong ..

I'm not even sure killing sshd is necessary, I think all its sockets and 
such would be cached, but it sure couldn't hurt.

cheers, Ian