김민식

펌웨어에서 GPL 소프트웨어인 리눅스나 비지박스를 썼는지 여부를 검사하는 도구가 나왔다고 한다. 원래의 기사 제목은 거창하게도 “New binary analysis tool finds FOSS in device firmware”이지만, 실상은 단순히 리눅스와 비지박스 소스를 차용했는지 여부를 검사하는 도구이다. 파이썬 스크립트라고 하는데, 소스를 받아보지는 않았지만 기사의 설명으로 보아 백신 프로그램이 바이러스를 찾듯이 특정 문자열이 포함되어 있는지를 검사하는 것으로 보인다.

GPL 소프트웨어를 만든 사람들이 자신들의 권리를 찾겠다는 것에 대해서는 적극 지지하는 바이다. 애초에 “이런 방식으로 사용을 허가하겠다”고 내어놓은 소프트웨어를 다른 방식으로 전용하는 것은 제작자의 명백한 권리를 침범하는 행위이기 때문이다. 하지만 이와 동시에 일부 사람들이 GPL을 주장하면서 “자유(freedom)”를 겉면에 내세우는 것은 위선이라고밖에 말할 수 없다. 소스를 공개하지 않는 상용 소프트웨어와 이렇게 검출 도구까지 써서 위반 사례를 적발해내는 GPL 소프트웨어의 차이는 무엇일까? “내가 허락하는 방식으로만 내 소프트웨어를 써야한다. 그렇지 않으면 고발하겠다.”라는 점에서는 대동소이하다. GPL의 경우 “허락하는 방식”에 몇 가지가 더 추가된다고는 하나 근본적으로는 사용자에게 “이러이러한 방식으로 쓰지 마라”라고 하는 것이 주된 목적이다. 게다가 GPL은 버젼이 올라가면서 금지 조항이 늘어나고 복잡해져서 이제는 일반인이 읽어서는 도대체 뭘 해도 된다는 것인지 알기 힘든 지경에 이르렀다.

GPL이 나쁘다는 것이 아니다. 내가 만든 소프트웨어에 어떤 라이센스를 적용할 것인가는 제작자의 고유한 권한이다. 하지만 그 권한을 행사하면서 자신의 선택이 마치 다른 사람들의 “자유”를 위한 것인 양 우쭐대지는 말아야 할 것이다. 내 소프트웨어를 쓰고자 하는 사람에게 정말로 자유를 주고 싶어하는 사람들은 GPL을 쓰지 않는다. NetBSD 개발자인 후베르트 파이러씨의 말마따나 GPL을 쓰는 사람은 자신의 코드가 다른 제품에 쓰인 것을 발겼했을 때 “이런, 이놈들이 내 코드를 썼어(argh, they use my code!)”라고 분개하고, 내가 좋아서 프로그래밍을 하는 사람은 같은 상황에서 “내 코드가 쓰이다니, 기분 좋은걸(cool, they use my code!)”하며 기뻐하는 법이다.

원격으로 컴퓨터에 접속할 필요가 있을 경우 가장 많이 쓰이는 것이 SSH일 것이다. 예전에 쓰이던 rlogin이나 telnet과는 달리, 암호나 전송 내용을 드러내지 않을 수 있어서 이제는 거의 필수 도구로 자리잡았다. 특히 OpenSSH는 무려 80%가 넘는 점유율을 보이고 있어서, SSH를 쓴다고 하면 OpenSSH가 설치되어 있다고 보아도 무방할 정도이다. 그런데 이런 중요한 소프트웨어에서 암호화된 메시지가 드러날 수도 있는 문제점이 발견되었다. 게다가 대부분의 보안 결함처럼 단순히 소프트웨어의 버그로 인한 것이 아니라, 표준으로 나와 있는 RFC 자체에 문제가 있는 것이어서 더욱 심각하다.

다행인 것은 실제로 피해를 입을 확률이 낮다는 것이다. 지난주 18일에 발표된 논문(PDF)에 따르면 32비트 분량의 메시지를 해독할 확률이 약 26만분의 일이다. 그렇지만 SSH가 안전하다고 철석같이 믿고서 매우 중요한 메시지를 주고받는데에 사용한다면, 이번에 발견된 보안 결함에 대한 대비책을 세울 필요가 있다.

공격 원리는 비교적 간단하다. 가장 많이 쓰이는 모드인 CBC의 경우, SSH는 일단 메시지 길이를 받은 후, 해당 길이만큼을 네트워크로부터 받아들여 복호화를 하는데, 메시지 길이 조차도 암호화되어 있어 그걸 먼저 복호화해야만 한다. 복호화한 메시지에 오류가 있다면 SSH는 에러를 내고 연결을 끊어버린다. 다시 말하면, 일부러 오류가 있는 메시지를 보내는 경우 SSH가 몇 바이트를 읽고서 연결을 끊는지를 보면 암호화된 메시지 길이 값을 알 수 있다는 것이다.

그렇다면 메시지 길이 대신에 공격자가 복호화하고 싶은 내용을 보내면 어떻게 될까? SSH는 그 내용이 무엇이건 그걸 숫자로 간주, 그 값만큼 메시지를 읽어들일 것이고, 애시당초 메시지 길이가 아닌 값이므로 메시지 복호화 후 에러를 낼 것이 거의 확실하다. 일단 에러가 발생해서 연결이 끊기면 공격자는 그때까지 보낸 메시지 길이를 확인하여 자신이 복호화하고 싶었던 내용을 알아낼 수 있는 것이다.

OpenSSH 5.2에서는 이 문제가 해결되었으므로, 32비트조차도 절대로 남에게 넘겨줄 수 없다면 OpenSSH를 업그레이드하는 것이 최선이다.

올해의 두번째 안정 브랜치를 내놓기 위해 pkgsrc가 동결에 들어갔습니다. 당분간은 새로운 패키지 추가나 pkgsrc 내부의 변경은 자제하고, 버그 수정에 주력하게 됩니다.

이번 브랜치에서는 무엇보다도 루비 관련 패키지들이 대폭 개선됩니다. 우선 루비 패키지 자체가 1.8.7.22로 갱신되면서 Mac OS X에서의 빌드 문제 등이 다 사라졌고, 대부분의 루비 패키지들을 pkgsrc 차원에서 루비젬을 이용하여 설치하도록 바뀌어서 앞으로 새 루비 패키지의 추가 및 기존 패키지의 갱신이 간단해졌습니다. 그 덕에 이번 브랜치에는 루비 온 레일즈를 포함한 대부분의 루비 패키지가 최신 버젼으로 제공될 겁니다.

새 브랜치는 7월 초쯤 보실 수 있습니다.

NetBSD의 라이센스는 애초에 캘리포니아 버클리 대학에서 BSD에 사용했던 4조항짜리 라이센스였습니다. 이중 세번째 조항(일명 advertising cluase)이 해당 소프트웨어의 모든 광고 자료에 저작권자의 이름을 명시해야한다고 하고 있는데, 여기저기서 소스를 가져온 대규모 오픈 소스 프로젝트에서는 이 조항이 현실적으로 지키기 어려워서 불평이 많았습니다. 그 결과 캘리포니아 버클리 대학을 비롯, 많은 프로젝트에서 해당 조항을 삭제한 3조항짜리 라이센스로 변경했지만, NetBSD는 4조항 라이센스를 고수해왔습니다. 하지만 이번에 시대의 요구에 부합하기 위해 말썽많은 세번째 조항을 삭제하고, 더 나아가 사실상 실효성이 거의 없는 마지막 조항마저도 삭제한 2조항짜리 라이센스로 변경했습니다. 아마도 CVS나 source-changes 메일링 리스트를 자주 보시는 분들이라면 최근 얼마간 NetBSD 소스의 라이센스가 대부분 변경된 것을 아셨을겁니다. NetBSD의 소스에 기반한 프로젝트를 진행하시는 분들께는 라이센스를 지키는데에 있어서 성가신 부담 하나가 사라진 반가운 소식입니다. 이제 NetBSD는 저작권과 라이센스만 명시하면 어떤 용도로든 자유롭게 사용할 수 있는 소프트웨어가 되었습니다.

NetBSD 4.0이 드디어 나왔습니다. 안정 브래치가 생성된 후 꼬박 일년이 걸렸군요. 중간에 한번 안정브랜치를 통째로 갈아엎는 일이 생기는 바람에 많이 늦어졌습니다. 3.0과 비교해보면 2년마다 새 버젼이 나오는 셈인데, 하루가 다르게 새로운 기능들이 추가되는걸 생각하면 좀 더 자주 새 버젼을 발표하는게 좋지 않을까 합니다. 다만 그러려면 안정 브랜치 관리에 들어가는 시간과 노력이 커질테니, 자발적인 참여로 이루어지는 오픈소스 프로젝트에서는 감당하기 힘들어질 수도 있겠죠.

CVS에서는 netbsd-4-0-RELEASE 태그로 받으시면 됩니다.

참고로, 이 글이 이 사이트에 쓰는 마지막 글이 될 지도 모르겠습니다. 호스팅하는 기계의 사정으로 다른곳으로 옮겨야해서요. 새로 옮겨갈 곳은 리소스 제한이 심해서, 루비 온 레일즈 애플리케이션을 돌리기는 쉽지 않을 듯 합니다. 피드버너의 XML 피드 주소는 그대로 유지할 예정입니다.

(12월 17일) 옮겼습니다.

NetBSD 4.0 정식 발표에 한발 더 다가섰습니다. RC2 발표 이후 바뀐 내용들은 CHANGES-4.0 파일에서 볼 수 있습니다. 아직 netbsd-4 브랜치에 반영되지 않은 풀업이 좀 남아 있어서, 바로 4.0으로 갈지, 아니면 한번 더 RC를 거칠지는 모르겠네요.

최근 몇달간 NetBSD CVS가 상당히 바쁘게 돌아가고 있습니다. 메일링 리스트에 연일 새로운 기능과 그 성능에 대한 얘기가 끊이질 않는군요. 대부분은 별도 브랜치를 만들어 구현해오던 것들인데, 최근들어 -current로 통합이 되었습니다. 굵직한 것들로는 멀티프로세서에서의 성능 개선과 새 malloc 등이 있었는데, 이번주에는 Mindaugas Rasiukevicius씨가 만든 새로운 스케쥴러도 통합이 되었네요. 이것도 최근 추세에 따라 MySQL SysBench 결과가 올라왔습니다. 쓰레드가 하나인 경우에는 기존의 스케쥴러(SCHED_4BSD, 빨간색)와 별 차이가 없지만, 쓰레드가 많아지면 새 스케쥴러(SCHED_M2, 연두색)가 무려 50%나 더 많은 트랜잭션을 처리할 수 있습니다. 연이은 벤치마크 결과를 보고 있으니 제 데스크탑도 어서 프로세서가 여러개 달린 놈으로 바꿔야만 할 것 같은 생각이 듭니다.

pkgsrc의 2007년 세 번째 안정 브랜치가 나왔습니다. 이번에는 Joerg Sonnenberger씨가 구글 Summer of Code 프로젝트로 만든 새 벌크 빌드 시스템을 추가하고, pkg_* 명령들을 개선하느라 시간이 좀 더 걸렸습니다. 지난번 안정 브랜치 발표때보다 일주일정도 늦어졌네요. 이번 브랜치는 특히나 pkgsrc의 탄생 10주년을 기념하는 브랜치여서 특별히 안정성에 주의를 기울이다보니 동결기간도 길었습니다.

tar 파일이 준비되는대로 메일링 리스트를 통해 공식 발표가 있을겁니다. 새 pkg_install에는 기존에는 별도 패키지로 제공되었던 audit-packages의 기능이 포함되어 있고 속도고 이전 버젼보다 많이 빨라졌으니, 개별 패키지만 업데이트해가며 쓰시던 분들이라도 이번엔 pkg_install을 업데이트하는 것을 권장합니다.

프로그램 수행시 malloc(3)만큼 많이 불리는 함수도 많지 않습니다. 아주 간단한 프로그램이 아닌 다음에야 메모리를 할당은 거의 필수죠. 대부분의 프로그램에서 쉴새없이 메모리를 할당하고 해제하는 일을 반복하다보니, 효율적으로 메모리를 관리한다는게 쉬운 일이 아닙니다. malloc이 하는 일은 겉으로는 빈 메모리 찾아서 돌려주는 단순한 작업처럼 보이지만, 실제로는 장기적으로 메모리를 쓰는데에 문제가 없도록 온갖 뒷치닥거리를 해야만 합니다. 특히나 프로세서도 여러개이고 쓰레드도 여러개가 함께 돌아가는 상황이 되다보면 malloc이 얼마나 일을 잘 하느냐가 전체 시스템의 성능에 큰 영향을 주게 됩니다. malloc이 제 몫을 못할 경우 얼마나 치명적인지 Andrew Doran씨의 벤치마크 결과를 보면 잘 알 수 있습니다. 파란 선과 분홍색 선을 비교해보세요. 둘 다 Linux 2.6.21인데, 하나는 glibc에 있는 malloc을 그대로 쓴 것이고, 다른 하나는 구글에서 만든 thread-caching malloc을 쓴 것입니다. glibc의 malloc으로는 쓰레드 수가 늘어남에 따라 처리할 수 있는 트랜잭션 수도 증가하다가, 쓰레드가 프로세서보다 많아지면 갑자기 불안한 모습을 보이면서 최고 성능의 60% 수준으로 주저앉고 맙니다. 그러나 tcmalloc을 쓰게 되면 이런 문제가 전혀 없고, 쓰레드 수가 늘어나더라고 일정한 성능을 유지합니다.

FreeBSD에서도 malloc이 병목이 되는 상황이 종종 발생하자, 작년 BSDCan에서 Jason Evans씨가 발표한 jemalloc으로 바꾸어버렸습니다. jemalloc에 대한 자세한 내용은 Evans씨의 논문에 잘 나와있습니다.

NetBSD는 그동안 다중 프로세서 지원이 워낙 미흡했기에 malloc이 병목이 될 기회조차 없었는데, 이번에 Andrew Doran씨가 다중 프로세서에서의 성능을 크게 향상시키면서 며칠 전 malloc도 jemalloc으로 교체해버렸습니다. 이제 NetBSD-current에서는 jemalloc을 기본으로 사용하며, 혹시라도 이전의 malloc을 계속 쓰려면 USE_JEMALLOC을 no로 설정해주어야 합니다. Kris Kennaway씨의 벤치마크 결과를 보면 jemalloc을 쓴 경우(보라색)가 안 쓴 경우(파란색)보다 약 30% 정도 성능이 향상된 것으로 나옵니다.

아직 4.0도 나오지 않았는데, 벌써부터 5.0이 탐이 나네요.

며칠 전 Andrew Doran씨가 NetBSD-current의 SysBench 결과를 리눅스, FreeBSD, OpenBSD와 비교한데에 이어 Jaime Fournier씨가 솔라리스와 비교한 결과를 공개했습니다. 읽기만 한 경우랑 읽기와 쓰기를 모두 한 경우를 나누어서 비교를 했는데요, 역시나 NetBSD-current가 더 나은 성능을 보여주고 있습니다. 읽기만 한경우 전반적으로 솔라리스에 비해 40%정도 더 많은 트랜잭션을 처리하고, 읽기와 쓰기를 모두 한 경우는 두 운영 체제가 대체로 비슷하지만 클라이언트 수가 12-20개인 구간을 제외하고는 NetBSD가 근소하게나마 우세하군요. 이번 비교는 클라이언트 수가 50개일때까지(지난번은 20개까지) 시도해 본 것인데, 클라이언트 수가 늘면서 성능이 상당히 완만하게 떨어지는 것으로 보아 리눅스처럼 일정 수(15개) 이상에서 불규칙한 행태를 보이는 일도 없는 것 같습니다. 뛰어난 결과를 만들어낸 Andrew Doran씨에게 찬사를 보냅니다.