Taeguk's Blog

이번에 인텔 CPU 보안취약점 (멜트다운) 관련해서 쉽고 잘 설명해놓은 좋은 글을 발견해서 공유합니다~ http://blog.cyberus-technology.de/posts/2018-01-03-meltdown.html (Trying it all together 부분만 읽으시면 됩니다. 짧습니다.) 간단하게 한번 끄적여보자면,,,, 다음과 같은 연속된 instruction들을 실행합니다. 1. 값을 얻으려는 특정 커널메모리 주소에 접근하여 값을 1바이트 읽습니다. 2. 1번에서 얻은 값에 4096을 곱합니다. 3. (미리준비된 충분히 큰 버퍼의 주소 + 2번에서 얻은 값) 의 주소에 접근합니다. (여기서 "충분히 큰" 이란 4096 * 256 바이트를 의미합니다.) 실제 cpu는 이 instruction들을 동시에 실행하게 됩니다. 그러나 instruction들의 실행 결과가 실제로 반영이 되는건 차례대로 반영이 되게 되는데, 1번에서 접근권한이 없어서 예외가 발생하므로, 저 instruction들의 결과가 실제로 반영이 될 순 없습니다. (Exception Suppression을 위해서는 Intel TSX 를 사용한다고 합니다. 사용할 수 없는 환경에서는 그냥 Exception handling) 그러나, 3번에서 비록 실행결과가 반영이 되진 않더라도, 실행과정에서 (미리준비된 충분히 큰 버퍼의 주소 + 2번에서 얻은 값) 의 주소의 메모리가 cache 되게 됩니다. 그 후 (미리준비된 충분히 큰 버퍼의 주소 + 4096 * 0~255) 의 주소에 각각 접근하면서 시간을 잽니다. (엄밀히 말하자면 Flush-Reload 라는 기법을 사용합니다.) 만약 가장 시간이 적게 걸렸을 때가 0~255중 74라고 한다면, (미리준비된 충분히 큰 버퍼의 주소 + 4096 * 74) 의 주소가 cache 됐다는 뜻이고, 즉 따라서 처음에 읽으려했던 커널메모리 1바이트의 값이 74인것 입니다! ...

34개월간의 산업기능요원 현역을 시작하게 됐다. 정당한 절차를 거친 것이긴 하지만, 다른 사람들에 비해 특혜를 누리는 것이기 때문에, 복무기간동안 사회를 위한 활동이나 기부같은 걸 해야겠다는 의무감이 든다. '진짜 현역'으로 군복무를 하신 분들에게 진심으로 존경과 감사를 표하며, 주변에 군복무를 당당하게 마친 친구들에게 식사나 술이라도 대접해야겠다고 생각하고 있다. 아무튼, 기나긴 병특 기간동안 개인적으로도 의미있고, 주변사람들에게도 도움이 될 수 있는 시간들을 보내고 싶다.

http://book.naver.com/bookdb/book_detail.nhn?bid=7405945 https://www.amazon.com/API-Design-C-Martin-Reddy/dp/0123850037 올해 9월 중순~말쯤에 내가 회사에 입사하고 나서, 팀장님께서 읽으라고 던져주신 책이다. C++언어를 이용해 API를 디자인하는 것에 대해 다루고 있다. 하지만, 비단 C++이나 API 디자인에 국한된 내용들은 아니다. 전반적인 소프트웨어 설계에 대해 영감을 얻을 수 있는 부분들이 많이 있다. 결론부터 말하면, 책이 굉장히 좋다...     이 책은 C++언어 자체적으로 고급적인 문법이나 스킬적인 부분, 그리고 디자인패턴적으로 고급적인 내용들을 다루지는 않는다. 다만, 내가 느끼기에는 다른 책들과는 다르게 좀 더 '현실적인' 관점에서 어떻게 소프트웨어를 잘 설계하고 프로젝트를 진행할 수 있는지에 대해 다루고 있다는 생각이 들었다.     "화려하고 기괴한, 마법같은" 과 같은 단어들은 이 책과 어울리지 않는다. 내가 이 책을 읽으면서 머릿 속에 떠올랐던 건 "투박하고 현실적인, 그렇지만 효과적인" 이런 단어들이다. C++쪽은 언어의 특성 탓인지 사용자들의 특성 탓인지, 다른 언어들에 비해 각종 기괴하고 마법같은 '언어적 기술'들이 많이 존재하고, 극단적으로 overhead를 없애거나 설계를 완벽하게 하려는 그런 점들이 많이 존재한다. 그런 것들은 기술적인 호기심을 자극하긴 하지만, 실제 팀내의 모든 사람들이 그것에 열의가 있거나 그것을 받아들일 역량이 있는 것은 아니기 때문에, 현실적으로 프로젝트에 적용하는 것이 쉽지 않다. 반면에 이 책은 그런 것들과는 다르게, 책 내용을 이해하고 활용하는데 고급적인 C++지식들이 필요하지 않고, 내용들이 상당히 유용하기 때문에, 진짜 현업에서 당장 적용할 수 있고, 당장 회사의 프로젝트와 팀에게 큰 도움을 줄 수 있을 것 같다는 생각...

https://www.amazon.com/Optimized-Proven-Techniques-Heightened-Performance/dp/1491922060 올 봄~여름쯤에 CppKorea에서 주최하는 스터디에 참가해서 읽었던 책이다. 'Optimized C++' 이라는 "자극적인" 책 제목에 이끌려서 읽게 됐는데, 결과적으로 말하자면 상당히 실망이다. 1. 내용이 깊지 않다. 책의 난이도를 의미하는 것이 아니다. 책의 난이도와 내용의 깊이는 엄밀히 말하면 별개이다. 아무튼, 책 내용의 깊이 측면에서 이 책은 매우 실망적이였다. Optimized C++ 이라는 책 이름에 걸맞는 내용들이 아니였다. 단순히, C++의 good practice들을 performance측면에서 서술한 것이 전부였다. 나는 뭔가 새롭고 고급스러운 스킬들이나 기술들을 원했는데, 내용은 단순히 겉핡기만 하고 있었다. custom memory allocator에 대한 부분으로 예를 들자면, 나는 그것을 활용한 실질적인 고급기술들이나 실제 응용들이 궁금한건데, 책은 단순히 custom memory allocator의 basic example만 가지고 그게 뭔지만 간단하게 설명하고 넘어간다. 2. 설명이 부실하다. 위에서 내용이 깊지 않다고 했는데, 사실 깊지 않은 내용이더라도 그것을 잘 전달하면 그것은 초심자 혹은 특정 level의 독자들을 위한 상당히 좋은 서적이 된다. 근데 이 책의 문제는 내용이 깊지도 않은데 설명도 부실하다. custom memory allocator로 예를 들자면, 책에서는 basic example만 가지고 간단하게 설명하고 넘어가는데, 문제는 저걸 이미 아는 사람은 읽을 필요가 없고, 저걸 모르는 사람은 책만 읽고서는 이해하기가 어렵다는 것이다. 즉, 뭔가 책의 target 독자층이 애매하다. 3. 영어가 뭔가 이상하다?? (지극히 주관적 생각임에 주의!) 이건 나의 문제일 수도 있는데.... 뭔가 영어가 너무 ...

여름동안의 Google Summer Of Code 2017를 성공적으로 끝마쳤다. Final Evaluation를 통과하고, 멘토님에게도 칭찬을 들어서 기분이 좋다. 아무튼 GSoC를 계기로 오픈소스에 직접 기여하면서 C++실력도 상당히 많이 늘게 되어서 뿌듯하다. 역시 실력을 키우는데에는 오픈소스 코드를 보는 게 가장 빠르고 효율적인 것 같다. 아래는 내가 GSoC에서 한 활동에 대한 Abstract이다. (자세한 건 https://summerofcode.withgoogle.com/projects/#5151083935563776 참고) HPX is “The C++ Standards Library for Concurrency and Parallelism”. So, implementing C++17 parallelism like N4409 is very important. Most of parallel algorithms are already implemented. But, still some algorithms have not been implemented. My main objective is implementing as many as possible of the remaining parallel algorithms and adapt them to Ranges TS and add container versions of them. And I add unit tests and benchmark codes for them. Associated with mainly parallel algorithms, I also catch and suggest many issues and resolve them.  비록, GSoC는 끝났지만 계속에서 HPX 오픈소스에서 활동을 하며 contribution을 이어나갈 생각이다. 오픈소스 활동을 통해 얻을 수 있는게 많기 때문이다. C++ 차세대 표준을 공부하고 구현하면서 C++ 실력을 상당히 많이 키울 수 ...

    이번 학기에 학교에서 '임베디드 시스템 소프트웨어'란 과목을 수강하였다. 학기의 마지막에 간단한 자유 프로젝트 과제가 주어졌다. 근데 기간이 빠듯해서 프로젝트를 진행할 수 있는 시간이 사실상 2일밖에 없었다. 그냥 평범하게 학교수업에서 배운 내용을 바탕으로 할까 하다가 이미 아는 내용을 반복하는 것은 의미가 없다는 생각이 들었다. 그래서 무작정 Android Framework 소스를 수정해서 뭔가 해보는 걸로 프로젝트의 방향을 잡았다. Android 기기의 Display 화면을 6x6으로 쪼개서 뒤섞은 모습 ㄷㄷㄷ          위는 이번 미니 프로젝트에서 구현한 2가지 기능중에 한 가지인 Display Puzzle 기능이다. Android 기기의 Display 화면을 NxM 의 형태로 쪼개서 퍼즐처럼 뒤섞어 버린다. 이 것을 구현하기 위해 Hardware Abstraction Layer에서 gralloc 관련 부분을 수정했다. 프레임버퍼로 나가기 직전에 화면을 가로채서 뒤섞어버린다. 정상적인 화면 캡처를 했을 때, 화면이 오른쪽으로 90도 돌아가고 왼쪽부분에 투명한 회색 선이 생긴 상태로 캡처가 되게 된다.         위는 2번째 기능을 보여준다. 사용자가 캡처를 하게되면, 화면이 오른쪽으로 90도 돌아가고 왼쪽부분에 투명한 회색 선이 생긴 상태로 캡처가 되게 된다. 물론 원래 화면을 그대로 두고 캡처만 저렇게 되게 된다. 출처 : http://cdn.edureka.co/blog/wp-content/uploads/2013/01/Android-Stack1.jpg         아무튼, 별 의미는 없지만 안드로이드 프레임워크를 수정해야 할 수 있는 기능 2가지를 구현해보았다. 쉽게 할 수 있을 줄 알았는데 생각보다 이상현상들이 많이 발생해서 힘들었다. 개발 ...

Chapter 8. 다듬기 항목 41. 이동이 저렴하고 항상 복사되는 복사 가능 매개변수에 대해서는 값 전달을 고려하라. 왼값 참조와 오른값 참조 버전 2개를 모두 만드는 것은 코드 중복, 유지보수 측면에서 단점이고, 보편 참조 전달 버전은 항목 26/27/30 에서 말했던 것들과 같은 문제들이 발생할 수 있다. 따라서 약간의 효율성을 포기하면 이러한 단점들을 피할 수 있는데, 그것이 바로 값 전달을 활용하는 것이다. (효율성 : 보편 참조 버전 >= 왼값 참조 버전 + 오른값 참조 버전 >= 값 전달 버전) 그러나, 값 전달의 경우에도 주의해야 할 점들이 있다. 1. 잘림 문제 (slicing problem) 2. 값 전달 함수들이 꼬리를 물고 호출되면, 전체적인 성능이 급격히 하락할 수 있다. 3. "값 전달 (복사 생성) -> 이동 배정" 의 경우 "참조 전달 -> 복사 배정" 보다 훨씬 비쌀 가능성이 있다. (예를 들면, std::string이나 std::vector등의 memory allocation 때문에) 흠, 나는 값 전달 버전이 얼마나 유용할 지 의문이 든다. 일단 이동 연산 하나가 불필요하게 낭비된다. 사실 이동이 저렴한 경우에는 유지보수, 코드중복 해결의 장점을 봤을 때 이러한 사소한 낭비를 무시할 수 있다. 그러나 사실 큰 문제는 이동이 저렴하다고 생각했는데 저렴하지 않을 수 도 있다는 것이다. std::string이나 std::vector같은 경우, memory allocation 때문에 값 전달 후 이동 배정을 하는 것이 상당히 느려질 수 있는데, 코드를 짤 때 이러한 점을 간과하거나 실수 할 가능성이 크다. 또한, 잘림 문제도 주의해야 한다. 즉, 값 전달을 사용하는 것은 참조 버전보다 실수할 가능성이 더 크기 때문에 일단 기본적으로는 피해야 한다고 생각한다. 내 생각에는 일단 우선적으로 왼값/오른값 참조 버전을 사용하다가, 성능을 더 강화할 필요가 있을 경우...