-2

Following's are part of three different .s files. The .c file has been compiled with three different options:

  1. -fno-inline -fstack-protector-strong,
  2. -fno-inline -fsanitize=address,
  3. -fno-inline -fno-stack-protector -zexecstack.

The followings are the contents of .s files:

handle_read:
.LFB20:
    .cfi_startproc
    pushq   %r12
    .cfi_def_cfa_offset 16
    .cfi_offset 12, -16
    pushq   %rbp
    .cfi_def_cfa_offset 24
    .cfi_offset 6, -24
    movq    %rsi, %r12
    pushq   %rbx
    .cfi_def_cfa_offset 32
    .cfi_offset 3, -32
    movq    8(%rdi), %rbx
    movq    %rdi, %rbp
    movq    160(%rbx), %rsi
    movq    152(%rbx), %rdx
    cmpq    %rdx, %rsi
    jb      .L394
    cmpq    $5000, %rdx
    jbe     .L421

handle_read:
.LASANPC20:
.LFB20:
    .cfi_startproc
    pushq   %r15
    .cfi_def_cfa_offset 16
    .cfi_offset 15, -16
    pushq   %r14
    .cfi_def_cfa_offset 24
    .cfi_offset 14, -24
    pushq   %r13
    .cfi_def_cfa_offset 32
    .cfi_offset 13, -32
    pushq   %r12
    .cfi_def_cfa_offset 40
    .cfi_offset 12, -40
    pushq   %rbp
    .cfi_def_cfa_offset 48
    .cfi_offset 6, -48
    movq    %rdi, %rbp
    addq    $8, %rdi
    pushq   %rbx
    .cfi_def_cfa_offset 56
    .cfi_offset 3, -56
    movq    %rdi, %rax
    shrq    $3, %rax
    subq    $24, %rsp
    .cfi_def_cfa_offset 80
    cmpb    $0, 2147450880(%rax)
    jne     .L1170
    movq    8(%rbp), %rbx
    leaq    160(%rbx), %r13
    movq    %r13, %r15
    shrq    $3, %r15
    cmpb    $0, 2147450880(%r15)
    jne     .L1171
    leaq    152(%rbx), %r14
    movq    %rsi, %r12
    movq    160(%rbx), %rsi
    movq    %r14, %rax
    shrq    $3, %rax
    cmpb    $0, 2147450880(%rax)
    jne     .L1172
    movq    152(%rbx), %rdx
    leaq    144(%rbx), %rcx
    cmpq    %rdx, %rsi
    jb      .L1054
    cmpq    $5000, %rdx
    jbe     .L1055
    movl    $httpd_err400form, %eax
    shrq    $3, %rax
    cmpb    $0, 2147450880(%rax)
    jne     .L1173
    movl    $httpd_err400title, %eax
    movq    httpd_err400form(%rip), %r8
    shrq    $3, %rax
    cmpb    $0, 2147450880(%rax)
    jne     .L1174


handle_read:
.LFB20:
    .cfi_startproc
    pushq   %r12
    .cfi_def_cfa_offset 16
    .cfi_offset 12, -16
    pushq   %rbp
    .cfi_def_cfa_offset 24
    .cfi_offset 6, -24
    movq    %rsi, %r12
    pushq   %rbx
    .cfi_def_cfa_offset 32
    .cfi_offset 3, -32
    movq    8(%rdi), %rbx
    movq    %rdi, %rbp
    movq    160(%rbx), %rsi
    movq    152(%rbx), %rdx
    cmpq    %rdx, %rsi
    jb      .L384
    cmpq    $5000, %rdx
    jbe     .L411

Can anyone tell me how these codes prevent buffer overrun?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
TYN
  • 29
  • 5
  • Take a look at the documentation for each of the options, this should help you to understand what is being done in each case. `fstack-protector-strong`: https://lwn.net/Articles/584225/. You can Google the others. – EkcenierK Nov 13 '15 at 14:22
  • 2
    Given that the first and third functions are the same, I'd say something is weird here. Also, the function doesn't have the sort of access-pattern that causes buffer overflow. I'd say: **Post the whole functions, not just part of them** – EOF Nov 13 '15 at 14:24

1 Answers1

2

Your handle_read function doesn't end up allocating anything on the stack so there's nothing for -fstack-protector-strong to protect, and so this option makes no difference. The -zexecstack option sets a flag in the generated executable, telling the operating system that it should allow code stored in the stack to be executed. It has no effect on the generated assembly.

Only -fsanitize=address option has an effect that shows up in the generated assembly output you've posted. It's responsible for the shrq $3, rXX; cmp $0, 2147450880(%rXX); jne .LXXXX sequences that appear in your second block of generated assembly. These instructions look up each address in memory that function accesses in a "shadow memory" table. The table records which locations are have been allocated and which haven't. If the inserted code detects that the program is attempting to access a memory location that hasn't be allocated yet it will cause program to exit with an error message.

For more details on how the shadow memory table works, and how AddressSanitizer works in general, you can read the author's Usenix paper AddressSanitizer: A Fast Address Sanity Checker.

Ross Ridge
  • 38,414
  • 7
  • 81
  • 112