RE: [Passwordsafe-devel] SecureAllocator

[James C. <Ja...@No...>]

	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