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

Matthew Summers matthew.summers at syapse.com
Sat Oct 21 06:20:07 CEST 2017


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>


More information about the Gnupg-devel mailing list