Unusual Question

[Arthur Chance]

On 14/07/2017 18:03, Warren Block wrote:
> On Fri, 14 Jul 2017, Arthur Chance wrote:
> 
>> On 14/07/2017 07:11, Doug Hardie wrote:
>>>
>>>> On 13 July 2017, at 21:44, David Christensen
>>>> <dpchrist at holgerdanske.com> wrote:
>>>>
>>>> On 07/09/17 02:57, Doug Hardie wrote:
>>>>> I have a FreeBSD 9.3 remote server that needs to be purged.  I know
>>>>> that rm -rf / will remove all the directory entries, but I need to
>>>>> write over the drive.  I thought that dd if=/dev/zero of=/dev/ada0
>>>>> might do the trick, but it gives an not permitted error.  The whole
>>>>> thing can crash and burn at the end.  This is an unmanned site so
>>>>> moving drives is not viable.
>>>>
>>>> If the machine has BIOS and the system drive isn't too large, write
>>>> an assembly program that fits into the MBR bootstrap code area to
>>>> wipe the rest of the drive, assemble the program, write it into the
>>>> MBR, and reboot.
>>>>
>>>>
>>>> Bonus: the program deletes the MBR when done wiping the rest of the
>>>> drive.
>>>
>>> Neat idea, but I have a number of these systems and they all use
>>> different disk drives.  That would be a lot of work writing drivers
>>> for each type.
>>
>> How about using the BIOS extended write sector call (INT 13h, AH=43h) in
>> your code? That should be portable.
> 
> Won't that choke after 2TB?  It might wrap around to the start of the
> drive after the 2TB mark, or just fail.  Failure would be better, at
> least it would mean that half of a 4TB drive might be left intact
> without notice.

It's a while since I last did any BIOS programming, but if my memory is
correct the basic disk io with CHS addressing is limited to ~8GB, but
the enhanced disk io routines using 48 bit LBAs can handle any existing
disk. (48 bit LBAs allow disks up to 128 PiB.)

The 2TB limit is in the maximum partition size in the MBR partition
table, not the BIOS disk io limit.

> But this idea of having a self-destructive boot block has some other
> problems.  A tiny space for code, a dangerous thing to have lying
> around, and if you have to reboot into it, might as well reboot into
> mfsBSD (http://mfsbsd.vx.sk/) and be sure that it works.

Agreed. It's more of an intellectual exercise that anything else. It's
not something I'd want loose in the wild.

> For SSDs, the Secure Erase option might be viable.  I have not yet had
> that work in the couple of times I've tried it, but that could be due to
> improper usage or possibly lack of support on the old SSDs being used.



-- 
An amusing coincidence: log2(58) = 5.858 (to 0.0003% accuracy).