Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!prls!pyramid!chronon!eric
From: eric@chronon.UUCP (Eric Black)
Newsgroups: net.unix-wizards,net.sources.bugs
Subject: Re: What happens during an unlink(2)
Message-ID: <238@chronon.chronon.UUCP>
Date: Thu, 1-May-86 15:09:10 EDT
Article-I.D.: chronon.238
Posted: Thu May  1 15:09:10 1986
Date-Received: Sat, 3-May-86 02:12:12 EDT
References: <947@kitty.UUCP> <403@ukecc.UUCP> <979@kitty.UUCP> <422@ukecc.UUCP>
Reply-To: eric@chronon.UUCP (Eric Black)
Organization: Chronon Computer Corp., Mtn. View, CA
Lines: 40
Keywords: Disk blocks sometimes get zeroed
Xref: linus net.unix-wizards:14969 net.sources.bugs:790

In article <422@ukecc.UUCP> edward@ukecc.UUCP (Edward C. Bennett) writes:
>
>In article <979@kitty.UUCP>, larry@kitty.UUCP writes:
>>
>>        I don't claim to be a UNIX internals expert (I have enough trouble
>> writing I/O drivers :-) ), but don't most ports of UNIX zero disk blocks after
>> an unlink(2)?  As I seem to recall, unlink(2) is derived from unlink.s, which
>> is assembly language specific for the given machine.  And unlink.s contains
>> a routine _unlink which fills the disk blocks with .word defined as 0x0000.
>
>        When you unlink a file, the disk block addresses in the inode are
>zeroed, not the actual data blocks. Zeroing the inode is tantamount to
>'forgetting' where the data is actually stored. The 'forgotten' data
>blocks are added to the (top of the) free list to be used when adding data
>to the filesystem.
>        When the old data blocks are placed in the free list, their contents
>are unimportant. Zeroing the blocks would be a waste of time since whatever
>is there will be overwritten when the blocks are allocated to another file.
>This situation is identical to the malloc()/free() process. i.e. Space
>that has been malloc()ed will have data written into it. When this space
>is free()ed, the data in it is not altered and is useable until the next
>malloc().

Some unitory systems do, indeed, zero out disk blocks when de-allocated,
and similarly clear memory when freed.  Any system you sell to customers
with concerns about security will require this.  Check out DOD requirements
for secure systems in the "Department of Defense Trusted Computer
System Evaluation Criteria", publication CSC-STD-001-83 (my copy is
dated March 1985) for this and other interesting features...

Spooks aren't the only people who might desire disks & memory to be
cleansed when released, by the way.

* "unitory" is a trademark of absolutely nobody, and I like it!

-- 
Eric Black   "Garbage In, Gospel Out"
UUCP:        {sun,pyramid,hplabs,amdcad}!chronon!eric
WELL:        eblack
BIX:         eblack