Bugzilla – Bug 1137307
gpg unusable
Last modified: 2021-02-22 20:15:22 UTC
On a fresh installed openSUSE Leap 15.1 machine gpg is not usable: gross@jglap:~> gpg --help gpg: Ohhhh jeeee: secure memory is disabled Abgebrochen (Speicherabzug geschrieben) Installation has been performed basically with default settings, for performance reasons the kernel parameter "mitigations=off" is being used.
(In reply to Jürgen Groß from comment #0) > On a fresh installed openSUSE Leap 15.1 machine gpg is not usable: > > gross@jglap:~> gpg --help > gpg: Ohhhh jeeee: secure memory is disabled > Abgebrochen (Speicherabzug geschrieben) > > Installation has been performed basically with default settings, for > performance reasons the kernel parameter "mitigations=off" is being used. The gpg2 command is usable except when it runs FIPS checks, i.e. when using the --help flag. Same problem in SLE-15 but not present in TW. Here is the bt: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff6963741 in __GI_abort () at abort.c:79 #2 0x00005555555f8699 in do_logv (level=6, ignore_arg_ptr=<optimized out>, extrastring=0x0, prefmt=<optimized out>, fmt=<optimized out>, arg_ptr=0x7fffffffd480) at logging.c:859 #3 0x00007ffff73769df in _gcry_logv (level=level@entry=50, fmt=fmt@entry=0x7ffff7441f2c "secure memory is disabled", arg_ptr=arg_ptr@entry=0x7fffffffd480) at misc.c:121 #4 0x00007ffff7376ee1 in _gcry_log_bug (fmt=fmt@entry=0x7ffff7441f2c "secure memory is disabled") at misc.c:229 #5 0x00007ffff737da2c in init_pool (pool=0x7ffff7683e80 <mainpool>, n=<optimized out>) at secmem.c:397 #6 _gcry_secmem_init_internal (n=<optimized out>) at secmem.c:562 #7 0x00007ffff737db2a in _gcry_secmem_malloc_internal (size=size@entry=256, xhint=xhint@entry=1) at secmem.c:606 #8 0x00007ffff737de31 in _gcry_secmem_malloc (size=256, xhint=1) at secmem.c:700 #9 0x00007ffff737d226 in _gcry_private_malloc_secure (n=<optimized out>, xhint=<optimized out>) at stdmem.c:148 #10 0x00007ffff7377c2a in do_malloc (n=n@entry=256, flags=flags@entry=3, mem=mem@entry=0x7fffffffd5e0) at global.c:923 #11 0x00007ffff73792f2 in _gcry_malloc_secure_core (xhint=1, n=256) at global.c:962 #12 _gcry_xmalloc_secure (n=n@entry=256) at global.c:1161 #13 0x00007ffff743cffe in _gcry_mpi_alloc_limb_space (nlimbs=nlimbs@entry=32, secure=secure@entry=1) at mpiutil.c:123 #14 0x00007ffff743d1a7 in _gcry_mpi_alloc_secure (nlimbs=nlimbs@entry=32) at mpiutil.c:106 #15 0x00007ffff743dbeb in _gcry_mpi_snew (nbits=nbits@entry=2048) at mpiutil.c:629 #16 0x00007ffff73ff9b3 in secret_blinded (output=0x55555585c100, input=0x55555585b5b0, sk=0x7fffffffd6c0, nbits=2048) at rsa.c:1105 #17 0x00007ffff73ffc8d in rsa_sign (r_sig=0x7fffffffd7d8, s_data=<optimized out>, keyparms=0x55555585cfe0) at rsa.c:1513 #18 0x00007ffff7389e5f in _gcry_pk_sign (r_sig=r_sig@entry=0x7fffffffd7d8, s_hash=0x55555585dd00, s_skey=<optimized out>) at pubkey.c:430 #19 0x00007ffff73fead1 in selftest_sign_2048 (pkey=0x55555585bcf0, skey=<optimized out>) at rsa.c:1749 #20 0x00007ffff73fecbe in selftests_rsa (report=0x7ffff737e3a0 <reporter>) at rsa.c:1974 #21 run_selftests (algo=<optimized out>, extended=<optimized out>, report=0x7ffff737e3a0 <reporter>) at rsa.c:2007 #22 0x00007ffff738abc3 in _gcry_pk_selftest (algo=<optimized out>, algo@entry=1, extended=extended@entry=0, report=report@entry=0x7ffff737e3a0 <reporter>) at pubkey.c:955 #23 0x00007ffff737f3b0 in run_pubkey_selftests (extended=<optimized out>) at fips.c:628 #24 _gcry_fips_run_selftests (extended=extended@entry=0) at fips.c:818 #25 0x00007ffff737f48c in _gcry_fips_is_operational () at fips.c:448 #26 0x00007ffff7375d39 in gcry_pk_algo_info (algo=1, what=what@entry=8, buffer=buffer@entry=0x0, nbytes=nbytes@entry=0x7fffffffdb20) at visibility.c:1041 #27 0x0000555555592b5c in openpgp_pk_test_algo2 (algo=<optimized out>, use=<optimized out>) at misc.c:647 #28 0x000055555556bb85 in build_list (text=0x55555560f4a3 "Pubkey: ", letter=1 '\001', mapf=0x55555556bac0 <build_list_pk_algo_name>, chkf=0x55555556baa0 <build_list_pk_test_algo>) at gpg.c:1132 #29 0x000055555556bf96 in my_strusage (level=<optimized out>) at gpg.c:1080 #30 0x00005555555f5c91 in strusage (level=level@entry=34) at argparse.c:1544 #31 0x00005555555f5e77 in show_version () at argparse.c:1478 #32 0x00005555555f5eca in show_help (opts=0x55555584a0c0 <opts>, flags=32833) at argparse.c:1302 #33 0x00005555555f6f66 in arg_parse (arg=<optimized out>, opts=0x55555584a0c0 <opts>) at argparse.c:1018 #34 0x00005555555646e7 in main (argc=<optimized out>, argv=<optimized out>) at gpg.c:2407 Looks like the problem is in libgcrypt, adding Vitezslav and Jason in CC.
Hmm, not sure yet! Here is the valgrind output. ==26975== Command: gpg2 --help --leak-check=full ==26975== gpg: Ohhhh jeeee: secure memory is disabled ==26975== ==26975== Process terminating with default action of signal 6 (SIGABRT) ==26975== at 0x5F62160: raise (raise.c:51) ==26975== by 0x5F63740: abort (abort.c:79) ==26975== by 0x1AC698: do_logv (logging.c:859) ==26975== by 0x559B9DE: _gcry_logv (misc.c:121) ==26975== by 0x559BEE0: _gcry_log_bug (misc.c:229) ==26975== by 0x55A2A2B: init_pool (secmem.c:397) ==26975== by 0x55A2A2B: _gcry_secmem_init_internal (secmem.c:562) ==26975== by 0x55A2B29: _gcry_secmem_malloc_internal (secmem.c:606) ==26975== by 0x55A2E30: _gcry_secmem_malloc (secmem.c:700) ==26975== by 0x559CC29: do_malloc (global.c:923) ==26975== by 0x559E2F1: _gcry_malloc_secure_core (global.c:962) ==26975== by 0x559E2F1: _gcry_xmalloc_secure (global.c:1161) ==26975== by 0x5661FFD: _gcry_mpi_alloc_limb_space (mpiutil.c:123) ==26975== by 0x56621A6: _gcry_mpi_alloc_secure (mpiutil.c:106) ==26975== ==26975== HEAP SUMMARY: ==26975== in use at exit: 56,535 bytes in 62 blocks ==26975== total heap usage: 220 allocs, 158 frees, 156,009 bytes allocated ==26975== ==26975== LEAK SUMMARY: ==26975== definitely lost: 0 bytes in 0 blocks ==26975== indirectly lost: 0 bytes in 0 blocks ==26975== possibly lost: 0 bytes in 0 blocks ==26975== still reachable: 56,535 bytes in 62 blocks ==26975== suppressed: 0 bytes in 0 blocks
*** Bug 1138171 has been marked as a duplicate of this bug. ***
*** Bug 1137963 has been marked as a duplicate of this bug. ***
Here's where I am at so far with this. First, I had guessed that this problem was related to the libotr issue I worked on earlier; I was wrong. More accurately, it is related to the separation of the fips testing functions that we did earlier. Before our changes, all libgcrypt tests were performed during the first invocation of _gcry_fips_is_operational(), called by the constructor. As part of those tests a page of secure memory is created. Then as part of the "--help" procedure the secure memory is disabled and the help text is printed. This is the expected outcome. After our changes, some tests are performed during the first invocation of _gcry_fips_is_operational() by the constructor, and the rest are to be performed by the second invocation of _gcry_fips_is_operational() when the libgcrypt library is first used. Our error is that the tests are performed too late; our code now disables the secure memory before it executes the fips tests and then, as part of the fips tests, tries to initialize it. Trying to initialize the secure memory after it has been disabled is an error, which we see here. That's my diagnosis. My prognosis is to add _gcry_fips_is_operational() to the beginning of gcry_control(). I'm trying that now.
The problem is when gpg was calling a libgcrypt function intending to simply drop the setuid privileges. One of the parameters passed was originally ignored, so a zero was used. After our fips change in libgcrypt that zero came to mean "disable secure memory". So gpg was patched to request a small amount of secure memory to keep it from being disabled. Patch has been submitted.
(In reply to Jason Sikes from comment #7) > The problem is when gpg was calling a libgcrypt function intending to simply > drop the setuid privileges. One of the parameters passed was originally > ignored, so a zero was used. > > After our fips change in libgcrypt that zero came to mean "disable secure > memory". So gpg was patched to request a small amount of secure memory to > keep it from being disabled. > > Patch has been submitted. Revised version gpg2-2.2.16-243.1.x86_64 from https://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/ works for me. Thx.
(In reply to Frank Kruger from comment #8) > Revised version gpg2-2.2.16-243.1.x86_64 from > https://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/ > works for me. Thx. As mentioned in comment#1, the version you mention was not affected. Leap 15.1 and SLE-15 versions should be tested instead.
(In reply to Pedro Monreal Gonzalez from comment #9) > (In reply to Frank Kruger from comment #8) > > Revised version gpg2-2.2.16-243.1.x86_64 from > > https://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/ > > works for me. Thx. > > As mentioned in comment#1, the version you mention was not affected. Leap > 15.1 and SLE-15 versions should be tested instead. Sorry, but with current TW20190623, which has pg2-2.2.16-1.2.x86_64, I get for "gpg -h": gpg: Ohhhh jeeee: secure memory is disabled Abgebrochen (Speicherabzug geschrieben)
(In reply to Frank Kruger from comment #10) > (In reply to Pedro Monreal Gonzalez from comment #9) > > (In reply to Frank Kruger from comment #8) > > > Revised version gpg2-2.2.16-243.1.x86_64 from > > > https://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/ > > > works for me. Thx. > > > > As mentioned in comment#1, the version you mention was not affected. Leap > > 15.1 and SLE-15 versions should be tested instead. > > Sorry, but with current TW20190623, which has pg2-2.2.16-1.2.x86_64, I get > for "gpg -h": > > gpg: Ohhhh jeeee: secure memory is disabled > Abgebrochen (Speicherabzug geschrieben) You are right, it fails now, that's weird. Anyhow, fixed for Factory in submission: https://build.opensuse.org/request/show/712076
gpg2 in LEAP-15.1 and SLE15-SP1 works for me. gpg2 in Factory was fixed with gnupg-2.2.16-secmem.patch.