contrib: add symbol-check test for non-existence of `vmova` instructions in Windows build #28413

Given we are patching the Windows GCC used for releases, to avoid the use of certain aligned assembly instructions, we should probably add a symbol-check test to ensure the patches are working as intended.

See #24726, #24736 and #28151 for the background here.

Wouldn't checking the instructions be more of a security-check instead of a symbol-check?

Assigning myself as I'm interested on working on this.

Is introducing a dependency on the python capstone binding acceptable here? It's not possible to do this check without a disassembler of some kind, we don't want to rely on calling out to objdump, and i'm not sure we want our own x86 mini-disassembler (hard to review, slow in pure python). Capstone is great for this and might help in future instruction security checks as well. But it's another build-time dep.

For reference, with capstone this check is as simple as:

# Intel® 64 and IA-32 Architectures Software Developer’s Manual:
#   chapter 14.9, table 14-22. Instructions Requiring Explicitly Aligned Memory
#   chapter 15.7, Table 15-6. SIMD Instructions Requiring Explicitly Aligned Memory
#
# This amounts to the following instructions:
#
# instruction                  chapter 4.3 section
# ---------------------------  ---------------------------------
# (V)MOVDQA xmm, mBBB          MOVDQA,VMOVDQA32/64—Move Aligned Packed Integer Values
# (V)MOVDQA mBBB, xmm          MOVDQA,VMOVDQA32/64—Move Aligned Packed Integer Values
# (V)MOVAPS xmm, mBBB          MOVAPS—Move Aligned Packed Single Precision Floating-Point Values
# (V)MOVAPS mBBB, xmm          MOVAPS—Move Aligned Packed Single Precision Floating-Point Values
# (V)MOVAPD xmm, mBBB          MOVAPD—Move Aligned Packed Double Precision Floating-Point Values
# (V)MOVAPD mBBB, xmm          MOVAPD—Move Aligned Packed Double Precision Floating-Point Values
# (V)MOVNTPS mBBB, xmm         MOVNTPS—Store Packed Single Precision Floating-Point Values Using Non-Temporal Hint
# (V)MOVNTPD mBBB, xmm         MOVNTPD—Store Packed Double Precision Floating-Point Values Using Non-Temporal Hint
# (V)MOVNTDQ mBBB, xmm         MOVNTDQ—Store Packed Integers Using Non-Temporal Hint
# (V)MOVNTDQA xmm, mBBB        MOVNTDQA—Load Double Quadword Non-Temporal Aligned Hint
#
# BBB is the bit size, which can be 128, 256 or 512.
#
FORBIDDEN_VMOVA = {
    capstone.x86.X86_INS_MOVDQA,    capstone.x86.X86_INS_VMOVDQA,   capstone.x86.X86_INS_VMOVDQA32, capstone.x86.X86_INS_VMOVDQA64,
    capstone.x86.X86_INS_MOVAPS,    capstone.x86.X86_INS_VMOVAPS,
    capstone.x86.X86_INS_MOVAPD,    capstone.x86.X86_INS_VMOVAPD,
    capstone.x86.X86_INS_MOVNTPS,   capstone.x86.X86_INS_VMOVNTPS,
    capstone.x86.X86_INS_MOVNTPD,   capstone.x86.X86_INS_VMOVNTPD,
    capstone.x86.X86_INS_MOVNTDQ,   capstone.x86.X86_INS_VMOVNTDQ,
    capstone.x86.X86_INS_MOVNTDQA,  capstone.x86.X86_INS_VMOVNTDQA,
}

def check_ELF_no_vmova(binary) -> bool:
    '''
    Check for vmov instructions that require alignment.
    These are a potential problem due to a stack alignment bug in GCC on Windows.
    See [#28413](/bitcoin-bitcoin/28413/) for specifics.
    '''
    cs = capstone.Cs(capstone.CS_ARCH_X86, capstone.CS_MODE_64)

    found_forbidden = False
    for segment in binary.segments:
        # Find loaded, executable segments
        if segment.type == lief.ELF.SEGMENT_TYPES.LOAD and (segment.flags & lief.ELF.SEGMENT_FLAGS.X) != 0:
            # disassemble segment, check every instruction
            for i in cs.disasm(segment.content, segment.virtual_address): # -> CsInsn
                if i.id in FORBIDDEN_VMOVA:
                    found_forbidden = True

    return not found_forbidden

Still need to port this to PE.

And figure out what the exceptions are in the current release, and how to either get rid of them, or identify them.

It looks like this issue has been resolved. If that’s not the case, please let us know by commenting here or opening a new issue.