[RFC PATCH] enable configurable SECMEM_BUFFER_SIZE [WAS Re: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576]

[Matthew Summers]

Please see the attached patch, I'll also include it in the body since
it's very short.

What this does is change configure.ac to allow the end user to choose
a value for secmem, or accept one of the two existing values.
Following `autoreconf` on STABLE-BRANCH-2-2 with this patch applied,
the following options are available:
./configure --enable-large-secmem        # uses default 64k
./configure --enable-large-secmem=no     # uses 32k value
./configure --enable-large-secmem=SIZE   # can input any number > 32k
(probably could use an upper bound too, perhaps)

I attempted to follow the style and structure used for
PK_UID_CACHE_SIZE via the --enable-key-cache option.

If you prefer, I can make a pull request against github



>From 5fd1e60f65048b3d0ccfd309f8c195e70d9fd027 Mon Sep 17 00:00:00 2001
From: Matthew Summers <matthew.summers at syapse.com>
Date: Fri, 20 Oct 2017 23:14:51 -0500
Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE

---
configure.ac | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/configure.ac b/configure.ac
index 70c122615..46cfd855a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -236,20 +236,30 @@ AC_ARG_ENABLE(selinux-support,
AC_MSG_RESULT($selinux_support)


-AC_MSG_CHECKING([whether to allocate extra secure memory])
+#
+# Check for size of secure memory allocation. If on Linux and if >
65536, it may be
+# necessary to increase max locked memory, ulimit -l to accommodate.
+#
+AC_MSG_CHECKING([for the size of the secure memory allocation])
AC_ARG_ENABLE(large-secmem,
-              AC_HELP_STRING([--enable-large-secmem],
-                             [allocate extra secure memory]),
-              large_secmem=$enableval, large_secmem=no)
-AC_MSG_RESULT($large_secmem)
-if test "$large_secmem" = yes ; then
-   SECMEM_BUFFER_SIZE=65536
-else
-   SECMEM_BUFFER_SIZE=32768
+              AC_HELP_STRING([--enable-large-secmem=SIZE],
+                             [set secure memory allocation to SIZE
(default 65536)]),,enableval=65536)
+if test "$enableval" = "no"; then
+  enableval=32768
+elif test "$enableval" = "yes" || test "$enableval" = ""; then
+  enableval=65536
fi
-AC_DEFINE_UNQUOTED(SECMEM_BUFFER_SIZE,$SECMEM_BUFFER_SIZE,
+changequote(,)dnl
+secmem_buffer_size=`echo "$enableval" | sed 's/[A-Za-z]//g'`
+changequote([,])dnl
+if test "$enableval" != "$secmem_buffer_size" || test
"$secmem_buffer_size" -lt 32768; then
+   AC_MSG_ERROR([invalid large-secmem buffersize])
+fi
+AC_MSG_RESULT($secmem_buffer_size)
+AC_DEFINE_UNQUOTED(SECMEM_BUFFER_SIZE,$secmem_buffer_size,
                   [Size of secure memory buffer])

+
AC_MSG_CHECKING([whether to enable trust models])
AC_ARG_ENABLE(trust-models,
              AC_HELP_STRING([--disable-trust-models],
--
2.13.6

On Fri, Oct 20, 2017 at 4:42 PM, Matthew Summers
<matthew.summers at syapse.com> wrote:
>
> On Fri, Oct 13, 2017 at 8:00 AM, Andreas Stieger <astieger at suse.com> wrote:
>>
>> Hello,
>>
>>
>> On 10/13/2017 06:44 AM, Matthew Summers wrote:
>> > This is following up on an issue that started around in the 2.1.17
>> > days, and I have been carrying a small patch addressing this for my
>> > team since we figured it out. This is all documented in an earlier set
>> > of threads to this ML.
>> >
>> > Would you consider increasing SECMEM_BUFFER_SIZE to 1048576 in the
>> > case where the configure option `large_secmem` = yes, please?
>> >
>> > The patch itself is a super trivial in both configure and/or
>> > configure.ac <http://configure.ac>.
>> >
>>
>> You haven't explicitly referenced the rationale for this. Is this about
>> RSA keys in excession of 4096 bits?
>
>
> Yes, we are using 4096bit RSA keys, and generally recommend/require that internally at this stage in the game.
>
> Here is the start of the 1st thread: https://lists.gnutls.org/pipermail/gnupg-devel/2017-January/032486.html
>
> Here is the start of the 2nd thread: https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032894.html
>
>> 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.
>
>
> I have been adjusting this ulimit as a matter of course, so it's not been an issue. It appears that 64k 'default' max locked memory and/or max memory size may vary from distro to disto as well.
>
> I would like to stress that this is not a theoretical problem we are dealing with, but rather an issue that were we not able to patch the SECMEM_BUFFER_SIZE we would not be able to use GnuPG to protect sensitive data as we currently do (via saltstack).
>
> What about an extra arg in configure.ac that would let us either specify the SECMEM_BUFFER_SIZE or set it with `--extra-large-secmem`? I'd be happy to provide a patch for that, of course.
>
> Thanks,
> Matt Summers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-enable-configurable-SECMEM_BUFFER_SIZE.patch
Type: text/x-patch
Size: 2068 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20171020/3246428d/attachment.bin>