Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576

[Werner Koch]

On Fri, 20 Oct 2017 23:42, matthew.summers at syapse.com said:

> I would like to point out that this creates an issue on systems with the
>> max locked memory size (ulimit -l) is limited to 64k:
>> gpg: Warning: using insecure memory!
>> mlock(0x7f5814308000, 262144) = -1 ENOMEM (Cannot allocate memory)
>> Thus exposing private key material to being swapped out to permanent
>> storage. I am not sure if a mere warning is sufficient here.

dkg already explained the problem using mlock to avoid swapping/paging
out memory.  That mechanism likely did what it was expected do when I
introduced it 20 years ago.  Nowadays we should more care about
hibernation [1] than about swapped memory with sensitive data.

Swapping is anyway rare for running processes.  An idle gpg-agent has
only one sensitive memory area of 16 bytes which could - with some work
- also be moved to the TPM or an NVRAM.  The real solution, which will
also protect other processes with sensitive data, is an encrypted swap
space.

Note also that increasing the secmem size is not anymore needed with
current GnuPG versions.  The secmem area is increased on demand (but this
new memory areas are anyway not mlock-ed).

The reason why we still have the secmem is to wipe out an allocated area
with the call to free() and to, to a minor extend, to know whether we
are working on sensitive data.


Shalom-Salam,

   Werner


[1] Do you call "gpgconf --reload gpg-agent" before you hibernate?
-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20171021/09ae9046/attachment.sig>