[RFC PATCH] enable configurable SECMEM_BUFFER_SIZE

[Shah, Amul]

-----Original Message-----
From: Werner Koch [mailto:wk at gnupg.org] Sent: Wednesday, November 22, 2017 8:46 PM

>On Wed, 22 Nov 2017 16:23, matthew.summers at syapse.com said:
>
>> We have a lot of active connections to the gpg-agent using a single
>> private key. I outlined our use case in more detail here [1].
>
>Frankly I followed the discussion in June only briefly.  Thanks for pointing
>me again to this.
>
>> We are enlarging the secmem_buffer using the patch attached
>> previously. We are determining the size using a simple empirical test
>
>I would accept this as a quick workaround but we need a better solution.
>
>> configurable, per the patch. It is perhaps notable that we needed to
>> go from ~1mb to 2mb when moving from 2.1.23 to 2.2.0.
>
>I just checked the commits between tehse release and I can't see anything
>which shoudl affect the allocation pattern.  This only shows how fragile the
>fixed memory approach is.

>On Wed, 22 Nov 2017 14:40, Amul.Shah at fisglobal.com said:
>As dkg already mentioned, the protection against swapping out sensitive data
>can nowdays better achieved by using encrypted swap.  Along with no way to
>protect against suspend/resume, I view the mlock more of a historical feature.

[amul:2] I see two issues with how libgcrypt treats xmalloc style allocations and
secure malloc style allocations.

[amul:2] Secure malloc style allocations are currently limited to the mainpool,
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.

[amul:2] An ugly solution would move lines 610-615 below line 666. This would
have the negative effect of allocating two memory pool sized chunks which could
cause problems on memory strapped systems.

    576 _gcry_secmem_malloc_internal (size_t size, int xhint)
    ...
    610   mb = mb_get_new (pool, (memblock_t *) pool->mem, size);
    611   if (mb)
    612     {
    613       stats_update (pool, mb->size, 0);
    614       return &mb->aligned.c;
    615     }
    616
    617   /* If we are called from xmalloc style function resort to the
    618    * overflow pools to return memory.  We don't do this in FIPS mode,
    619    * though. */
    620   if (xhint && !fips_mode ())
    ...
    666     }
    667
    668   return NULL;
    669 }

[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.

[amul:2] If we implement option 2 below, these points are moot.


>> [amul] I agree with your assessment of option #1. I think, however,
>> that there is a third option. In its current form, the gpg-agent
>> accepts every request and spawns a thread to handle it. There is no
>> limit on the rate at which it accepts connections. Other than crudely
>> limiting the thread count, I don't know of a good way to slew the
>> agent. Do you have any suggestions? Additionally, I have not seen any
>> timeouts in gpg/libassuan when communicating with the gpg-agent.
>
>Limiting the number of concurrent connections to gpg-agent is a useful feature
>but it requires more thought and is unlikley to make it into 2.2 anytime soon.
>I opened a ticket at https://dev.gnupg.org/T3529 .

[amul:2] Thank you for creating the bug. Given the trouble that a buggy agent
can cause, I concur!

>> [amul] If I were to prepare a patch for option #2, assuming it passes
>> a review and conforms to the coding standards, would it be acceptable?
>
>We should try this.  Let me implement something for testing.
>https://dev.gnupg.org/T3530

[amul:2] I updated the bug with the test script that I used to expose the problem.

[amul:2] While I have you reading my mail, let me thank you and the others
involved in producing this useful suite of tools. I appreciate your time and
effort.
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.