From owner-freebsd-questions@freebsd.org Sat Jul 15 12:14:29 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FFDBAF9184 for ; Sat, 15 Jul 2017 12:14:29 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from bede.home.qeng-ho.org (bede.qeng-ho.org [217.155.128.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fileserver.home.qeng-ho.org", Issuer "fileserver.home.qeng-ho.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DA6B06E9AD for ; Sat, 15 Jul 2017 12:14:28 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from arthur.home.qeng-ho.org (arthur.home.qeng-ho.org [172.23.1.2]) by bede.home.qeng-ho.org (8.15.2/8.15.2) with ESMTP id v6FCEJKQ034005; Sat, 15 Jul 2017 13:14:19 +0100 (BST) (envelope-from freebsd@qeng-ho.org) Subject: Re: Unusual Question To: Warren Block Cc: freebsd-questions@freebsd.org References: <888578F8-AD68-4993-823C-152789F3C929@mail.sermon-archive.info> <0ccfaae9-6fdb-adfa-71b2-5dd3978f41b3@qeng-ho.org> From: Arthur Chance Message-ID: <01c6a4c3-1dd9-ee46-a224-a3a2993c377e@qeng-ho.org> Date: Sat, 15 Jul 2017 13:14:19 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 12:14:29 -0000 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 >>>> 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).