Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys

Jussi Kivilinna jussi.kivilinna at iki.fi
Sat Jan 18 12:31:04 CET 2014


On 17.01.2014 20:34, Hans-Christoph Steiner wrote:
> 
> On GPG for Android, I've updated to the latest libgcrypt in master (or close
> to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4).  Now it seems
> that any operation that needs a passphrase is crashing somewhere in libgcrypt.
>  I've tried building with auto-detection of CPU which enables Padlock, Intelt
> DRNG, and NEON.  I also tried with --disable-padlock-support
> --disable-drng-support --disable-neon-support, and seemed to get the same thing.
> 
> I've also tried running gpg-agent with and without --enable-ssh-support, and
> same result each time.
> 
> Here's the basic backtrace:
<..snip..>
> From the bug report in our tracker, you can download the complete build log, a
> debug log from the Android app, a log from gpg-agent, and a log from gpgme:
> 
> https://dev.guardianproject.info/issues/2888

Have you configured gcc flags correctly for target platform? It seems that
compiler (and libgcrypt assembly) are configured to allow unaligned memory
accesses, but target does not support them.

Disassembly of crash site:

   0:   e1866469        orr     r6, r6, r9, ror #8
   4:   e8900f00        ldm     r0, {r8, r9, sl, fp}
   8:   e0244008        eor     r4, r4, r8
   c:   e0255009        eor     r5, r5, r9
  10:   e026600a        eor     r6, r6, sl
  14:   e027700b        eor     r7, r7, fp
  18:   eafffded        b       0xfffff7d4
  1c:   e92d5ff0        push    {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr}
!!20:   e89200f0        ldm     r2, {r4, r5, r6, r7}
  24:   e24dd010        sub     sp, sp, #16
  28:   e59fe864        ldr     lr, [pc, #2148] ; 0x894
  2c:   e3a0c0ff        mov     ip, #255        ; 0xff
  30:   e58d1004        str     r1, [sp, #4]
  34:   e1a0c18c        lsl     ip, ip, #3
  38:   e353000c        cmp     r3, #12
  3c:   aa000215        bge     0x898

Crash happens in rinjdael_arm.S:_gcry_aes_arm_decrypt_block, line 496:
	/* aligned load */
	ldm	%r2, {RA, RB, RC, RD};

This just loads four 32-bit words from input buffer (pointer in r2). The pointer
in r2 is 0x013ebf9f, not aligned to 32-bit word boundary. Above disassembly
shows that code is compiled with __ARM_FEATURE_UNALIGNED (-munaligned-access)
and unaligned memory accesses are assumed to be ok. But clearly unaligned
memory accesses are not allowed as programs crashes with "signal 7 (SIGBUS),
code 1 (BUS_ADRALN), fault addr 013ebf9f" - Invalid address alignment.

GCC documentation says [1]:
 -munaligned-access
 -mno-unaligned-access
   Enables (or disables) reading and writing of 16- and 32- bit values from
   addresses that are not 16- or 32- bit aligned. By default unaligned access
   is disabled for all pre-ARMv6 and all ARMv6-M architectures, and enabled for
   all other architectures. If unaligned access is not enabled then words in
   packed data structures will be accessed a byte at a time.

   The ARM attribute Tag_CPU_unaligned_access will be set in the generated
   object file to either true or false, depending upon the setting of this
   option. If unaligned access is enabled then the preprocessor symbol
   __ARM_FEATURE_UNALIGNED will also be defined.

-Jussi

[1] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

> 
> .hc
> 
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 




More information about the Gnupg-devel mailing list