可変長レコードで満たされたバイトバッファーがあり、その長さはレコードの最初のバイトによって決定されます。単一のレコードを読み取るためのC関数の縮小バージョン
void mach_parse_compressed(unsigned char* ptr, unsigned long int* val)
{
if (ptr[0] < 0xC0U) {
*val = ptr[0] + ptr[1];
return;
}
*val = ((unsigned long int)(ptr[0]) << 24)
| ((unsigned long int)(ptr[1]) << 16)
| ((unsigned long int)(ptr[2]) << 8)
| ptr[3];
}
最初にptrで4バイトをロードし、最初のバイトを0xC0と比較してから、2バイトまたは4バイトのいずれかを処理するアセンブリ（GCC 5.4 -O2 -fPIC on x86_64）を生成します。未定義のバイトは正しく破棄されますが、コンパイラはなぜ最初に4バイトをロードしても安全だと考えているのですか？たとえば、ptrのアライメント要件はないので、メモリページの最後の2バイトを指している可能性があります。これは、わかっているすべてのマッピングされていないものの隣にあり、クラッシュを引き起こします。
再現するには、-fPICと-O2以上の両方が必要です。
ここで何か不足していますか？これを行う際にコンパイラは正しいですか？これを回避するにはどうすればよいですか？
上記のValgrind / AddressSanitiserエラーまたはmmap / mprotectでのクラッシュを表示できます：
//#define HEAP
#define MMAP
#ifdef MMAP
#include <unistd.h>
#include <sys/mman.h>
#include <stdio.h>
#elif HEAP
#include <stdlib.h>
#endif
void
mach_parse_compressed(unsigned char* ptr, unsigned long int* val)
{
if (ptr[0] < 0xC0U) {
*val = ptr[0] + ptr[1];
return;
}
*val = ((unsigned long int)(ptr[0]) << 24)
| ((unsigned long int)(ptr[1]) << 16)
| ((unsigned long int)(ptr[2]) << 8)
| ptr[3];
}
int main(void)
{
unsigned long int val;
#ifdef MMAP
int error;
long page_size = sysconf(_SC_PAGESIZE);
unsigned char *buf = mmap(NULL, page_size * 2, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
unsigned char *ptr = buf + page_size - 2;
if (buf == MAP_FAILED)
{
perror("mmap");
return 1;
}
error = mprotect(buf + page_size, page_size, PROT_NONE);
if (error != 0)
{
perror("mprotect");
return 2;
}
*ptr = 0xBF;
*(ptr + 1) = 0x10;
mach_parse_compressed(ptr, &val);
#elif HEAP
unsigned char *buf = malloc(16384);
unsigned char *ptr = buf + 16382;
buf[16382] = 0xBF;
buf[16383] = 0x10;
#else
unsigned char buf[2];
unsigned char *ptr = buf;
buf[0] = 0xBF;
buf[1] = 0x10;
#endif
mach_parse_compressed(ptr, &val);
}
MMAPバージョン：
Segmentation fault (core dumped)
Valgrindの場合：
==3540== Process terminating with default action of signal 11 (SIGSEGV)
==3540== Bad permissions for mapped region at address 0x4029000
==3540== at 0x400740: mach_parse_compressed (in /home/laurynas/gcc-too-wide-load/gcc-too-wide-load)
==3540== by 0x40060A: main (in /home/laurynas/gcc-too-wide-load/gcc-too-wide-load)
ASanの場合：
ASAN:SIGSEGV
=================================================================
==3548==ERROR: AddressSanitizer: SEGV on unknown address 0x7f8f4dc25000 (pc 0x000000400d8a bp 0x0fff884e56c6 sp 0x7ffc4272b620 T0)
#0 0x400d89 in mach_parse_compressed (/home/laurynas/gcc-too-wide-load/gcc-too-wide-load+0x400d89)
#1 0x400b92 in main (/home/laurynas/gcc-too-wide-load/gcc-too-wide-load+0x400b92)
#2 0x7f8f4c72082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#3 0x400c58 in _start (/home/laurynas/gcc-too-wide-load/gcc-too-wide-load+0x400c58)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 mach_parse_compressed
Valgrindを使用したHEAPバージョン：
==30498== Invalid read of size 4
==30498== at 0x400603: mach_parse_compressed (mach0data_reduced.c:9)
==30498== by 0x4004DE: main (mach0data_reduced.c:34)
==30498== Address 0x520703e is 16,382 bytes inside a block of size 16,384 alloc'd
==30498== at 0x4C2DB8F: malloc (vg_replace_malloc.c:299)
==30498== by 0x4004C0: main (mach0data_reduced.c:24)
ASanを使用したスタックバージョン：
==30528==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffd50000440 at pc 0x000000400b63 bp 0x7ffd500003c0 sp
0x7ffd500003b0
READ of size 4 at 0x7ffd50000440 thread T0
#0 0x400b62 in mach_parse_compressed
CMakeFiles/innobase.dir/mach/mach0data_reduced.c:15
#1 0x40087e in main CMakeFiles/innobase.dir/mach/mach0data_reduced.c:34
#2 0x7f3be2ce282f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#3 0x400948 in _start
(/home/laurynas/obj-percona-5.5-release/storage/innobase/CMakeFiles/innobase.dir/mach/mach0data_test+0x400948)
ありがとう
編集：実際にクラッシュするMMAPバージョンを追加し、コンパイラオプションを明確化
編集2：https : //gcc.gnu.org/bugzilla/show_bug.cgi?id=77673として報告しました。回避策としてasm volatile("": : :"memory");、ifステートメントの後にコンパイラのメモリバリアを挿入すると、問題が解決します。みんな、ありがとう！
おめでとう！あなたは本物のコンパイラのバグを見つけました！
http://gcc.godbolt.orgを使用して、さまざまなコンパイラおよびオプションからのアセンブリ出力を探索できます。
x86 64ビットLinuxのgccバージョン6.2では、を使用するgcc -fPIC -O2と、関数は正しくないコードにコンパイルされます。
mach_parse_compressed(unsigned char*, unsigned long*):
movzbl (%rdi), %edx
movl (%rdi), %eax ; potentially incorrect load of 4 bytes
bswap %eax
cmpb $-65, %dl
jbe .L5
movl %eax, %eax
movq %rax, (%rsi)
ret
.L5:
movzbl 1(%rdi), %eax
addl %eax, %edx
movslq %edx, %rdx
movq %rdx, (%rsi)
ret
問題を正しく診断し、このmmap例は優れた回帰テストを提供します。gccは、この関数を最適化しようと懸命に努力しており、結果のコードは間違いなく正しくありません。整列されていないアドレスから4バイトを読み取ることは、ほとんどのX86オペレーティング環境では問題ありませんが、配列の終わりを超えて読み取ることはできません。
コンパイラーは、32ビットまたは64ビットの境界を越えない場合、配列の終わりを超えた読み取りは問題ないと想定することができますが、この仮定は例では正しくありません。割り当てられたブロックをmalloc十分に大きくすると、ブロックがクラッシュする可能性があります。非常に大きなブロックにmalloc使用mmapします（デフォルトではIRKB 128KB以上）。
このバグはコンパイラのバージョン5.1で導入されたことに注意してください。
clang 一方、この問題はありませんが、一般的なケースではコードの効率は低くなります。
# @mach_parse_compressed(unsigned char*, unsigned long*)
mach_parse_compressed(unsigned char*, unsigned long*):
movzbl (%rdi), %ecx
cmpq $191, %rcx
movzbl 1(%rdi), %eax
ja .LBB0_2
addq %rcx, %rax
movq %rax, (%rsi)
retq
.LBB0_2:
shlq $24, %rcx
shlq $16, %rax
orq %rcx, %rax
movzbl 2(%rdi), %ecx
shlq $8, %rcx
orq %rax, %rcx
movzbl 3(%rdi), %eax
orq %rcx, %rax
movq %rax, (%rsi)
retq
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加