Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Prevent SystemEntropyCache writes to disable drive spin-up System
Mac OS X 10.2.8 (6R73) runs on my iBook G3 800MHz. I use the "Put the hard disk to sleep when possible" setting in the Energy Saver preference pane. Something was making my hard drive spin up every 60 minutes. After some digging, I found that SecurityServer was writing to the file /private -> var -> db -> SystemEntropyCache. The following modification disables this write activity; do this at your own risk. You are preventing writing to a file owned by "system".

[robg adds: I concur - this hint is experimental and potentially dangerous. I haven't tested it, nor do I have any intention of doing so! However, if spurious disk activity really bothers you, read the rest of the hint for some advice on how to remove at least one source of activity...]

To stop writing to this file:
  1. Go into the Finder and use the menu command "get info->ownership and permissions". Change the the owner to the current user and allow read and write access on the directory /private/var/db and the file /private/var/db/SystemEntropyCache. Note the original settings before making changes.

  2. 2: Go into the terminal and type:
    cd /private/var/db
    rm SystemEntropyCache
    ln -s /dev/null SystemEntropyCache
  3. Change the permissions settings on the directory /private/var/db back to their original values. Also try to change the permissions settings on the new symbolic link called SystemEntropyCache back to their original values. In my case for that link, the get info dialog box would ignore attempts to change the owner.

My computer was tested after making these changes. It takes about 10 minutes for the spinning hard drive to spin down. It did not spin up after 2 hours 10 minutes, at which point I manually spun up the drive by opening a file. This was much better than having the hard drive automatically spinning up every 60 min.

Additional notes:
I noticed a process was writing to SystemEntropyCache by using the Finder search to find items of "all" visibility that were modified "today" on the boot volume. I locked the file and changed all of its permissions to "no access". The next hour when the SystemEntropyCache was due to be written, another process spun up the hard drive and updated the /private/var/log/secure.log file.

The secure.log file read (after changing permissions to allow reading):

Jan 13 10:59:42 xs-Computer /System/Library/CoreServices/SecurityServer:
 error writing entropy file /var/db/SystemEntropyCache

The computer would then try to write to the SystemEntropyCache every ten minutes. The log file was continuously updated with a new attempt every ten minutes, even after locking and preventing access to the log file. The hard drive did not seem to spin down at all.

Symbolically linking /private/var/db/SystemEntropyCache to /dev/null allows the computer to think it is writing to a file, but the hard drive is never activated because /dev/null is an empty space. Doing this does not break any security features of the OS that I know of. As normal, I was able to: log in, log out, authenticate to do things that require an admin user, and authenticate to access encrypted disk images.

I thought about symbolically linking to a real file with proper permissions on a ramdisk. However, I have found that one way to make the 10.2.8 Finder crash repeatedly is to use the Find command with visibility = all and date modified = today on the boot volume while more than one volume is mounted. I use the Finder Find on the boot volume a lot, so that was not an option for me.

Note that this is just one of many files on the hard drive that is periodically accessed by the computer. You should remove or disable other calendar apps (iCalhelper: inside iCal) and scheduling processes (cron) in order to make sure that your hard drive does not spin up. However, the preinstalled cron processes and iCal may be useful to you. Also note that the SecurityServer will try to write to the SystemEntropyCache every 60 minutes from when it was last successfully written to, not necessarily on the hour.

    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
 
[8,511 views]  

Prevent SystemEntropyCache writes to disable drive spin-up | 7 comments | Create New Account
Click here to return to the 'Prevent SystemEntropyCache writes to disable drive spin-up' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
WARNING: Security Risk
Authored by: dfe on Jan 26, '04 11:54:55AM

I would not do this if I were you because you are effectively getting rid of the entropy pool which is used for secure random number generation. In other words, any encryption keys your computer generates will not be very secure and will be much easier for an attacker to guess.

An X-bit encryption key is only as good as its source of random data. Computers don't generate random data too well and so they need a source for it. Sun actually has an interface to a Lava Lamp for generating entropy (I'm not joking). Most desktop systems use user actions such as the way you move your mouse or type on your keyboard to generate entropy.

I really don't understand what the big deal about having your drive spin up for a bit every hour is anyway. Perhaps you can change a defaults value and/or hexedit the binary to change the timeout value? I don't at all recommend linking the entropy cache to /dev/null though or making it unwritable so it is effectively useless.



[ Reply to This | # ]
Prevent SystemEntropyCache writes to disable drive spin-up
Authored by: sben on Jan 26, '04 12:14:32PM

I'd be careful with this one. I suspect, based on its name (though I don't know for certain) that SystemEntropyCache stores entropy (crypto-speak for "good randomness") that the system harvests over the course of time. If you have any reason to be using strong crypto, killing this file may have strange or bad side-effects -- e.g., generating keypairs might take a long time or break entirely.

It's even conceivable that things like connecting via SSL will break or be less secure -- but I don't know my SSL protocol well enough to be anything other than alarmist.



[ Reply to This | # ]
change disk spindown interval
Authored by: huzzam on Jan 26, '04 06:34:03PM

You could also just reduce the spindown time from 10 minutes to 1 minute, with this command:

sudo pmset -a spindown 1

That way you still get entropy for encryption purposes, & your HD will spin down one minute after it's done being used. Granted, it'll still start up every hour, but at least it'll turn back off faster. (This also helps 'book battery life, BTW, at the cost of a slight decrease in speed whenever the HD needs to wake up.)



[ Reply to This | # ]
Prevent SystemEntropyCache writes to disable drive spin-up
Authored by: _merlin on Jan 26, '04 07:15:42PM

The file we're talking about here is used to initialise the random number gerneators on startup (/dev/random and /dev/urandom).

While the machine is running, the random number generators are fed entropy directly from fluctuations in the kernel. When the machine starts up, entropy from SystemEntropyCache is loaded (presumably from the last time the machine was running).

So if you prevent writes to this file, your machine will not generate random numbers acceptably until at least a few minutes after startup.

Yes, this can cause security to suffer.



[ Reply to This | # ]
DANGEROUS
Authored by: paulio on Jan 27, '04 02:03:51PM

I have to agree with everybody here: This is NOT a good thing to do.



[ Reply to This | # ]
little .app for drive-spin up/down-stuff
Authored by: dirkstoop on Jan 28, '04 04:19:11AM
to check on your harddisk activity and setting timeouts for spindown try this one, part of the 10.3 devtools:
/Developer/Applications/Performance\ Tools/CHUD/Hardware\ Tools/SpindownHD.app


[ Reply to This | # ]
Security Risk, may be acceptable for certain environments
Authored by: iixhd on Jan 31, '04 10:56:24PM

If I could edit the post above I would. I made a mistake, and a very specific element of security is broken by linking SystemEntropyCache to /dev/null. However, I still recommend this hint to users who use their computers for personal, disconnected, work.

The system is able to generate random numbers to allow proper function even without the cache. The system stores the random numbers in memory; SystemEntropyCache is needed only at boot time (please see the other comments for reference). Note that the computer is able to regenerate the cache when the cache has been deleted. A single user computer should be secure if it is rebooted only when it is disconnected from the network. Use of the sleep function eliminates the need to reboot almost entirely.

Working comfortably without the pauses or sound caused by a HD spinning up and down is important to me. My system is not a public system in any way, and I am not running any optional services on startup. I spend most of my time in a word processor, not on a network, because I have dial-up at home. I recommend this hint to anybody that shares my computing environment. I do not recommend this hint to people who keep their computers in a service or public environment.

Thanks for all the feedback.



[ Reply to This | # ]