bug#24703: fontconfig keeps obfuscated reference to itself, not grafted

[Mark H Weaver <mhw@netris.org>]

Mark H Weaver <mhw@netris.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> It turns out there's an obfuscated self-reference to fontconfig's store
>> directory.  Here's an excerpt of the output of "hexdump -C
>> libfontconfig.so.1.9.0":
>>
>> 0000cca0  00 48 b9 2f 67 6e 75 2f  73 74 6f c6 40 48 00 45  |.H./gnu/sto.@H.E|
>> 0000ccb0  31 e4 48 89 08 48 b9 72  65 2f 62 34 38 34 6e 48  |1.H..H.re/b484nH|
>> 0000ccc0  89 48 08 48 b9 76 6e 39  6e 6e 72 33 64 48 89 48  |.H.H.vn9nnr3dH.H|
>> 0000ccd0  10 48 b9 64 63 6c 70 7a  32 66 6d 48 89 48 18 48  |.H.dclpz2fmH.H.H|
>> 0000cce0  b9 61 39 79 78 6d 69 6d  67 48 89 48 20 48 b9 32  |.a9yxmimgH.H H.2|
>> 0000ccf0  6a 6a 2d 66 6f 6e 74 48  89 48 28 48 b9 63 6f 6e  |jj-fontH.H(H.con|
>> 0000cd00  66 69 67 2d 32 48 89 48  30 48 b9 2e 31 31 2e 39  |fig-2H.H0H..11.9|
>> 0000cd10  34 2f 65 48 89 48 38 48  b9 74 63 2f 66 6f 6e 74  |4/eH.H8H.tc/font|
>> 0000cd20  73 48 89 48 40 48 8b 04  24 48 8b 18 48 89 c5 48  |sH.H@H..$H..H..H|
>
> It turns out that this is part of the compiled x86_64 code for
> 'FcConfigFilename' in src/fccfg.c, which copies a compile-time string
> constant, 8 bytes at a time, into a buffer:
>
> $ objdump -d libfontconfig.so.1.9.0 | grep -B1 -A35 '48 b9 2f 67 6e 75 2f'
>     cc9b:	0f 84 3f 01 00 00    	je     cde0 <FcConfigFilename+0x2d0>
>     cca1:	48 b9 2f 67 6e 75 2f 	movabs $0x6f74732f756e672f,%rcx
>     cca8:	73 74 6f 
>     ccab:	c6 40 48 00          	movb   $0x0,0x48(%rax)
>     ccaf:	45 31 e4             	xor    %r12d,%r12d
>     ccb2:	48 89 08             	mov    %rcx,(%rax)
>     ccb5:	48 b9 72 65 2f 62 34 	movabs $0x6e343834622f6572,%rcx
>     ccbc:	38 34 6e 
>     ccbf:	48 89 48 08          	mov    %rcx,0x8(%rax)
>     ccc3:	48 b9 76 6e 39 6e 6e 	movabs $0x6433726e6e396e76,%rcx
>     ccca:	72 33 64 
>     cccd:	48 89 48 10          	mov    %rcx,0x10(%rax)
>     ccd1:	48 b9 64 63 6c 70 7a 	movabs $0x6d66327a706c6364,%rcx
>     ccd8:	32 66 6d 
>     ccdb:	48 89 48 18          	mov    %rcx,0x18(%rax)
>     ccdf:	48 b9 61 39 79 78 6d 	movabs $0x676d696d78793961,%rcx
>     cce6:	69 6d 67 
>     cce9:	48 89 48 20          	mov    %rcx,0x20(%rax)
>     cced:	48 b9 32 6a 6a 2d 66 	movabs $0x746e6f662d6a6a32,%rcx
>     ccf4:	6f 6e 74 
>     ccf7:	48 89 48 28          	mov    %rcx,0x28(%rax)
>     ccfb:	48 b9 63 6f 6e 66 69 	movabs $0x322d6769666e6f63,%rcx
>     cd02:	67 2d 32 
>     cd05:	48 89 48 30          	mov    %rcx,0x30(%rax)
>     cd09:	48 b9 2e 31 31 2e 39 	movabs $0x652f34392e31312e,%rcx
>     cd10:	34 2f 65 
>     cd13:	48 89 48 38          	mov    %rcx,0x38(%rax)
>     cd17:	48 b9 74 63 2f 66 6f 	movabs $0x73746e6f662f6374,%rcx
>     cd1e:	6e 74 73 
>     cd21:	48 89 48 40          	mov    %rcx,0x40(%rax)
>     cd25:	48 8b 04 24          	mov    (%rsp),%rax
>     cd29:	48 8b 18             	mov    (%rax),%rbx
>     cd2c:	48 89 c5             	mov    %rax,%rbp
>     cd2f:	48 85 db             	test   %rbx,%rbx
>     cd32:	48 89 df             	mov    %rbx,%rdi
>     cd35:	75 16                	jne    cd4d <FcConfigFilename+0x23d>
>     cd37:	eb 44                	jmp    cd7d <FcConfigFilename+0x26d>
>
> So far, I've not been able to find any evidence of the fontconfig code
> doing anything strange here.  I strongly suspect that GCC is generating
> this code, most likely due to an inlinable string/memory copy function
> where the source is a string literal.

I've confirmed this.  After building this package manually, "objdump -d
--source src/.libs/fccfg.o" reveals that the corresponding source code
is:

    dir = (FcChar8 *) FONTCONFIG_PATH;
    path[i] = malloc (strlen ((char *) dir) + 1);
    if (!path[i])
	goto bail1;
    strcpy ((char *) path[i], (const char *) dir);

It is part of 'FcConfigGetPath', inlined into 'FcConfigFilename', in
src/fccfg.c.  -DFONTCONFIG_PATH='"$(BASECONFIGDIR)"' is one of the flags
passed to GCC, via AM_CPPFLAGS in src/Makefile.am.

> Obviously, this could be a serious problem for Guix (and Nix), since it
> suggests that we may not be able to continue with our simplistic
> assumption that references to the store in compiled code will be easy to
> find and replace.

      Mark