|
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
|
어제 개발자 분들과 술을 한잔 하다가 재미난 이야기를 들었습니다. 드라이버를 만들면 릴리즈 버전에서도 항상 디버깅 정보가 포함된다는 이야기였죠. 저는 '그럴리가요?'라고 했죠. 일반적으로 어플리케이션의 경우에는 프로젝트 속성을 조절해서 디버그 정보 유무를 결정할 수 있기 때문입니다. 그런데 드라이버는 잘 몰라서 거기서 어떻게 하는지는 모르고 있었습니다. 어제 화두를 던졌던 window31님 말씀으로는 DDK 버전별로 차이가 있는것 같다고 하시더군요. 문득 오늘 술깨고 생각나서 간단한 드라이버를 만들어 보았습니다. DriverEntry만 만들어서 XP free 환경에서 빌드를 해보았습니다. 후훗. 그런데 어제 들은 이야기대로 릴리즈 버전임에도 버젓히 디버깅 정보가 들어 있더군요. 아래 그림처럼 드라이버 파일에 빌드한 환경의 전체 경로가 나옵니다.  이런걸 몹시 찝찝해 하시는 분들도 계시죠. 그래서 왜 그럴까? 하고 뜯어 봤습니다. ddk 문서도 찾아보고 링커 옵션을 제어할 수 있는 방법도 찾아보고 해도 딱히 방법이 없더군요. NTDEBUG를 통해서 조절하라는 이야기가 있었는데 해보니까 안됐습니다. 그래서 DDK를 빌드하는 실제 makefile을 열어봤습니다. 제 버전의 경우에는 DDK 설치 폴더에 bin 밑에 있더군요. makefile.new입니다. 파일을 쭈욱 내려가다 보면 아래와 같은 부분이 보입니다. !ifdef RESOURCE_ONLY_DLL # Resource only DLL's have no exports, no entrypoint, no code, no data, no debug symbolic. LINKER_DBG_SECTION=-debug:NONE NO_DLL_EXPORTS=1 !undef NTBBT !undef DLLENTRY !undef NOLINK NO_BROWSER_FILE=1 LINK_NO_RELEASE=1 MAKEDLL=1 TARGETLIBS= LINKLIBS= USE_NOLIBS=1 NO_NTDLL=1 AFX_FORCE_STDAFX= AFX_FORCE_USRDLL= MFC_LIBS= !else LINKER_DBG_SECTION=-debug AFX_FORCE_STDAFX=/include:__afxForceSTDAFX AFX_FORCE_USRDLL=/include:__afxForceUSRDLL !endif 훗. 그렇죠. 리소스 온리 DLL이 아니면 항상 디버그 정보가 포함이 되는 겁니다. 따라서 밖에서 무엇을 해줘도 항상 디버깅 정보가 포함되는 거죠. 알았으면 고쳐야겠죠. 시스템 파일을 고치는 거라 좀 찝찝하시다면 복사해서 고치셔도 됩니다. 전 아래와 같이 고쳤습니다. !if "$(DDKBUILDENV)" == "fre" LINKER_DBG_SECTION=-debug:NONE !else LINKER_DBG_SECTION=-debug 고친 다음 다시 빌드를 해보면 릴리즈 버전에서는 더 이상 디버그 정보가 포함되지 않는다는 걸 알 수 있습니다.  |
 책소개 Secure Coding in C and C++ 편리한 세상이다. 은행에 가지 않고도 컴퓨터 앞에서 인터넷 뱅킹을 이용해서 거래를 할 수 있고, 증권사에 직접 전화를 걸지 않고도 HTS를 사용하면 원하는 대로 주식을 사고 팔 수 있다. 더 이상 약도를 그려주지 않아도 된다. 주소만 불러주면 GPS를 사용한 네비게이션 시스템이 현재 위치에서의 최단 거리를 찾아주기 때문이다. 휴대폰 속 전화번호부 기능은 너무 좋아서 요즘은 전화번호를 외우고 다니는 사람을 만나기가 힘들다. 점점 더 많은 일들이 컴퓨터로 처리되고 있고, 사람의 손이 개입되지 않는 일들이 늘어나고 있다. 이런 시대에 개발자로 살아가는 필자에게 가장 먼저 드는 생각은 ‘위험하다’라는 것이다. 자동화 될수록 편리함은 늘어나지만 뭔가 오류가 발생했을 때 바로잡는 과정이 힘들어지기 때문이다. 의도하지 않은 계좌로 잔고가 빠져나간다거나, 자신이 원하지 않는 시점에 주식이 팔린다거나 하는 일들이 벌어질 수 있다. 더 이상 영화 속 이야기가 아니다. 실제로 얼마 전 필자와 같이 근무하는 동료 한 분은 ATM 기계의 오류로 이러한 일을 겪었고, 매우 힘들게 잘못된 금액을 다시 계좌로 돌려 받을 수 있었다. ATM 기계에 오류가 발생했다는 그 쪽지 한 장이 없었다면 그마저도 돌려받지 못하는 상황이 발생할 뻔 했다. 이런 ‘위험함’을 보다 더 잘 느끼기 위해서는 좀 더 극적인 시스템을 생각해 보는 것이 도움이 된다. 로켓이나 수술실에 들어가는 프로그램을 상상해보자. 과연 이러한 프로그램 속의 버그가 문제를 일으킨다면 어떻게 될까? 그 대가는 몇 천억의 예산이 집행된 프로젝트의 실패나 한 사람의 죽음을 의미한다. 실제로 아리안 5호는 정수 오버플로 문제로 발사 40초 만에 폭발했다. 아리안 5호의 총 개발비는 80억 달러의 이른다. 물론 많은 개발자들이 이런 극도로 미션 크리티컬한 시스템 개발에 참여하고 있는 것은 아니다. 하지만 분명히 알아야 할 점은 사회가 점점 자동화되고 고도화될 수록 시스템간 결합도는 증가한다는 점이다. 자신이 만든 사소한 시스템이 언제 그러한 시스템과 결합될지는 모를 일이다. 위험한 세상이 오고 있음에도 많은 개발자들은 여전히 안전 불감증 상태다. 자신이 만든 프로그램의 어디가 위험한지, 안전하게 만들기 위해서는 어떤 부분들에 신경을 써야 하는지를 모르는 경우가 대부분이다. 돌아가기만 하는 프로그램을 만드는데 급급한 사회적 풍토 때문인지도 모르겠다. 하지만 앞으로는 단지 돌아가는 것만으로는 부족하다. 안전하게 만드는 것이 더 중요한 시대가 오고 있다. Secure Coding in C and C++은 C/C++개발자들이 이러한 부분을 인식하는데 좋은 출발점이 될 수 있는 책이다. 어떤 부분이 위험한지 문제를 보여주고 그것에 대한 대처 방법을 상세하게 소개한다. 300페이지가 조금 넘는 얇은 책 속에 이론과 실전을 담백하게 담아내고 있다. 지나치게 원리에 치우친 기존 책들의 무거움과 특정 플랫폼의 안전한 라이브러리 사용법에 초점을 맞춘 책들의 가벼움 사이의 중간을 잘 절충한 책이다. C/C++ 프로그램의 대표적인 취약점으로 꼽히는 문자열, 포인터, 동적 메모리, 정수 오버플로, 형식 문자열, 파일 I/O에 관해서 한 장씩 할애해서 자세하게 설명하고 있다. C/C++의 경우 하드웨어와 매우 밀접한 언어이기 때문에 일부 내용은 컴퓨터 구조의 문제이기도 하다. 따라서 C/C++ 개발자가 아니라고 하더라도 한번쯤 읽어보는 것도 좋은 선택이 될 것 같다. |
|
2008년 새해가 밝았습니다. 요런 포스팅을 하기에는 정말 뒷북이겠죠? 그냥 저냥 그동안 버로우 하고 있었습니다. 회사 분이 선물해 주신 프랭클린 다이어리 마지막 페이지에는 다음과 갈은 이야기가 적혀 있더군요. 인생을 사랑한다면 시간을 낭비하지 마라.훗.정말 솔직담백한 이야기죠. 거창하게 생각할 것도 없이 인생이란 우리에게 주어진 얼마간의 시간인 것 같습니다. 그 시간동안 위대한 일을 하는 사람도 있고, 남에게 피해를 주는 사람도 있고, 아무 것도 하지 않는 사람도 있죠. 물론 악플달고 시간 때우는 사람들도 있습니다. 흐흐~~ 그 시간 동안 무엇을 할지는 전적으로 자신이 결정하는 것이겠죠. 전 인생을 사랑하지만 얼마간은 제 시간을 좀 낭비하고 싶습니다. 때로는 그런 시간도 필요한 것 같아서요. ㅎㅎ 새해에는 이 글을 읽으시는 모든 분들께 기적 같은 일들만 벌어지기를 소망해 봅니다. 물론 좋은 의미의 기적같은 일이겠죠? ㅋㅋ 새해 복 많이 받으세요 ^^;; |
