Re: [Passwordsafe-devel] SecureAllocator

[Edward E. <pas...@ed...>]

Thanks for the information.  I want to get my code to run on VC7 but I 
haven't had a copy to mess around with myself yet.  I will fold in 
those changes soon.

You can still link/use the allocator without boost threads if you 
stick to the single-threaded version.  Just pass the NoLocking thread 
policy as the LockPolicy parameter to SecureAllocator.

Actually, this will still require linking to Boost threads for the 
mutex in PolicyHolder (misc.h); I suppose I should fix that so the 
single-threaded version doesn't need Boost threads.  In the meantime, 
you can comment out line 37 in misc.h:

     typename MutexLocking<PolicyHolder<Policy> >::Lock lock;

and change line 27 from
     typedef MutexLocking<Policy*>::VolatileType     PtrType;
to
     typedef Policy*     PtrType;

I believe that should eliminate the need to link to Boost, although 
you will still need their header files.  I should fix that as well.

Thanks!

Edward


James Curran wrote:
> 	For fun, I ran your code through VC7.   It realize a few
> interesting things.
> SecureAllocator::max_size() & SecureAllocator::getAllocate() should be
> const.  (I'm kinda curious how that got past VC6).  Further, all
> references to 
> 	#if define (_MSC_VER)
> Can be replaced by 
> 	#if defined(_MSC_VER) && _MSC_VER <= 1200
> (ie, if VC6 or earlier)-- except for the one around
> SecureAllocator::allocate().  That still has the bad signature.  (Which
> also means that with VC7, you don't need NoSwapHeap.cpp anymore)
> 
> 	I don't have the boost threading library available, so I
> couldn't link the code.
> 
>     Truth, 
>      James Curran
> 
> 
> -----Original Message-----
> From: pas...@li...
> [mailto:pas...@li...] On Behalf Of
> Edward Elliott
> Sent: Friday, June 21, 2002 12:39 AM
> To: 'PasswordSafe Development'
> Subject: Re: [Passwordsafe-devel] SecureAllocator
> 
> 
> Nice job, James.
> 
> First, so this information doesn't get buried in the post, here is the 
> link to my SecureAllocator code:
> 
> http://www.eddeye.net/src/secalloc.html
> 
> It addresses all of the issues below.  I have also written a detailed
> article on the design and usage of my allocator, which is currently
> being considered for publication in the C/C++ User's Journal.  If anyone
> is interested, I can see about getting you an advance copy of the
> article.  Meanwhile, the code is well commented and the readme file
> covers its usage.
> 
> Allocators have many subtle issues.  I'd just like to make a few 
> observations on James's code:
> 
> 1) Why subclass std::allocator?  Reimplementing all of std::allocator's
> functions can be done in a few lines, and avoids any problems with
> subclassing.  Notably, the C++ Standard says if two allocators compare
> equal, they may be used to deallocate each other's memory.  When
> std::allocator's operator= is called with your SecureAllocator as an
> argument, this will happen and you lose all the protections.  Easy
> enough to fix.
> 
> 2) Since you don't reimplement the rebind nested template each allocator
> must provide, SecureAllocator inherits std::allocators. for Whenever a
> container uses rebind to obtain an allocator of a type other than the
> container value type (T), it will obtain a std::allocator and not a
> SecureAllocator.  This occurs with every container other than vectors
> and strings; lists, maps, and sets all store values in their own tree or
> node structure type.  Again, easy to fix.
> 
> 3) Clearing memory before releasing it is not the only issue.  In fact,
> I seem to recall reading somewhere that some Windows OSes zero out all
> memory pages that are returned to the system (though I could be wrong
> about this).  In any case, what worries me more is paging out of keys
> and passwords to the swap file, where they can remain on disk much
> longer than the lifetime of the program.  Some more work to add, but
> doable.
> 
> 4) Each STL has its own quirks with regards to allocator usage.  For
> example, the STL which ships with MSVC6 calls an (undocumented) method
> in an allocator, _Charalloc, to allocate memory for types other than T
> (the container value type).  MSVC doesn't use the rebind template as
> prescribed by the C++ Standard because they haven't implement nested
> templates yet.  Easy to fix.
> 
> 5) Likewise, the popular STLPort implementation, which I use with MSVC,
> uses some external templated functions to perform rebinding on compilers
> that don't support nested templates (a much cleaner solution than
> Microsoft's hack).  If you plan to use the allocator with STLPort, these
> will have to be added.
> 
> I might add that in addition to solving these issues, my allocator
> - is well-tested, having been used in several projects for many months
>     with success.
> - is cross-platform, having been tested with MSVC and gcc on 32-bit
>     Windows, and gcc on linux. it should port easily to any other unix.
> - uses policy classes for easy extensibility.
> - is thread safe.
> 
> I leave it to others to decide what use, if any, to make of my code.
> 
> 
> Edward Elliott
> 
> BTW, I apologize for sending several copies of my last post.  I was
> having trouble with my mail server and thought the first two submissions
> failed.  Nevertheless, I am embarassed by the slipup.
> 
> 
> 
> 
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Passwordsafe-devel mailing list Pas...@li...
> https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
> 
> 
> 
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Passwordsafe-devel mailing list
> Pas...@li...
> https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
>