linux - Glibc scanf Fallos de segmentación cuando se llama desde una función que no alinea RSP

assembly nasm

Question

Al compilar el siguiente código:

global main
extern printf, scanf
section .data
msg: db "Enter a number: ",10,0
format:db "%d",0
section .bss
number resb 4
section .text
main:
mov rdi, msg
mov al, 0
call printf
mov rsi, number
mov rdi, format
mov al, 0
call scanf
mov rdi,format
mov rsi,[number]
inc rsi
mov rax,0
call printf
ret

utilizando:

nasm -f elf64 example.asm -o example.o
gcc -no-pie -m64 example.o -o example

y luego correr

./example

se ejecuta, imprime: ingresa un número: pero luego se bloquea e imprime: falla de segmentación (núcleo volcado)

Así que printf funciona bien pero no scanf. ¿Qué estoy haciendo mal con scanf así?

Answer 1

Use sub rsp, 8 / add rsp, 8 al inicio / final de su función para realinear la pila a 16 bytes antes de que su función realice una call .

O mejor es empujar / pop rcx un registro ficticio, por ejemplo, push rdx / pop rcx , o guardar / restaurar un registro conservado de llamadas como RBP.

En la entrada de la función, RSP está a 8 bytes de la alineación de 16 bytes porque la call insertó una dirección de retorno de 8 bytes. Vea Imprimir números de coma flotante desde x86-64 parece que se necesita guardar% rbp , alineación principal y de pila y Llamando a printf en x86_64 usando el ensamblador GNU . Este es un requisito de ABI que solía ser capaz de evitar violar cuando no había ningún argumento FP para printf. Pero ya no más.

El código-gen de gcc para glibc scanf ahora depende de la alineación de la pila de 16 bytes, incluso cuando AL == 0 .

Parece tener una copia auto-vectorizada de 16 bytes en algún lugar de __GI__IO_vfscanf , que el scanf normal llama después de derramar su registro args a la pila ¹ . (Las muchas formas similares de llamar a scanf comparten una gran implementación como back-end a los diversos puntos de entrada de libc como scanf , fscanf , etc.)

Descargué el paquete binario libc6 de Ubuntu 18.04: https://packages.ubuntu.com/bionic/amd64/libc6/download y 7z x blah.deb los archivos (con 7z x blah.deb y tar xf data.tar , porque 7z sabe cómo extraer muchos formatos de archivo).

Puedo reprochar tu error con LD_LIBRARY_PATH=/tmp/bionic-libc/lib/x86_64-linux-gnu ./bad-printf , y también resulta con el sistema glibc 2.27-3 en mi escritorio Arch Linux.

Con GDB, lo ejecuté en su programa y set env LD_LIBRARY_PATH /tmp/bionic-libc/lib/x86_64-linux-gnu luego set env LD_LIBRARY_PATH /tmp/bionic-libc/lib/x86_64-linux-gnu . Con layout reg , la ventana de desmontaje se ve así en el punto donde recibió SIGSEGV:

 │0x7ffff786b49a <_IO_vfscanf+602> cmp r12b,0x25 │
│0x7ffff786b49e <_IO_vfscanf+606> jne 0x7ffff786b3ff <_IO_vfscanf+447> │
│0x7ffff786b4a4 <_IO_vfscanf+612> mov rax,QWORD PTR [rbp-0x460] │
│0x7ffff786b4ab <_IO_vfscanf+619> add rax,QWORD PTR [rbp-0x458] │
│0x7ffff786b4b2 <_IO_vfscanf+626> movq xmm0,QWORD PTR [rbp-0x460] │
│0x7ffff786b4ba <_IO_vfscanf+634> mov DWORD PTR [rbp-0x678],0x0 │
│0x7ffff786b4c4 <_IO_vfscanf+644> mov QWORD PTR [rbp-0x608],rax │
│0x7ffff786b4cb <_IO_vfscanf+651> movzx eax,BYTE PTR [rbx+0x1] │
│0x7ffff786b4cf <_IO_vfscanf+655> movhps xmm0,QWORD PTR [rbp-0x608] │
>│0x7ffff786b4d6 <_IO_vfscanf+662> movaps XMMWORD PTR [rbp-0x470],xmm0 │

Así que copió dos objetos de 8 bytes en la pila con movq + movhps para cargar y movaps para almacenar. Pero con la pila desalineada, movaps [rbp-0x470],xmm0 fallas.

No tomé una compilación de depuración para averiguar exactamente qué parte de la fuente C se convirtió en esto, pero la función está escrita en C y compilada por GCC con la optimización habilitada. A GCC siempre se le ha permitido hacer esto, pero solo recientemente se ha vuelto lo suficientemente inteligente como para aprovechar mejor el SSE2 de esta manera.

Nota al pie 1: ¡printf / scanf con AL != 0 siempre ha requerido una alineación de 16 bytes porque el código-gen de gcc para funciones variad usa la prueba al, al / je para derramar los registros XMM completos de 16 bytes xmm0..7 con las tiendas alineadas en Ese caso. __m128i puede ser un argumento para una función variadic, no solo el double , y gcc no comprueba si la función alguna vez lee realmente cualquier argumento FP de 16 bytes.