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

[Mark H Weaver]

Mark H Weaver <address@hidden> 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/address@hidden|
> 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  |address@hidden|

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:

--8<---------------cut here---------------start------------->8---
$ 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>
--8<---------------cut here---------------end--------------->8---

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.

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