[PATCH] Erase memory before freeing.

Justus Winter justus at g10code.com
Tue Aug 2 09:51:42 CEST 2016


Hi :)

Ben Kibbey <bjk at luxsci.net> writes:

> On Mon, Aug 01, 2016 at 12:15:31PM +0200, Justus Winter wrote:
>> > +static struct mem_item_s *memlist;
>> 
>> I wonder if a list is the right data structure.  Linear lookup time
>> feels expensive.
>
> I thought this too. I haven't done any benchmarks but the list is
> prepended to so it comforms with most de/allocations as LIFO. I also
> don't khow how else to do it without requiring a realloc of a mem_item_s
> which would corrupt pointers for .next. Any ideas?

Actually, if you allocate both the length and the actual data in one
chunk, you don't need an extra data structure at all and get constant
time lookups, i.e.:

struct chunk {
size_t size;
char data[0];
};

then on free(p) you do

chunk *c = p - offsetof(struct chunk, data);

>> > +    {
>> > +      UNLOCK (memlist_lock);
>> > +      return _gpgme_assuan_malloc (n);
>> > +    }
>> > +
>> > +  tmp = _gpgme_assuan_malloc (n);
>> 
>> Can't we just use realloc here?  And if not for some reason, please
>> don't look newitem up like this, instead create a variant of
>> _gpgme_assuan_malloc that returns the item.
>
> Needed to wipe item->data. Not sure how to do both wiping item->data
> and realloc'ing.

Yeah, I understand now.

> Attached is the revised patch. Suggestions welcome. Also, Werner
> mentioned some time ago he'd like to add allocaters to gpg-error to
> replace the "hooks" in libassuan and others. Not sure if anyone has
> started that or not.

I don't know that either.


Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160802/6e2aa298/attachment-0001.sig>


More information about the Gnupg-devel mailing list