Когда сегмент ELF .text не является сегментом ELF .text?

Question

У меня возникли проблемы с поиском соответствующей документации для проблемы. У меня возникает согласование HMACS в ядре и пространстве пользователя. Согласно R. Love в LKD, дескриптор памяти mm-> start_code и mm-> end_code должны содержать сегмент .text. Поиск сегмента .text в статическом исполняемом файле хорошо определен в документации ELF и легко получить. Таким образом, учитывая следующие два фрагмента кода, можно было бы ожидать, чтобы получить соответствующий HMAC:

Kernel:

__mm = get_task_mm(__task); 

__retcode = ntru_crypto_hmac_init(__crypto_context); 
if(__retcode != NTRU_CRYPTO_HMAC_OK) 
    return 1; 

__retcode = ntru_crypto_hmac_update(__crypto_context, (const uint8_t*)__mm->start_code, 
            __mm->end_code - __mm->start_code); 
if(__retcode != NTRU_CRYPTO_HMAC_OK) 
    return 1; 

__retcode = ntru_crypto_hmac_final(__crypto_context, __hmac); 
if(__retcode != NTRU_CRYPTO_HMAC_OK) 
    return 1; 

return 0; 

Userland:

for (j = 0; j < file_hdr32.e_shnum; j++) 
{ 
    if (!strcmp(".text", strIndex + section_hdr32[j]->sh_name)) 
    { 
     retcode = ntru_crypto_hmac_init(__crypto_context()); 
     if(retcode != NTRU_CRYPTO_HMAC_OK) 
     { 
      syslog(LOG_ERR, "ntru_crypto_hmac_init error: retcode = %d, TID(0x%lx)", 
            retcode,pthread_self()); 
      return 0; 
     }  

     retcode = ntru_crypto_hmac_update(__crypto_context(), 
       filebuf + section_hdr32[j]->sh_offset, section_hdr32[j]->sh_size); 
     if(retcode != NTRU_CRYPTO_HMAC_OK) 
     { 
      syslog(LOG_ERR, "Internal crypto error (%d)", retcode); 
      return 0; 
     } 

     retcode = ntru_crypto_hmac_final(__crypto_context(), _hmac); 
     if(retcode != NTRU_CRYPTO_HMAC_OK) 
     { 
      syslog(LOG_ERR, "Failed to finalize HMAC, TID(0x%lx)", pthread_self()); 
      return 0; 
     } 

     return 1; 
    } 
} 

В обоих случаях сегмент .text именно там, где его документально подтвердили, но они никогда не совпадают. Я создал пользовательский HMACS для всех 17 000 исполняемых файлов в системе, поэтому даже если сегмент кода в дескрипторе памяти ядра указывал на зависимость, а не на основной исполняемый файл, я все равно должен получить совпадение, но не кубик. Есть что-то принципиально иное между двумя сегментами «.text», и мне было интересно, знает ли кто-нибудь, что это такое, чтобы я мог сэкономить некоторое время - какие-то подсказки? Заранее спасибо, Pete;. 1

Answer 1

Там что-то принципиально отличается от двух «.text» сегменты

Ваша проблема заключается в том, что вы не обращая внимания на разницу между сегментов и секций.

Формат ELF является исполняемый и связывая формат. Сегменты используются для первого, секции для последнего (и ссылка здесь означает статическое связывание, т. Е. Время сборки). Как только двоичный файл связан, разделы могут быть полностью удалены из него, и во время выполнения требуются только сегменты. Сегменты: mmap ed, а не разделы.

Теперь давайте рассмотрим разницу между ними.

readelf -l /bin/date 

Elf file type is EXEC (Executable file) 
Entry point 0x402000 
There are 9 program headers, starting at offset 64 

Program Headers: 
    Type   Offset    VirtAddr   PhysAddr 
       FileSiz   MemSiz    Flags Align 
    PHDR   0x0000000000000040 0x0000000000400040 0x0000000000400040 
       0x00000000000001f8 0x00000000000001f8 R E 8 
    INTERP   0x0000000000000238 0x0000000000400238 0x0000000000400238 
       0x000000000000001c 0x000000000000001c R  1 
     [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] 
    LOAD   0x0000000000000000 0x0000000000400000 0x0000000000400000 
       0x000000000000d5ac 0x000000000000d5ac R E 200000 
    LOAD   0x000000000000de10 0x000000000060de10 0x000000000060de10 
       0x0000000000000440 0x0000000000000610 RW  200000 
    DYNAMIC  0x000000000000de38 0x000000000060de38 0x000000000060de38 
       0x00000000000001a0 0x00000000000001a0 RW  8 
    NOTE   0x0000000000000254 0x0000000000400254 0x0000000000400254 
       0x0000000000000044 0x0000000000000044 R  4 
    GNU_EH_FRAME 0x000000000000c700 0x000000000040c700 0x000000000040c700 
       0x00000000000002a4 0x00000000000002a4 R  4 
    GNU_STACK  0x0000000000000000 0x0000000000000000 0x0000000000000000 
       0x0000000000000000 0x0000000000000000 RW  8 
    GNU_RELRO  0x000000000000de10 0x000000000060de10 0x000000000060de10 
       0x00000000000001f0 0x00000000000001f0 R  1 

Section to Segment mapping: 
    Segment Sections... 
    00 
    01  .interp 
    02  .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 
    03  .ctors .dtors .jcr .dynamic .got .got.plt .data .bss 
    04  .dynamic 
    05  .note.ABI-tag .note.gnu.build-id 
    06  .eh_frame_hdr 
    07 
    08  .ctors .dtors .jcr .dynamic .got 

Выше вы можете видеть, что множественным секции (.interp, .note.ABI-tag ... .text ...) все получили карту в один PT_LOADсегмента. Все эти разделы имеют одинаковую защиту, и все они «покрыты» одним регистром [mm->start_core, mm->end_code).

Сравните это раздел .text:

readelf -WS /bin/date | grep '\.text' 
    [13] .text    PROGBITS  0000000000401900 001900 0077f8 00 AX 0 0 16 

Вы заметите, что секция меньше и начинается другое смещение.

Неудивительно, что вы получаете другую HMAC. Попробуйте вычислить HMAC в пользовательских сегментах по сегментам, и вы должны получить соответствие.