aboutsummaryrefslogtreecommitdiffstats
path: root/src/alloc/secmem.h
Commit message (Collapse)AuthorAgeFilesLines
* Add new helper zap which zeros a vector, clears it, and then callslloyd2012-11-291-0/+12
| | | | shrink_to_fit to actually deallocate memory.
* Add missing includes, noticed by OS X's Clang 4.1lloyd2012-10-301-0/+1
|
* Avoid integer overflows in calls to the mlock allocator, changing thelloyd2012-06-111-2/+2
| | | | | | | interface to more of a calloc style. Alignment remains set to the underlying type size. Increase the maximum mlock size to 512 KB.
* Remove a debug call in secmem.h.lloyd2012-05-221-4/+14
| | | | | | | | | Add a new mlock allocator which is far superior to the previous one both in terms of behavior (will lock exactly as much memory as we can actually mlock and will fall back to new/delete in all other cases), and much better and much simpler freelist than the old mem_pool code. Currently we only support systems with mmap+mlock, however it should be easy to extend to also support Windows VirtualLock if desired.
* Replace 0 and NULL pointer constants with nullptr. Also fix an oldlloyd2012-05-181-3/+4
| | | | style cast in secmem.h
* Fairly huge update that replaces the old secmem types with std::vectorlloyd2012-05-181-348/+63
| | | | | | using a custom allocator. Currently our allocator just does new/delete with a memset before deletion, and the mmap and mlock allocators have been removed.
* First step towards replacing the existing containers with std::vectorlloyd2012-05-181-11/+25
| | | | | | with a custom allocator; remove the 3 argument version of MemoryRegion::copy, replacing with freestanding buffer_insert function.
* Avoid a few maintainer mode flag warnings. Remove -Weffc++ from thelloyd2012-04-201-4/+5
| | | | | list of maintainer mode flags. It produces some very useful warnings, but also a lot of noisy junk that I really don't care about.
* The comments incorrectly described end as returning the last element,lloyd2012-04-091-4/+4
| | | | | rather than one past the end. Reported by Stuart Maclean on the mailing list.
* Fix -Wreorder warninglloyd2012-01-251-1/+1
|
* Use initializer list, make destructor virtuallloyd2012-01-061-2/+2
|
* Add std::swap specialization for memory containerslloyd2011-06-131-0/+10
|
* Fix the very basic operations for encoding and decoding alloyd2011-05-171-7/+0
| | | | | | | | | certificate policies extension, though it's really not supported at all. Remove test code from secmem.h Fix building the examples
* Remove MemoryRegion::set entirelylloyd2010-11-021-20/+34
|
* Make MemoryRegion::set protected, change all callerslloyd2010-10-291-8/+10
|
* s/u32bit/size_t/ in alloclloyd2010-10-121-23/+23
| | | | Also handle partial writes in alloc_mmap
* Use push_back for the single value += operatorlloyd2010-09-151-3/+1
|
* Remove all versions of MemoryRegion::append.lloyd2010-09-151-19/+43
| | | | | | | Add a push_back that takes a single argument ala std::vector For appending, provide some namespace level += operators - we can use this technique with either MemoryRegion or a std::vector.
* Completely remove the second parameter to SecureVector which specifieslloyd2010-09-141-13/+6
| | | | | | | | | | | | | | | | | | | | the initial/default length of the array, update all users to instead pass the value to the constructor. This is a old vestigal thing from a class (SecureBuffer) that used this compile-time constant in order to store the values in an array. However this was changed way back in 2002 to use the same allocator hooks as the rest of the containers, so the only advantage to using the length field was that the initial length was set and didn't have to be set in the constructor which was midly convenient. However this directly conflicts with the desire to be able to (eventually) use std::vector with a custom allocator, since of course vector doesn't support this. Fortunately almost all of the uses are in classes which have only a single constructor, so there is little to no duplication by instead initializing the size in the constructor.
* Split up definitions so it is easer to remove functions I want to remove.lloyd2010-09-131-19/+21
| | | | | | Avoid using using directives in MemoryVector and SecureVector to bring things into scope; it brings them into public scope even if they are protected which is not desirable. Instead disambiguate using this->func()
* Don't expose init (protected) with a using directivelloyd2010-09-131-8/+6
|
* Remove constructors of MemoryVector and SecureVector that took twolloyd2010-09-131-18/+0
| | | | MemoryRegions and concatenated them.
* More vector->pointer conversion removals.lloyd2010-09-131-0/+7
| | | | | | | | | | | Add RandomNumberGenerator::random_vec, which takes an length n and returns a new SecureVector with randomized contents of that size. This nicely covers most of the cases where randomize was being called on a vector, and is a little cleaner in the code as well, instead of vec.resize(length); rng.randomize(&vec[0], vec.size()); we just write vec = rng.random_vec(length);
* Anywhere where we use MemoryRegion::begin to get access to the raw pointerlloyd2010-09-131-26/+27
| | | | | representation (rather than in an interator context), instead use &buf[0], which works for both MemoryRegion and std::vector
* Use a true lexicographic ordering in MemoryRegion::operator<lloyd2010-09-091-8/+11
|
* Rename MemoryRegion::destroy to MemoryRegion::clear to match STLlloyd2010-09-081-1/+1
|
* Big, invasive but mostly automated change, with a further attempt atlloyd2010-09-071-20/+26
| | | | | | | | | | | | | | harmonising MemoryRegion with std::vector: The MemoryRegion::clear() function would zeroise the buffer, but keep the memory allocated and the size unchanged. This is very different from STL's clear(), which is basically the equivalent to what is called destroy() in MemoryRegion. So to be able to replace MemoryRegion with a std::vector, we have to rename destroy() to clear() and we have to expose the current functionality of clear() in some other way, since vector doesn't support this operation. Do so by adding a global function named zeroise() which takes a MemoryRegion which is zeroed. Remove clear() to ensure all callers are updated.
* Realization while thinking about the recently added truncate: in a STLlloyd2010-09-071-40/+10
| | | | | | | | | | | | | | | | | | container like vector, truncate is simply resize, but what MemoryRegion called resize will zap the entire contents, and then what was resize was called grow_to. This is really problematic in terms of the goal of replacing MemoryRegion with a vector with a custom allocator. In this checkin: - Remove MemoryRegion::grow_to and MemoryRegion::truncate - Change the semantics of MemoryRegion::resize to change the size while keeping any current contents intact (up to the new size), zero initializing any new values. Unrelated, just noticed the lack while I was in there, add a version of CryptoBox::decrypt taking a std::string for the input.
* Add a simple function to MemoryRegion to truncate to a specified size.lloyd2010-09-031-0/+10
| | | | Required by the hex decoder.
* Clang fixlloyd2010-08-081-0/+1
|
* Fix constructorlloyd2010-07-091-1/+1
|
* Argh: SecureVector's constructor needs to behave differentlylloyd2010-07-071-2/+14
| | | | | | | | | | | | | | depending on if INITIAL_LEN is non-zero. Normal semantics are the vector will change size based on whatever it is constructed with, but that's bad in cases like SecureVector<byte, 4> val(buffer, 3); which in the past would be a 4 valued thing with 3 elements set and one zero trailing. (This construct showed up in base64 and possibly elsewhere). If INITIAL_LEN is set, use copy instead so the length does not change. C++0x cannot come soon enough.
* Doxygenlloyd2010-06-211-0/+9
|
* Replace "@return a blah" and "@return the blah" with just "@return blah"lloyd2010-06-161-10/+10
|
* Fix a few hundred Doxygen warningslloyd2010-06-151-2/+2
|
* Add a couple of small patches from Thomas Capricelli <[email protected]>lloyd2010-05-211-8/+16
| | | | that enable botan to be built under the clang C++ compiler.
* Rename SecureVector::L param to INITIAL_LEN so as to be somewhat obvious as ↵lloyd2010-03-231-2/+3
| | | | to meaning
* Remove SecureBuffer, which is the fixed-size variant of SecureVector.lloyd2010-03-231-38/+2
| | | | | | | | | | | | | | Add a second template param to SecureVector which specifies the initial length. Change all callers to be SecureVector instead of SecureBuffer. This can go away in C++0x, once compilers implement N2712 ("Non-static data member initializers"), and we can just write code as SecureVector<byte> P{18}; instead
* Remove reference to no-longer existing function in docslloyd2010-03-221-6/+2
|
* Fix Doxygen comment for grow_tolloyd2010-03-221-4/+6
|
* Guard call to the allocator in deallocate() by checking if the alloclloyd2010-03-101-1/+1
| | | | | | | | | | | | | | | | | | pointer was actually set. Otherwise, the following problem could occur if an allocator could not be found: init() will call Allocator::get, which throws an exception init() is called from the constructor of the subclasses (MemoryVector, etc) Since the constructor of MemoryRegion has already finished, its destructor will be called. ~MemoryRegion will call deallocate() deallocate() will then access a NULL pointer By guarding the call, the exception is propagated correctly.
* Rename/remove some secmem member variables for better matching with STLlloyd2009-11-171-22/+15
| | | | | | | | containers (specifically vector). Rename is_empty to empty Remove has_items Rename create to resize
* Remove some Doxygen commentslloyd2009-11-171-8/+2
|
* Move some files around to break up dependencies between directorieslloyd2009-07-161-0/+438
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 14:50:40 +0000