| 이 기사의 의견 보기 |
|
|
| . / 04-06-25 12:04/
신고
|
|
|
쿠엑 치명적이네요 rep movs면 많이쓰는 명령인데... 확실히 안정성이 좀 올라가야 서버에 쓸만할듯 하군요. 인텔칩 나눗셈 오류 못지않은 결함이긴한데 아직 보급 컴퓨터 대수가 얼마 안되서 다행인듯하네요. 가끔 멎는다는 분들이 이것에 해당되는 분들도 있으셨나봅니다.. 역시 아직 안정화를 기다려야 할듯.. 특히 옵테론은 서버도입이 힘든게 이런부분 검증 탓인듯 합니다.
|
|
|
|
|
| . / 04-06-25 12:06/
신고
|
|
|
현재 제온서버가 많이 팔리는게 linux 안정화버젼깔고 1년동안 재부팅 없이 빙빙 돌아가서 입니다. 성능 좀 떨어져도 안정성이 중요한 바닥이지요. 자주쓰는 명령이 저렇게 좀 지나서야 알려졌으니 발생 확률이 낮겠지만 개인유저는 머 잘 몰라도 서버로서는 확실히 곤란하군요. 서버는 죽으면 황.
|
|
|
|
|
| 커엉 / 04-06-25 12:28/
신고
|
|
|
일반 사용자들을 위한 Athlon64 와 서버와 워크스테이션을 위한 Opteron 프로세서들중에 지금까지 문제가 보고 된적은 없었다고 합니다. 이 문제는 AMD 엔지니어들이 자체적으로 발견해서 수정한 거라고 전해지네요. 소비자들이 모르는 문제를 덮어 놓다가 나중에야 리콜등을 단행하는 인텔보다는 도덕성에 한표 주고 싶습니다.
|
|
|
|
|
| 걍 / 04-06-25 12:43/
신고
|
|
reps movs가 얼마나 중요한 시퀀스인지 잘모르시는건가요?
도덕성을 따지기 전에 앞서 말도안되는
버그를 내놓은 거라는걸 아셨음 합니다.
지금까지 문제가 보고되지 않은 것은 사용자가 없어서지요. 서버로 돌리다 퍽 죽어버리면 아 이게 64빗이라서 아직 플그램이 안정화 안됐나 보군이라고 생각하지
이게 혹시 명령어간의 버그로 나오는걸까 라고 guess하는 사람이 몇이나될까요
|
|
|
|
|
| . / 04-06-25 13:04/
신고
|
|
rep movs는 엄청나게 중요한 명령입니다. 이게 오작동하면 컴퓨터 보안근간자체가 송두리째 날라갑니다. 그리고 아래 여기 사이트에도 리플 이미 있네요 http://www.bodnara.co.kr/bbs/?imode=view&D=11&num=53611&category=97 여기 올리신분..
머 저문제인진 모르겠지만...
그리고 문제가 없다기 보단 그만큼 지금까지 판매량이 극도로 부진하다가 이제사 조금 늘어나니 보이게 되었다는쪽이 맞을겁니다. 도덕성을 떠나서 칩의 가장 중요한 연산부분중하나에 낮은 확률로 오작동이 있다는건 정말 끔찍한 일입니다. 신뢰에 엄청난 타격이라고 보시면 되겠네요 다행스런건 아직 많이 안팔렸다 라는거.. 그리고 육사 랑 옵테론 둘다 이렇다는건 코어결함 같습니다만 그건 좀봐야 알듯하고..
|
|
|
|
|
| ... / 04-06-25 14:01/
신고
|
|
별로 중요한 오류는 아니라고 하더군요.
컴파일러를 사용할 경우 해당 오류는 발생하지 않고 단지 핸드 어셈블리어를 사용했을때 나타날 수도 있는 오류라고 합니다.
개발자 중에서 인라인도 아니고 핸드 어셈블리어까지 쓰면서 개발할 사람이 몇 명이나 될까요?
|
|
|
|
|
| ... / 04-06-25 14:09/
신고
|
|
Reperence MOVS가 전반적으로 오류가 날 정도면 보안근간이 날아가는 정도가 아니라 컴퓨터가 아예 안돌아 가지요.
하지만 현재 컴퓨터가 문제없이 돌아가는 것을 생각한다면 해당 오류가 그다지 심각한 상황이 아니라는 이야기밖에는 설명이 안됩니다.
|
|
|
|
|
| 흐미 기죽네 / 04-06-25 14:38/
신고
|
|
전 님들 무슨토론을 하시는지...^^;;;
역시일반유저는 뭔소리인지 모르겠군요 님들 지식에 정말 감탄....
|
|
|
|
|
| 걍 / 04-06-25 15:06/
신고
|
|
|
어떤 조합인지는 모르겠으나 x86_64코드를 내놀수 있는 컴파일러야 얼마든지 다르게 만들어서 내놓을수 있지요. 그리고 컴퓨터가 부팅해서 os가 올라가고 애플리케이션이 돌아가기까지 많은수의 손으로 짠 어셈블리가 돌아간다는 사실을 모르시는군요. 한 개발자가 장난으로 끼적거리는 애플리케이션이 아닌이상 손으로 직접 어셈블리를 치지 않고 순수 high level로만 작성한 sw는 또 얼마나 많은지 모르겠군요. 그리고 전반적으로 오류가 나면 어디 팔렸겠습니까. 오류가 날 확률을 가지고 있다는 뜻이지요. 그리고 컴퓨터가 아예 안돌아간다는 말은 너무 포괄적이지 않나요? 컴퓨터가 안돌아간다는 걸 뜯어보면 pc가 엉뚱한 데로 jmp한경우가 대부분이지요. 보안근간이 날아간다는 말이 무슨뜻이지 이제 아시겠지요. 이런데도 정말 안심각한가요 ㅎㅎ
|
|
|
|
|
| 걍 / 04-06-25 15:10/
신고
|
|
그리고 ...님 Reperence가 몬가요?
무슨 어셈블런지 모르겠군여.
제가 알기론 repeat입니다만.
|
|
|
|
|
| ... / 04-06-25 15:26/
신고
|
|
|
Errata sheet를 보니 해당 오류는 C0과 CG에만 해당하더군요. Repeat Move String이라는 명령어가 많이 쓰이기는 하는데 이게 어떻게 해서 보안근간이 날아갈만한 명령어인지가 궁금한 중입니다.
|
|
|
|
|
| ... / 04-06-25 15:28/
신고
|
|
|
Reperence가 아니라 Repeat입니다. 날밤을 좀 깠더니 좀 정신이 없군요.
|
|
|
|
|
| ... / 04-06-25 15:35/
신고
|
|
으음, PC가 엉뚱한 데로 점프한 다음에 살아있을 수 있는 CPU도 있었나 보군요. CPU가 죽은 다음에야 보안이건 뭐건 따질 여유도 없을 터인데.
그런데 누가 요즈음 핸드 어셈블리를 그렇게 수많을 정도로 쓸까요? 애플리케이션에서야 어쩌다가 인라인 어셈블리어를 쓸까말까이고 OS조차도 포팅에 직접 관계되는 로우레벨의 부트업에 엔트리 부분만 빼고는 거의 C/C++이구먼.
|
|
|
|
|
| ... / 04-06-25 15:41/
신고
|
|
아무튼 해당 문제는 로직상의 오류가 아니라 마이크로 코드의 버그로 인한 것이기 때문에 바이오스에서 마이크로코드 업데이트 부분을 패치하면 해결된다는 내용이더군요.
때문에 기본적으로 로직 자체의 문제로 인해 코드 패치 정도로는 완전한 해결이 불가능했던 95년의 펜티엄 실수연산 오류하고는 치명도 면에서 비교가 되지 않죠.
|
|
|
|
|
| .. / 04-06-25 16:16/
신고
|
|
|
마이크로 코드 를 업데이트 하는부분은 저도 잘 모릅니다만 펜티엄 실수연산오류랑 차원이 다르게 위험한것은 서버 상태일때 입니다. strlen, memcpy 다 rep movs 같은걸로 구현합니다. 아니면 일반 컴파일러 컴파일시 순간순간 수시로 사용합니다. 머 exe덤프떠서 보시면 간단히 보실수 있으실테고.. 이게 위험한건 네턱시 버퍼오버플로 공격에 무지 취약하단 것입니다. 확률이 낮게 발현하는건 확실하진 않지만 파이프라인 값 즉 전방후방 명령어 배치의 패턴에 따라 문제생길 공산이 큰데 어찌됬건 그 패턴을 확실히 알아놓으면 바로 버퍼 오버플로 공격에 악용될 소지가 큽니다. 하다못해 ring 0 상태의 커널단계서 램복사가 재수없게 작살날 소지도 많습니다. 실수의 경우 혼자 이상한 값 뱉고 죽으므로 그것도 치명적인데 이경우는 보안문제상 아주 위험하죠. 작당하고 오작동나도록 pc카운터 유도하고 거기다가 웜코드 스타트 부분 넣어놓으면 바로 골로갑니다. 해결이야 요즘 다 됩니다. 어차피 H/W명령어들이 아닌 시피유 들이니깐요 안에서 가상으로 risc전환되기도 하고 샛길은 있을겁니다. C/C++ 코드 여러종류별로 함 짜보시고 디스어셈 덤프뜨시기 바랍니다. 오류란 낮은확률을 가지고 있는 발견하기 힘든 오류이면서 동시에 시스템 장악력을 가지고 있는것이 위험한 것입니다. 만약 버그가 APIC문제다 이런 류라면 전력소모량 예측보다 더 크거나 등등 이런문제 정도 혹은 절전모드만 하면 재수읍게 죽어요 등등이겠지요. 글고 대부분 code들은 page 의 빈칸을 nop로 채웁니다 pc잘못날라가면 살거나 혹은 os 내부 에러메세지 보셨나요? 리눅스 커널 개발단계버젼의... 내부에러 꽤 됩니다만 안죽고 유저레벨 플그램들 돕니다. 좀불안하죠.. 자신이 무슨이야길 하는지 로직을 완전히 모르신다면 말씀 안하시는게 좋다고 봅니다. 저도 아는게 이정도가 한계라 마이크로 코드 이하는 잘 말씀드리기가 힘들군요
|
|
|
|
|
| 걍 / 04-06-25 16:26/
신고
|
|
->으음, PC가 엉뚱한 데로 점프한 다음에 살아있을 수 있는 CPU도 있었나 보군요. CPU가 죽은 다음에야 보안이건 뭐건 따질 여유도 없을 터인데
pc가 엉뚱한데로 jmp하면 왜 죽는지 생각해 보시면될듯한데..
user program일경우 pc가 엉뚱한데로 jmp하면 그놈만 kill당하면 끝입니다.
정말 재수없는경우 시스템 메모리를 건드려 os가 자폭할수도 있겠지여.
그리고 os레벨에서 이상한데로 jmp할경우 그것이 event적으로 발생된 스트림이라면 보통 "가까스"로 살릴수 있는 경우도 있죠. linux kernel을 들여다 보시면 제가 따옴표친대로 "가까스"로 살려볼려고 닭짓해논데가 쫌있지요
물론 보통 kernel레벨에서 뛰어버리면 사실 못산다가 맞긴합니다만..
본내용과는 관계없지만 잠시 님의 글일부만 반박했습니다.
|
|
|
|
|
| 걍 / 04-06-25 16:32/
신고
|
|
그리고 손으로 어셈블러를 자주 짜는
저같은 사람은 쫌 이상한 부류이긴 하군여..
하지만 무슨 UI가 하는일 전부인 플그램이나 java로 다짜지 않는이상
10만라인에 최소 1-2000라인은 asm으로 짜는데 저랑 님이랑 필드가 틀려서 그런것 같군요.
하긴 java로 짜더라도 java돌리는 vm은 손으로 어셈블러 마니짰지여 ㅋㅋ
|
|
|
|
|
| needled247 / 04-06-25 17:16/
신고
|
|
느낌이 좀 호들갑 떠는것 같군요.
어셈블리는 꼭 필요한 곳 아니면 안쓰는게 당연합니다. 서버가 어쩌고 안정정 운운하던데, 핸드라이팅 어셈블리하면 프로그램의 안정성이 증가하던가요? VM이 아니라 OS를 짠다고 해도 필요한 곳 빼면 C로 짜야죠.
요즘은 성능상으로도 핸드어셈블리가 별 매력이 없다는걸 잘아실텐데요. rep 시리즈 명령어는 워낙 구닥다리라서 그나마 rep movs 빼고는 성능상으로도 별로 나을게 없다는 것도... 작정하고 SIMD같은거 적용한다면 또 몰라...
|
|
|
|
|
| needled247 / 04-06-25 17:26/
신고
|
|
한마디 더하면 여기에도 AMD64 시스템 문제있다고 리포트한 글이 있네 하고 올리는것도 성급하고 좀 유치한 짓인거 스스로도 아시죠? 그 글 읽어봤으면 아래 리플단것처럼 보드문제일 가능성이 당연한 것이니 말입니다.
그런데도 쓰는 사람이 없어서 그렇다는둥... 아무리 AMD64가 안팔려도 특정상황에 관계없이 하루에 8-9번 다운되는 문제가 이번 같은 AMD64의 일반적인 문제라면, 과연 보드나라 유저 중에 AMD64 사용자가 1명이겠습니까?
|
|
|
|
|
| ... / 04-06-25 18:00/
신고
|
|
약간 이해를 잘 못하시는 것 같은데 기본적인 REP MOVS정도가 오류를 내면서 작동한다면 코드건 데이터건 몽땅 오류가 발생할 수 있다는 이야기이고 그정도면 애플리케이션에서 뻑난 다음 커널레벨에서 해당 애플을 킬 시키고 정상동작 시킨다고 해도 그 다음에 계속될 오류를 잡는다는 보장이 전혀 없다는 겁니다.
왜냐? 커널이라고 해서 코드가 잘못되지 말라는 보장이 전혀 없기 때문이죠. 그정도면 보안상의 공격같은건 아주 부차적인 문제일 뿐입니다. 컴이 정상으로 단 몇초라도 돌아야 공격을 하건 말건 할 것 아닙니까?
해당 버그는 마이크로코드의 버그이고 그 문제는 CPU의 POST과정에서 CPUID를 받은 다음 마이크로코드를 패치하면 해결되는 문제입니다.
그리고 애슬론64가 출시된 이후 109(!)번째로 발견된 버그이지요.
|
|
|
|
|
| 이제 그만 / 04-06-25 19:23/
신고
|
|
이제 그만.
그냥 취향과 성능에 맞는 서버 쓰시고 이제 그만~
|
|
|
|
|
| ... / 04-06-25 19:28/
신고
|
|
..님의 보안 부분에 대한 언급은 확실히 일리가 있습니다. 그 부분은 제가 틀렸군요.
마이크로코드 패치가 안되고 일반코드가 해당 버그에 대한 대응이 되어 있을때 고의적으로 에러를 유발할만한 악성 코드를 삽입한다면 확실히 보안 부분에서도 충분히 문제를 발생시킬 소지가 있군요.
물론 마이크로코드 패치가 된 POST과정 이후에는 문제가 되지 않으리라 봅니다.
|
|
|
|
|
| needled247 / 04-06-25 21:58/
신고
|
|
또다시 109번째라는걸 강조하는군요. 그런식이 바로 호들갑이라는 얘깁니다. 인텔 CPU에 버그가 실수연산 버그만 있었던것도 아니고, 대중에 알려지지 않고 은근슬쩍 넘어가는 버그가 더 많은데... rep movs의 중요성을 얘기하고 싶으면 그것만 얘기하세요.
그리고 보안문제. 뭐 OS 자작해서 쓰십니까? 보안문제 날 소지는 무지하게 많습니다. MS가 서버/워크용으로 처음만든 NT3.1은 서비스팩 3정도 나올때까지는 엉망이었다고 해도 과언이 아닙니다. 지금 2000이나 2003, 리눅스라고 해서 문제가 깨끗이 해결된 것도 아니고요.
문제가 발견되서 악용되기 전에 해결책이 나오는게 중요한건지, 완전무결한 제품이 있기를 바라는건지 묻고 싶군요.
|
|
|
|
|
| 다스베이더 / 04-06-26 11:28/
신고
|
|
다덜 황이요 집에들 들어가서 발씻고 주무시요 승자는 needled247님이요 다들 고개 숙이시요.
별것도 아닌 문제인데 뭘그리 호들갑이요.
|
|
|
|
|
| 문제 / 04-06-26 12:56/
신고
|
|
일반적인 사용에 있어서는 문제가 없다고 봐도 무방할듯 합니다. 제 경험에 의하면 델파이에서 컴파일링시에 문제가 있었습니다.
제출용으로 만든 용량이 작은 프로젝트를 HDD 내에서 컴파일시에는 정상 동작 하였으나, FDD로 컴파일시에 디버그 창에 프로세서 에러가 발생하면서 엉뚱한 연산을 계속 해 대더군요. 4월말쯤에 있었던 일이고 AMD코리아에 문의를 할려고 했으나, 개인적으로 AMD코리아 직원분들에게 열받는 일이 있어서 걍 X먹어봐라고 가만 있었는데..이제서야 일이 터졌군요.
그래도 엔지니어들이 알아서 발견하고 패칭했다고 하니 다행이라는 생각도 듭니다. 새 BIOS 깔아서 그때 그 프로젝트 다시 컴파일해봐야 겠습니다.
|
|
|
|
|
| 염성비제 / 04-06-28 9:20/
신고
|
|
머 기술적인 문제는 모르겠고 댓글을 잃어 보니..
댓글 단 분의 이야기가 사실이라면..
버그를 자체적으로 발견하고 그걸 아무도 모르게 업데이트할수 있는것을 모두에게 알리고 공지를 때린 AMD에게 점수를 주고 싶네여..
|
|
|
|
|
| ... / 04-06-30 11:53/
신고
|
|
제가 강조하는 것도 버그 문제가 지나치게 과장되었다는 점입니다.
109번째라는 점을 지적한 것은 마이크로프로세서의 버그는 호들갑을 떨 정도로 이례적인 것이 아니라 거의 통상적인 것이라는 점도 빼놓을 수 없죠.
CPU는 버그덩어리입니다. OS는 더더욱 버그덩어리죠. 애플리케이션도 버그덩어리입니다.
버그는 일상사이며 없애야 할 대상이지만 현실적으로는 없앨 수 없고 때문에 대처와 관리를 시스템적으로 안정적으로 할 수 있는가가 중요합니다.
그점에서 버그 하나를 가지고 치명적이느니 아니니 떠드는 것보다는 -REP MOVS에 관련된 버그가 전반적이면서도 치명적이었다면 옵테론 C0은 출시도 되기 전에 빠꾸먹었을 겁니다.- 과연 그것을 발견하고 관리하는 시스템이 얼마나 잘 정립되어 있는가를 보아야 한다는 것이죠.
|
|
|
|
|
| ... / 04-06-30 11:57/
신고
|
|
그점에서 봤을때 정말 위험한건 애슬론64가 아니라 프레스캇 버그의 관리실태입니다.
버그가 발견하고 공지되었으나 피해가는 방법이나 해결 예정으로 포스팅 된 게 지나치게 적습니다. 엔지니어링 샘플이 나오기 시작한지 1년이나 지난 CPU가 말입니다.
발견된 버그 31개 중에 해결된게 3개고 해결예정인게 5개? 개그죠 개그.
|
|
|
