충격! 펜티엄 버그

최준호(1999/11/17)

지난 11월 초, 유즈넷(8)과 리눅스를 비롯한 각 PC관련 메일링 리스트와 BBS들은 이미 널리 사용되고 있는 인텔의 펜티엄 프로세서에 버그가 있다는 사실에 경악했다(1, 2). 과연 어떤 것이었고, 해결책은 있는 것일까?

버그의 심각성

이 버그는 프로세서의 하드웨어적인 버그로 알려진 바로는 도스, 윈도우95, 윈도우NT, 리눅스, FreeBSD, Solaris x86등 펜티엄에서 운영할 수 있는 모든 운영체제에 영향이 있다. 다만 그 영향은 펜티엄 프로세서와 펜티엄 MMX프로세서로 제한되며, 486이나 펜티엄 프로, 펜티엄 II등에는 영향이 없고, Cyrix나 AMD등의 인텔 호환계열 프로세서에도 영향이 없다. 이 버그는 유닉스 계열 OS의 경우 운영자(root)의 권한 없이도 시스템을 다운시킬 수 있기 때문에, 공공 서비스를 운영하는 경우나 악의적인 바이너리 유포에 취약하며, 처음에는 소프트웨어적인 해결책을 생각하기 어려운 하드웨어적 버그였다는 것이었다. 그러나 현재 소프트웨어적으로 이 버그를 해결할 수 있다는 사실이 알려져 있다 - 도스는 어렵겠지만.

버그의 내용

처음 알려진 바로는, F0 0F C7 C8 의 바이트열을 실행하도록 하면 시스템이 중단된다는 것이었다. 이 코드는 올바른 펜티엄 명령이 아니다. 따라서 C컴파일러등의 프로그램 생성 도구는 이 명령을 만들지 않고, 단지 사용자가 임의로 지정하는 때에만 나타난다. 이 때문에 기존에 사용하던 프로그램이 이 버그로 인해 다운되는 일은 없을 것이다. 프로세서는 이 명령에 대해 잘못된 명령을 의미하는 인터럽트를 발생시키야 하지만, 실제로 그렇게 하지 않고 다운되어 버린다. 게다가 이 버그는 32비트 프로텍티드 모드의 사용자 수준 권한에서도 프로세서를 다운시킬 수 있는 것이어서, ISP로 제공되는 펜티엄 서버의 경우 사용자의 악의적인 DOS(Denial-Of-Service)공격의 대상이 될 수 있다. 이 버그는 문제가 되는 명령의 이름을 따서 Pentium F0, Pentium F0 0F, Pentium lock cmpxchg8b버그 등으로 불린다.

문제의 코드는 다음과 같은 어셈블리 명령이다. 물론 정상적인 명령은 아니다. 이 명령은 64비트 숫자를 32비트 숫자와 비교해서 결과에 따라 바꾸라는 것인데, 맞지 않는 명령이다.

  lock: cmpxchg8b %eax

하지만 이 명령만 그런 것이 아니고 레지스터를 ebx, ecx등으로 바꾸어도 같은 결과가 나온다고 한다. 펜티엄 프로세서 매뉴얼에 따르면 이 명령을 잘못된 명령으로 인정해야 한다고 한다.

테스트

다음은 실제 버그를 발생시키는 코드(4)이다. 펜티엄 사용자들은 조심해서 해 보기 바란다. 리눅스와 같은 유닉스 계열 OS를 운영하는 경우에는 파일시스템을 읽기 전용으로 마운트하거나 Single-User모드에 들어가서 하는 것이 시스템 파손을 최소한으로 막는 일이다.

$ cat > f0.c
char main[] = { 0xf0, 0x0f, 0xc7, 0xc8 };
^D
$ gcc f0.c
$ ./a.out
Illegal instruction (core dumped)

여러분의 프로세서가 순정(!) 펜티엄이라면 마지막의 Illegal instruction메시지는 보지 못했을 것이다...

어떻게, 누가 알렸을까?

알려진 바(4)로는 noname@noname.com이라는 사람이 11월 6일에 리눅스 뉴스그룹에 이 문제를 포스팅했다고 한다. 하지만 x86.org의 Robert Collins는 이 문제를 몇달전부터 이미 알고 있었다고 주장했다. Jim Brooks라는 사람은 Robert Collins가 4-5달 전에 이 문제를 자신에게 보여주었다고 했고, Collins는 이 문제를 인텔에게 알렸지만 무반응이었다고 말했다. 반면 인텔은 뉴스그룹에 문제의 글이 올라오기 전까지 이 문제에 대해 몰랐다고 주장한다.

사용하지도 않는 명령의 버그를 어떻게 발견하였을까? CPU에 대해 모든 바이트열을 명령처럼 주고 올바른 동작을 하는지 알아보는 검사(9)는 누구나 쉽게 해 볼 수 있다. 아마 이런 도중에 발견되지 않았을까...

해결책

인텔은 이 버그를 인정했다. 인텔 사이트에 가면 이 버그에 대한 자세한 기술적인 정보(3)를 얻을 수 있고, 소프트웨어적인 해결책이 존재한다. 필자가 이 글을 쓸 때까지 BSDI(5), Linux(6), FreeBSD, Windows 95(7)등에서 이 문제를 해결할 수 있는 공식/비공식적인 패치가 나왔다. Linux의 경우 개발버전 커널 2.1.64에 해당 버그의 패치가 포함되었다. FreeBSD의 경우 freebsd-hackers 메일링 리스트에 비공식적인 커널 패치가 포스팅된 바 있으며, BSDI의 경우에는 고객에게 공식적인 패치를 제공한다. 다른 OS의 패치는 알려진 바가 없지만, 커널이 프로텍티드 모드를 제어하는 대부분의 OS의 경우 패치가 가능하리라 생각한다.

패치는 OS에 따라 다른 방식으로 구현되지만, 대부분 F0 0F명령이 실행되는 페이지에서 잘못된 명령 인터럽트 대신 페이지 폴트와 같이 더 우선순위가 높은 다른 인터럽트를 발생시키는 방법으로 처리한다고 한다. 이 방법은 생각보다 OS의 성능을 그렇게 크게 낮추지는 않는다고 하며, 펜티엄이 아닌 프로세서에서는 사용할 필요도 없다. 자세한 것은 리눅스 커널 2.1.63에서 펜티엄 버그에 대한 부분(linux/arch/i386/kernel/setup.c, linux/arch/i386/mm/fault.c,linux/include/asm-i386/bugs.h)을 읽어보라. 인텔에서도 소프트웨어 벤더를 위해 정보를 제공하고 있다(3).

위험은 여전히..

소프트웨어가 완벽한 것이 아니듯, 하드웨어도 완벽한 것이 아니다. 특히 CISC로 마이크로프로그램되는 펜티엄과 같은 경우 그 자체도 하나의 소프트웨어라 할 수 있을 것이다. 펜티엄은 이미 부동소수점 버그등으로 상당한 홍역을 치른 적이 있다. 게다가 bugtraq메일링 리스트(10)에 따르면 모든 RISC프로세서가 이런 종류의 버그에 안전하지 못하다는 놀라운 사실을 전하고 있다(9). 버그는 소프트웨어에만 있는것이 아니라 우리가 믿고 따르는 CPU에도 있는 것이다!

충격! 펜티엄 버그

버그의 심각성

버그의 내용

테스트

어떻게, 누가 알렸을까?

해결책

위험은 여전히..

관련 사이트