Follow-up to Crashes with gpg-agent 2.1.18
matthew.summers at syapse.com
Mon Jun 5 05:35:59 CEST 2017
On Thu, Jun 1, 2017 at 6:31 PM, NIIBE Yutaka <gniibe at fsij.org> wrote:
> The limitation comes from the fact we only have 32KB or 64KB for secure
> memory; The region is mlock(2)-ed to avoid data transfer to swap
> storage. ... even if we have multiple giga bytes of memory.
Hi, huge thanks for the effort here! I can see a definite improvement
in stability with the newly released libs.
I ask a question of you:
This mlock(2)'d region, is this something that could be made a
run-time setting or even compile time changed in configure? I would
be keenly interested to know if allocating a larger mlock(2)'d region
would address the problem I have.
I understand that it's often needed and desirable to restrict memory
regions to smaller sizes. It's probably true that for most users,
highly parallelized decryption operations are rare. However, it's not
difficult to demonstrate use cases where it's important to handle
highly parallelized requests to gpg-agent. At present, if I make too
many calls too fast to gpg-agent, I can crash it very easily.
Maybe I can figure out how to set this AC_DEFINE HAVE_BROKEN_MLOCK,
seen in acinclude.m4, Presumably, this disables the secure region.
I am already building with `--enable-large-secmem` so I assume it's at 64kb now.
Anyway, thanks again!
More information about the Gnupg-devel