UFS Wiping out data from FreeBSD disk partitions

My FreeBSD partitions are like this :
Code:
pc154:user 12] df -h
Filesystem           Size    Used   Avail Capacity  Mounted on
/dev/gpt/rootfs      2.0G    1.7G    144M    92%    /
devfs                1.0K    1.0K      0B   100%    /dev
/dev/gpt/efi         1.0G     64K    1.0G     0%    /efi
/dev/gpt/var         387M    7.9M    348M     2%    /var
/dev/gpt/godspeed    1.9G    124K    1.8G     0%    /var/db/godspeed
/dev/gpt/data        784G     27G    694G     4%    /data
procfs               4.0K    4.0K      0B   100%    /proc
linprocfs            4.0K    4.0K      0B   100%    /compat/linux/proc
linsysfs             4.0K    4.0K      0B   100%    /compat/linux/sys
I would like to delete data completely from the following partitions :
/dev/gpt/var
/dev/gpt/godspeed
/dev/gpt/data

I tried the following commands :
Code:
pc154:user] pwd
/data        <==== my current location
pc154:user] 
pc154:user] find /var -name "*" | wc -l
      98       <==== total 98 files are present in '/var' folder
pc154:user] 
pc154:user] sysctl kern.geom.debugflags=16
kern.geom.debugflags: 16 -> 16
pc154:user] 
pc154:user] dd if=/dev/zero of=/dev/gpt/var bs=1024 seek=0 count=396288    <==== zeroing entire 387M of /dev/gpt/var
396288+0 records in
396288+0 records out
405798912 bytes transferred in 10.398334 secs (39025378 bytes/sec)
pc154:user] 
pc154:user] sync
pc154:user]  find /var -name "*" | wc -l
      98       <==== all the 98 files still present in '/var' folder
pc154:user]

As observed from the above commands, even after executing 'dd' command which is supposed to wipe out all data from '/dev/gpt/var', I can see all the old files are still present.

I can't find any clue why 'dd' command is not able to wipe out data from the file system.
Any idea ?

Thanks !!!

Note: Even if I use '/dev/da0p6' instead of '/dev/gpt/var' in the above 'dd' command, I get the same result.
 
You nuked the partition out from under the OS. Unmount /dev/gpt/var and remount it and see if it's still there...
 
  • Thanks
Reactions: Avk
You nuked the partition out from under the OS. Unmount /dev/gpt/var and remount it and see if it's still there...
Bad luck !!!
As soon as I unmount the partition, the system crashes. May be I need to try other trivial partition once it boot up again. I guess even rebooting the system should take effect if it works.
 
Bad luck? You rug-pulled the OS and expected it to be fine? Unmount the other partition before trying the same stunt.
 
  • Like
Reactions: mer
98 <==== all the 98 files still present in '/var' folder
Those 98 files (and the directories they are contained in) were in memory (RAM) cache.

Your basic idea is good: Overwrite the disk partitions (for example with zeroes) to make data unreadable. But NEVER EVER do this while the file system is mounted. Because file systems cache a lot of data in memory. Matter-of-fact, if you had performed a write to that file system after overwriting, the file system might have written data back to the disk.

The resulting crash is no surprise at all. File systems aren't designed to handle all of the underlying storage suddenly turning into garbage.

Reboot, and you should find that there is no file system there any more, and any attempt to mount it will fail. If you then examine the content of the disk (hexdump -C is nice), you should find nothing there (or perhaps very little, if writes were in progress at the time, and raced with your overwrite). And next time, do this after unmounting please.
 
And if it's something that won't let you unmount, then reboot to single user mode and try the dd command. When you are single user mode, not much past / is actually mounted (and that may even be mounted read only).
 
  • Thanks
Reactions: Avk
So far what I observed is that for some partitions unmounting operation, system does not crash and unmounting operation must be done in specific order.

umount -f /dev/gpt/data
umount -f /dev/gpt/godspeed
umount -f /dev/gpt/var

After unmounting operations I can do 'dd' operation to wipe out data from all the above partition.

dd if=/dev/zero of=/dev/gpt/data bs=1024 seek=0 count=10485760
dd if=/dev/zero of=/dev/gpt/godspeed bs=1024 seek=0 count=2031132
dd if=/dev/zero of=/dev/gpt/var bs=1024 seek=0 count=395896

Once I reboot the box after 'dd' operations, the system didn't boot up. Probably because of 'dd' operation the partition table might have corrupted and hence the system didn't boot up (?).

Problem is how can I ensure all the data got deleted because of 'dd' operation as the system didn't boot up ?

Even if I apply 'dd' operation only on one partition ( /dev/gpt/data) , I get the same result.

Thanks !!!
 
Don't add -f to the unmount command willy-nilly. There's typically a reason why it doesn't want to unmount (because it's still in use for example!). Forcing the unmount is usually a very, very bad idea and should not be done lightheartedly.

Code:
     -f        The file system is forcibly unmounted.  Active special devices
               continue to work, but all other files return errors if further
               accesses are attempted.  The root file system cannot be
               forcibly unmounted.  For NFS, a forced dismount can take up to
               1 minute or more to complete against an unresponsive server and
               may throw away data not yet written to the server for this
               case.  If a process, such as umount without the -f flag is hung
               on an NFS mount point, use the -N flag instead.  Also, doing a
               forced dismount of an NFSv3 mount when rpc.lockd(8) is running
               is unsafe and can result in a crash.

unmounting operation must be done in specific order.
Unmounting must always be done in the reverse order they are mounted. You cannot unmount /mnt/some/dir before /mnt/some/dir/lower is unmounted.

In your case /data can be unmounted fairly easily as long as you don't have applications running that use that filesystem. Same for /var/db/godspeed. /var is a little trickier because there are many system services (syslog being the primary one) that have files open on that filesystem. And /var/db/godspeed needs to be unmounted before you can unmount /var (order is important here).

With any unmount, you will need to stop any and all processes that have files open on that filesystem before you can "safely" unmount them. Failing to do so (and by forcing the unmount) you are essentially pulling the rug from under your feet. Sometimes this works out fine, but there's definitely a high risk of crashing or just locking up the system.
 

Unwanted destruction​

kern.geom.debugflags=16

For readers who are not familiar with this value (16) for the sysctl: it allows irreparable damage.

From <https://unix.stackexchange.com/a/195028/13260>:

sysctl kern.geom.debugflags=16 (or kern.geom.debugflags=0x10, which is all the same) you get allowed to shoot in the foot …

From <https://www.freebsd.org/cgi/man.cgi?query=geom&sektion=4&manpath=FreeBSD#DIAGNOSTICS>:


… All of these flags are off by default, and great care should be taken in turning them on.



0x10 (allow foot shooting)

Allow writing to Rank 1 providers. This would, for example, allow the super-user to overwrite the MBR on the root disk or write random sectors elsewhere to a mounted disk. The implications are obvious.



There's just one warning in the FreeBSD Handbook, easily overlooked.
 
  • Thanks
Reactions: Avk
Avk welcome to FreeBSD Forums.



If device da0 is solid state, and if your intention is to securely erase data from any part of the device:
  • simply writing zeros to that part might not have the required effect.
Why do you think writing zeros might not have required effect ?
For us we need to ensure data are actually deleted from selected partitions. We don't care if the system become unusable after 'dd' operation.

dd if=/dev/zero of=/dev/gpt/data bs=1024 seek=0 count=10485760

Once we do the 'dd' operation probably it delete some important information from the beginning. Is it possible to know the correct "seek= " value so that 'dd' operation only delete data from the partitions, but not everything from the beginning of the disk partition (where it might be storing some crucial partition info) ?

Thanks !!!
 
Why do you think writing zeros might not have required effect
Writing zeroes decreases the lifespan of the drive. grahamperrin might be thinking about how TRIM will just mark it as unallocated and not actually erase it, but this bypasses that method of erasure. Nitpicky details.

For us we need to ensure data are actually deleted from selected partitions. We don't care if the system become unusable after 'dd' operation
Just unmount the partition before destroying it and you won't crash the system. Don't bother using the count or seek. If you need to verify that it's all zeroes, then just read the partition back with dd if=/dev/gpt/data and verify the giant binary chunk it dumps into the terminal is 694GB of zeroes. This is left as an exercise for you to figure out, because the dd if=/dev/zero of=/dev/gpt/data is going to do the correct thing.
 
  • Thanks
Reactions: Avk
so that 'dd' operation only delete data from the partitions, but not everything from the beginning of the disk partition

If you specify the correct partition with da0p6 or /dev/gpt/data you'll get your desired results. If you want to nuke the whole drive you would use da0,
 
  • Thanks
Reactions: Avk
I think the compact way of saying it is that SSD firmware moves around the physical location of an "absolute position" on disk so you can never be 100% sure you deleted something without vendor support.
 
I think the compact way of saying it is that SSD firmware moves around the physical location of an "absolute position" on disk so you can never be 100% sure you deleted something without vendor support.

That sounds like what I had/have in mind. I couldn't recall the keywords until I found the phrase transparent wear levelling whilst seeking discussion of the HP technical white paper below. From that, I found things such as these:


With the types of modern HP notebook that pass through my hands, I'm accustomed to F10 at boot (before the operating system) then a very quick secure erase (two minutes, something like that).

A few weeks ago I was surprised to find nothing comparable in a dynabook (or, it might have been a Toshiba) with an SSD. Instead, I booted from a utility drive and ran something that slowly overwrite the internal SSD. This was more for entertainment – to remind myself of available utilities – than truly for security, because I (then) had in mind the behind-the-scenes movement that msplsh describes. In retrospect, I see that it was like point 3 above.

HP Secure Erase for SSDs & HDDs whitepaper (2021-06-09, PDF)

Side note: the paper's visual link to hp.com/wolfsecurityforbusiness is technically a link to non-existent <http://hp.com/go/computersecurity>. Manual adaptation of the URL to <https://www.hp.com/go/computersecurity> causes a redirect (for me, in the UK) to <https://www.hp.com/uk-en/security/pc-security.html?jumpid=va_v85nm19hyz>, which is not the canonical URL. Canonical for Firefox leads from there, to <https://www.hp.com/us-en/security/pc-security.html>, which (according to the extension) is also not a canonical URL, but is probably the best for bookmark purposes. The battle with and between HP's websites will never be won. Oh, and thanks, HP, for using non-secure http URLs in your security-specific white paper and related pages.

tl;dr from HP PCs - Using HP Disk Sanitizer or Secure Erase | HP® Customer Support:

  • Secure Erase: Works on solid-state drives and hard disk drives. HP added Secure Erase to the standard BIOS in 2011. Systems sold in 2009 or later can upgrade the BIOS to include Secure Erase.
 
Writing zeroes decreases the lifespan of the drive. grahamperrin might be thinking about how TRIM will just mark it as unallocated and not actually erase it, but this bypasses that method of erasure. Nitpicky details.


Just unmount the partition before destroying it and you won't crash the system. Don't bother using the count or seek. If you need to verify that it's all zeroes, then just read the partition back with dd if=/dev/gpt/data and verify the giant binary chunk it dumps into the terminal is 694GB of zeroes. This is left as an exercise for you to figure out, because the dd if=/dev/zero of=/dev/gpt/data is going to do the correct thing.
Hi msplsh
I have tried to verify delete operation of '/dev/gpt/var' which is just 2G in size. But the verification process was taking too long, no output on the terminal unless I aborted the operation in the middle.

wsa154:rtestuser 16] dd if=/dev/zero of=/dev/gpt/var <== filling partition data with all zero
dd: /dev/gpt/var: end of device
819201+0 records in
819200+0 records out
419430400 bytes transferred in 20.832344 secs (20133615 bytes/sec)
wsa154:rtestuser 17]

wsa154:rtestuser 17] date
Thu May 26 08:13:36 UTC 2022
wsa154:rtestuser 18] dd if=/dev/gpt/var <== Trying to verify data deletion.
^C <== aborting the operation as it takes too long
17535+0 records in
17534+0 records out
8977408 bytes transferred in 9396.934214 secs (955 bytes/sec)
wsa154:rtestuser 19] date
Thu May 26 10:50:57 UTC 2022
wsa154:rtestuser 20]
Thanks !!!


Edit :
Finally I am able to do the operation, but I don't see any binary chunk dump in the terminal.
wsa154:rtestuser 16] dd if=/dev/gpt/var
819201+0 records in
819200+0 records out
419430400 bytes transferred in 45.955987 secs (9126785 bytes/sec)
wsa154:rtestuser 17]
 
I thought you might figure this out on your own but I guess not.

You're not going to look at 4,000,000,000 digits and verify each one is zero. You will need to create some kind of program or script to do this and get the input from dd.
 
One easy (but still slow) way of doing it: dd if=/dev/... | hexdump -C

Hexdump will print the initial row of 16 zeroes, then it will wait and print a single "*" for the repeated lines, and at the very end print the last address (which is count of bytes, in hex).
 
One easy (but still slow) way of doing it: dd if=/dev/... | hexdump -C

Hexdump will print the initial row of 16 zeroes, then it will wait and print a single "*" for the repeated lines, and at the very end print the last address (which is count of bytes, in hex).

That's wonderful.
It display the way you said and it should be enough to confirm all zero filled up.
No need to write any extra script for that ...

1653631195951.png
 
With the wear levelling stuff: is it possible for a data fragment that was previously in that part of the device to be elsewhere now?

I'm not being paranoid, just trying to better understand the implications of this type of thing – where data is not encrypted from the outset.
 
Depending on the algorithm, the controller might stop using a block and start using another one from spare capacity and remap it so you don't even notice.
 
Back
Top