[RFC PATCH] enable configurable SECMEM_BUFFER_SIZE
wk at gnupg.org
Fri Nov 24 10:59:57 CET 2017
On Thu, 23 Nov 2017 10:43, Amul.Shah at fisglobal.com said:
> but xmalloc allocations can use the overflow pool(s). This means that every
> xmalloc allocation consumes the limited main pool. Once the mainpool is
> exhausted, xmalloc allocations continue, but secure mallocs stop.
To clarify: that is xmalloc_secure. I meanwhile implemented a Libgcrypt
feature to allow expanding the secmem pool. It is also possible to
advice Libcgrypt on the size of the newly allocated pools. The latter
can be important because all calls to free need to check whether that
free is affects the secmem pool - this is done by comparing the tagnges
of all secmem pools - many pools obviously take a little bit longer.
gpg-agent has a new option --auto-expand-secmem to enable this features.
This is currently in the 2.2 branch but will soon be merged into master.
> [amul:2] Currently, when the secure malloc fails, libgcrypt reports an
> ENOMEM. That is not accurate as ENOMEM would imply that the process
> cannot allocate more memory. The problem is that there is no secure
> memory available to service the request. libgcrypt should report a
> different error.
ENOMEM does not mean it is not possible to allocate more memory. It
should always been viewed as a temporary error code. Right a different
error code would be useful but has the disadvantgae that all ENOMEM
handling code needs to be adjusted. With the auto-expand-secmem feature
any ENOMEM will anyway be a "real" ENOMEM.
> [amul:2] I updated the bug with the test script that I used to expose the problem.
Thanks. All as been pushed and a Libgcrypt 1.8.2 release can be done
soonish. GnuPG 2.2.4 needs to wait a few weeks.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 227 bytes
Desc: not available
More information about the Gnupg-devel