bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[patch #6797] shred option to use internal RNG


From: Steven Schveighoffer
Subject: [patch #6797] shred option to use internal RNG
Date: Tue, 31 Mar 2009 18:38:04 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8

URL:
  <http://savannah.gnu.org/patch/?6797>

                 Summary: shred option to use internal RNG
                 Project: GNU Core Utilities
            Submitted by: schveiguy
            Submitted on: Tue 31 Mar 2009 06:38:01 PM GMT
                Category: None
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Hi,

Our company is looking at using GNU shred to wipe customer data from RMA'd
drives in our systems.

One thing we have noticed is that shred runs about 90% slower if /dev/urandom
exists versus when it does not.  Researching this, it seems this is because
gl/lib/randread.c will use an internal RNG when null is passed into
randread_new, and /dev/urandom cannot be opened.

However, there is no way to *force* this behavior without removing
/dev/urandom (if you pass in an invalid file name, shred exits with an error).
 It is not important to us that the data isn't truly random, pseudorandom data
seeded the way it is done in shred is sufficient.  However, it is important
that the wiping of the drive completes in a reasonable time.  When not using
/dev/urandom, a single pass on a 160G drive on a system takes roughly an hour.
 When using /dev/urandom, it takes 28 hours.  Furthermore, since the CPU is
now the bottleneck, wiping several drives in parallel will not take advantage
of the ability to use multiple hard drive channels, the time will scale
roughly linearly.  When /dev/urandom is not used, the time to add an extra
drive increases by a couple minutes.  We regularly work with 750GB and 1TB
drives, and we plan on doing 2 passes, so you can see how this problem will
balloon out of reasonable range.

I would like to propose that an option be allowed to force usage of the
internal RNG.  This can be done by passing a filename into randread that is a
special filename, or by adding an argument to the randread create functions,
or by adding a different create function.

I've attached a patch that will allow for this in both randread.[ch] and a
special option in shred.c that forces the issue.  Note that this patch is on
the released 7.2 code, not the git directory structure.  The patch specifies a
blank filename is the special file that signals to use the internal RNG.  I
also added the option -i (--random-internal) to shred to signify this option.

Please let me know if you guys intend on accepting this patch or something
like it. if not, we will simply use it internally, otherwise, I'll download
the official version when you release it.

Thanks

-Steve



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Tue 31 Mar 2009 06:38:01 PM GMT  Name: shred.patch  Size: 3kB   By:
schveiguy

<http://savannah.gnu.org/patch/download.php?file_id=17845>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?6797>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]