Software blog

4월 10일 부터 이 고민을 했으니 한참 걸렸다. 처음에는 선점형쪽 모델로 부터 증명을 시작 했는데, 증명을 하다보니 여러가지 가정들로 채워 놓은 것은 그렇다고 치더라도 어거지 부리는 느낌이 너무 강했다. 중간에 비선점형 관련 스케줄 테스트들을 찾아 냈는데, 대략적으로 이해하는데만 한 주 정도가 지나 간것 같다.

이제까지와 다른 형태로 내용을 전개하다보니, 중간중간 가끔 느끼는 미래에 대한 불안감 같은 느낌을 논문을 쓰면서 느꼈고, 초록을 작성이 끝나기전 4~5일간은 또 다시 내가 말도 안되는 논리로 억지를 부리고 있는 것이 아닌지 고민 했다. 오늘을 포함해서 이틀 동안 8번 교정을 하면서, 스토리 텔링이 좀 더 명확해지고, 각 수식들이 간결 해졌다.

이런식의 작업에 좀 걱정을 했었는데, 역시 사람은 걱정하는 것을 없애는 방법은 생각이 아니라 행동으로 그것을 푸는 수 밖에 없다는 것을 이번에 세삼느꼈다. 오후 들어서는 작년에 논문들 마무리 할때 나는 머리가 띵해지는 그런 느낌도 다시 한번 느꼈는데, 아직까지는 좀 부족 한 것 같다. 내일 다시 몇 번 교정한 다음에 교수님께 보내야겠다.

칙센트 미하이에 소개된 바에 따르면 외과의사들은 수술 중과 후에 큰 성취감을 얻을 수 있다고 한다. 수술의 목적이 확실하고 각 과정에서 즉각적인 피드백이 존재 하기 때문에 시술중에 몰입감이 최대가 될 수 있다 했다.

나는 누가 뭐라고 해도 코딩 할때 즐겁다. 코딩 자체에 대한 행위는 나에게 있어서 그림을 그리거나 글을 쓴다는 맥락에서 같은 데, 생각을 써내려가며 자신의 생각과 구조를 그림이나 문자로 표현하는 즐거움 정도라고 해야 할까. 아무래도 회사에 있는 것이 아니다보니, 코드 자체에 손대는 시간은 현저하게 줄었다. 논문을 작성하는 것도 보통 아이디어를 정리하고 이를 기술 하는데 80% 이상을 소비한다.

언제 부터 가끔 너무 머리가 복잡하면, 오래된 코드들을 정리하는 습관이 생겨버렸다. 말 그대로 프로그래밍이 아닌 코딩은 생각을 필요로 하지 않는 단순 작업에 가깝기 때문에 몰입에 들어가기 쉽다. 개발자로서 외과의사들 처럼 계속 수술대에 서 있고 싶지만, 그전에 그 재미있는 작업을 맛 보기 위해서는 내가 배워야 하는 다른 기초들에 시간을 많이 투자해야 하는 것을 알고 있다. 예를 들면 아이디어를 위해 새로운 논문들을 살펴보거나, 페이스북, 트위터 같은 킬러 어플리케이션들도 살펴본다. 때로는 아이디어가 논문거리가 되는지 또는 수술대 올릴만한 것인지 스스로 잣대에 올려 봐야 할 일도 있고, 코딩으로 써 내려갈 프로그램의 전체 구조와 기능을 생각 해본다던가 이러한 작품들이 기존의 것과 어떤 것이 다른 지도 생각해야 한다.

몇 몇의 사람들은 학문에 대한 연구를 수술대에 올라가기 위한 전초 작업보다 일종의 새로운 아이디어의 기여라고만 생각 하기도 하지만, 개인 적으로는 나에게 있어 이러한 학문적 연구나 탐색등은 수술대 위해서 FLOW를 최대한 즐길 수 있는 전초 작업에 불과 하다. 다만 이러한 전초 작업 또한 수술과는 또 다른 형태의 사고방식과 몰입 과정을 요하기 때문에 아직까지 이에 익숙하지 않음을 느낀다.

앞으로 제대로 된 수술대에 올라갈려면 내가 기존에 무시하면서 봐왔던 것들, 그리고 단기적 목표를 달성하기 위해 소월히 하고 있던 것들, 가끔 보면 스트레스 받는 것들, 아니면 아예 귀찮아서 버려 놓았던 것들에 대해서 정성을 들여야 함을 세삼 느끼고 있다. 이제 남은 시간은 69일 정도.. 그 사이에 뭔가를 해 놓을 필요는 없지만.. 내 생활 습관이나 근성들이 좀 바뀌었으면 좋겠다.

대구, 서울, 수원을 돌아서 다시 부산으로 오는 일주일 일정을 마쳤다.

지도교수님과 대학원 진학 문제와 이후 저널 논문에 대한 이야기를 좀 나누고, 미국 생활에 큰 도움이 될 조언들을 듣고 올 수 있었다. 자신을 내려 놓는일. 연구자로서의 인성과 인품을 갖추기 이전에 가장 먼저 선행 되어야 하는 일. 자신을 바닥까지 내려 놓는 지도교수님의 이야기는 그 문장 하나하나가 기억에 날 만큼 인상적이었다. 설득을 위한 이야기가 아니라 자신의 이야기를 바탕으로 걱정 해주시는 마음을 느낄 수 있는 기회였다.

목요일에는 영종이형을 만났는데, 지도교수님이랑 상반되는 이야기였지만, 앞으로 미국에 나가서 많은 내가 계속적인 추진력을 가질 수 있도록 해주는 가장 훌륭한 조언이 아니었나 싶다. 인위적인 여유이던, 내가 인지 못하는 내 스스로의 여유이던 간에 내가 예상하지 못했던 변수들에 흔들리지 않도록 경제적 문제를 처리 해야 하며, 단기적인 목적을 위해서는 그 선택 뒤에 오는 기회비용의 평가는 목적의 달성 시점까지 미뤄두고 현재 내가 쳠여하고 있는 게임 의 판을 나에게 가장 유리하도록 짜는 것이 중요하다는 것을 다시 상기 시켜줬다.

이외에도 이번 주에 참 많은 분들을 만나 뵈었다. 각기 전부 다른 사고와 견해를 가지고 계셨지만, 결국 하나에 이르는 결론을 가지고 계셨으며, 서로간의 입장 차이에 따라 같은 결론을 다른 방법으로 설명 해주신 차이 밖에 없다. 이런 도움을 받을 수 있는 것은 내게 있어 큰 축복이며, 그들의 도움을 통해 나는 또 다른 이에게 도움을 줄 수 있을 것이라 생각한다.




KTX 안에서는 칙센트 미하이의 Optimal Experience:Flow, 를 원서로 다시 읽었다. 혼돈으로 부터 우리를 어느정도 지켜주는 (Shield) 여러가지 기존의 방법을 떠나서 다시 한번 깊은 생각과, 생각의 즐거움을 생각 해볼 수 있었던 계기가 되었다. 거진 3개월간, 기다리고, 고민하고, 생각했고 이제 미국에 대한 여러가지 생각들도 결정이 되었으니 남은 3개월 간은 내 안에 부족한것 들을 수정하고, 내가 가진 것들 만이라도 나에게 판이 유리하도록 다시 재구성해야 할 것이다.

이번 주는 복잡한 내 머릿속을 정리하고, 필요하지만 까먹었던 과거에 내가 가졌던 여러가지 생각들을 다시 상기시켜주는 올해 가장 값진 한 주가 아니었나 싶다.

과거에는 모니터와 키보드만 보면 두근 거리는 순간이 있었다. 마치 하얀 캔버스를 보며 자신에 의해서 세상에 처음 모습을 나타낼 한폭의 그림을 상상하는 것 처럼 키보드를 보면 흥분되는 그런 순간이 있었다. 시간이라는 것은 참 많은 것을 우리에게서 빼앗아 간다. 상상해보라. 초등학교 시절, 그 단순한 소풍이라는 단어 하나만으로도 우리는 소풍 전날 쉽사리 잠이 들지 못했다.

작년 한해 나는 3개의 해외 논문을 내고, 11개의 기술 컬럼을 작성했으며, GT와 KU를 졸업하기 위해 열심히 프로젝트에 참여하고 GRE와 같은 영어 시험들을 쳤다. 하지만 그 순간에 내가 했던 것들의 결과가 궁금해서 설레였던 적은 SESC를 통한 캐시 프로젝트 단 한번 이었다. 대부분의 시간은 위경련을 일으킬 만큼 힘겨웠으며 프로그램을 만들면서도 내가 만든 모듈의 결과가 예상과 달라 원인을 생각하기 바빴다. 일본에서는 내 목표가 손에서 벗어나버릴까바 고작 하나 먹은 초코바를 처음 보는 거리에 모두 토해냈으며, 책상에는 항상 아스피린 껍질과 활명수, 박카스 병이 굴러 다녔다. 더욱 중요한 것은 랩실을 들어서면서, 그리고 내 작업실 문을 열면서 오늘 새로 만들어질 그림을 기대하며 흥분을 감추지 못한 적은 한번도 없다. 그곳에는 어떠한 설레임도 없었다. 단순한 나에 대한 신념만이 존재 했다. 지금도 누가 강요한 적은 없지만 박사 과정에 들어가기전에 두개의 논문을 더 작성하고 있지만 그 과정이 그렇게 즐겁지 않다.

회상속에서 내가 단 한번도 내가 평생해야 할 일에 대한 흥분을 느끼지 못한 이유를 분석해본다면 첫 번째 이유는 문제를 해결 하기 위한 내 기반 지식의 부족과 능력의 결여에 있을 것이다. 칙센트 미하이의 플로우(Flow, Optimal Exprience)의 진입 조건을 따져 본다면 목적을 달성하기 위한 기술의 부족에 있을 것이다. 두번 째 이유는 작년 한해를 거치고, 올해 여러 어드미션을 받으면서 내 원래의 목적 -- 내가 잘 할 수 있고 좋아할 수 있는 분야의 교수에게로 간다 --를 벗어나 지명도와 수치적 가치를 먼저 보게 되는 소위 속물이 되어가고 있는 것이다. 오늘도 나는 펀딩은 없지만 이후 나의 위치를 어느정도 대변해줄 위스콘신, UCLA, 브라운 중 하나를 선택할 것인가 아니면 원래의 목적과 일치하고 적절한 펀딩을 지원해주는 펜스테이트를 갈것인가를 고민 하고 있다.

삼성 부사장이 자살을 하고 초 전도계의 이성익 교수의 자살 소식을 들으면서 그들의 자살에 원인은 실적도 삶에 대한 고뇌도 아닐 것이라 생각 했다. 좋아하는 것과 잘하는 것의 차이. 잘하는 것을 자신의 인생의 궁극적인 목적으로 생각한다면 삶이라는 긴 여정에서 우리 자신을 잃어버리지 않을 방법이 있는가? 분명 자신보다 잘하는 사람은 그 긴여정속에 반드시 나타나게 되어 있다. 그러면 우리는 그때 새로운 의미를 찾을 수 있을 만큼 젊은가? 정작 키보드를 보면 이제 설레이는 마음보다는 어떻게 문제를 분석할 것인가에만 초점이 맞춰져 있고 학교의 이름을 살펴보고 지명도를 확인하고 순위를 확인 하는 지금의 내가 그들과 다른 결과를 만들 수 있는 일말에 여지가 있는가? 문제를 풀기 위한 기반 지식에 대한 한계를 겪을때 마다 생기는 그 고통을 넘지 못하고 있다면 잘하는 것에 앞서 내가 좋아하는 일은 할 수 있는 것인가? 내가 잘하는 것도 아니고 좋아하는 것도 아니라면 내가 여기서 얻을 수 있는 것은 무엇인가?


늙은 연인을 안고 어색한 탱고를 추고 싶은 마음은 추어도 없다. 고매한 학자인척 하는 연기하는 것은 나로서는 완전이 불가능한 일이다. 결국 만들어내고 생각하는 것을 즐기지 않는다면 작년 올해 내가 한것과 앞으로 할 것들은 내 인생의 중요한 시간을 창문 밖으로 버리고 있는 것과 같은 부질 없는 짓일 것이다. 언제 쯤이면 나에게 있는 깨진 창문들을 모두 고치고, 예전처럼 키보드와 모니터 앞에서 미칠도록 즐거웠던 그 설레임을 다시 가질 것인가?

Efficient Software-Based Fault Isolation

Myoungsoo Jung

Problems, Solutions and Summaries:

The key idea to isolate fault by software is very simple, and allows us to archive the efficient way to make fault isolation cheap enough. Begin with this paper, Robert Wahbe at al. figure out the problem of the traditional fault isolation method. When we use such scheme (i.e., hardware-based fault isolation), high performance cost is necessary because preventing the code in one address space from corrupting the contents of another induces prohibitive context switch overhead and needs some additional operation such as trapping, copying arguments, saving and loading relative register, and flush look-aside buffer. To overcome this challenge, the authors provide a software approach, which implemented within a single address space. It grants a separated fault domain to load code and data for a distrusted module and modify object code to prevent faults from writing and jumping to address outside such fault domain.

To archive mentioned goal of this paper, the authors propose the software encapsulation transforming distrusted module not to escape its fault domain – fault domain consists of two segments, one for distrusted module's code, and another for its static data, heap and stack. The software encapsulation contains of two kinds of key mechanism to pinpoint the actual location of fault within a module and isolate distrust module. One is called, segment matching preventing the use of illegal addresses. In segment matching, insert checking code before every unsafe instruction that jumps to or store to statically unverified address within the correct segment. If the check fails, such code traps to a system error routine outside the distributed modules' fault domain.

Another key mechanism of software encapsulation is address sandboxing. Sanding boxing indicate inserted code that sets the upper bits of the target address to the correct segment identifier before distrusted instructions. As with segment matching, earlier mentioned, unsafe store or jump instruction can be modified to use dedicate register, and it guarantee that distrusted module code cannot produce an illegal address. There are two instruction for providing sandboxing, one to clear segment-id and store the result in a dedicate register, the other to set segment id for the correct value.

Remaining issues for supporting efficient software encapsulation are optimization, how to prevent corrupting process resources and to access among domains when they need data sharing. In the view of optimization, the authors provide the way to reduce overhead, which is induced from computing target address. Basically, instruction of RISC has register address and offset. However, sandboxing mechanism just use only register addresses or numbers and handles offset by creating guard zone, which indicate unmapped area. In process resources problem, the authors require distrusted modules for accessing resource through cross-fault-domain RPC. For instance, if a distrusted module's object code performs a direct system call, the authors transform this call into the appropriate RPC call. In last, I talk about data sharing. Because segment encapsulation doesn't alter load instruction, fault domains can read any memory mapped in the application's address space. However, each domain cannot share data among them. So the authors provide lazy pointer swizzling that alias the shared regions into multiple locations in the virtual address space by modifying the hardware page table.

Critiques:

Although this paper strives for reducing the cost of fault isolation by using not hardware but software, I afraid some kinds of possibility that its mechanism can break pipeline. Traditionally, many scientists who involved in computer architecture realm take effort to reduce the number of broken pipeline because it induces the terrible performance degradation. As software encapsulation, we should insert code for support segment matching and sandboxing, which incur to break pipeline. So the authors should provide clearer evidence that proposed approach cannot hurt breaking pipeline. Secondly, I don't find realistic solution for adding "correct" value which used for implementing segment matching. If the actual location where occupied with loadable distrusted modules is fixed then we can easily find segment-id during a compile time, but if not, segment-id is unable to be recognized when compile time. For this reason, the authors also should refine the correct value and provide the way to find segment-id without any operating system's load modules mechanism during a compile time.

Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines

Myoungsoo Jung

 

Problems, Solutions and Summaries:

This paper proposes the way to reuse unmodified device driver. At the same time, Joshua Le Vasseur et al. point out how to improve system dependability by using virtual machine. Actually full reuse for a driver base has been considered unachievable. It's because if we want to introduce device driver into new Operating System, then elusive problems occur such as unavailable code, undocumented feature, and extent of programming errors. The authors suggest pragmatic approach for it and strong isolation of legacy device drivers by guaranteeing that semantics a preserved and incompatibilities are limited using virtual machine multiplexing. Also this scheme allows system suffer from minimal resource overhead by collaborating VMs.

Traditionally, for experience driver reuse, the author divides approaches into two parts. First one is a co-hosting method that indicates binary driver reuse. Another one is transplanting driver that enables to enjoy independence. However the previous approach can interfere between VM and driver OS because they run with all privileges. Also, the last method has problem to successfully reuse device driver because they has to use glue code, and it raise conflicts. When system tries to reuse device driver, the authors propose three considerations such as semantic resource conflicts that represent accidental denial of service, sharing conflicts that are induced since fair address space sharing may be unachievable. Finally, in the view of an engineering effort, donor OS knowledge significantly required writing glue and it is even difficult.

In this paper, drivers are closely knit to kernel, applications are not. In addition to that, orthogonal drivers should be based on following principles: 1. Resource delegation by receiving only bulk resources. 2. Separation of name spaces that indicate each driver has its own address space. 3. Separation of privilege by executing driver in unprivileged mode. In last the author claims secure isolation and common API as basic principle to satisfy orthogonal device driver requirements. In architectural view, to reuse and isolate each device driver, system executes it and its native OS within VM called by DD/OS. This approach is same effect that each deriver can be executed in separate VMs and it allows systems exploit simultaneous use of driver from incompatible OS-s. To communicate each deriver located in separated VMs, translation module support abstractions and control them by adding to DD/OS to interface with client.

The authors also claim that low overhead communication by using message notification and request completion. In addition to it, to bolster their reuse approach, they insist low overhead memory sharing registering memory areas of a VM into another VM's physical memory space. Besides those claims, the authors consider virtualization issues such as DMA operation, additional requirements regarding resources, and special timing. In DMA operation case, there are problem that DD/OS can perform DMA to physical memory not allowed by memory protection system. For this reason, it uses DMA to replace hypervisor code and data. I will discuss regarding these considerations in next critique section to argue for details. This research contributes unmodified reuse, a strong isolation, and fault containment to existing device driver.

 

Critiques:

In DMA and trust section of this paper, I wonder if where actual memory locations that cannot be reclaimed are when this approach uses DMA operation. I think that the author have to solve this ambiguity. In addition to it, the author claims that client must not use pinned memory because of DD/OS until faulted it complete rebooting process. However, I am not confident this mechanism is right. For example if DMA completes before the faulted VM restart then system fall down to ambiguous status, and I wonder if VM fail to reboot their system then what can be incur. If systems need a bunch of drivers to provide one functionality like PCI device then I have question to decide whether the proposed approach still use distributed device drivers to deal with one functionality or not. With this reason, to bolster their claims, the author should provide tradeoff between performance and isolation advantage. More crucial problem is resource consumption. The authors solve this problem by using swapping memory method. To evict it, It considers which one is cold page or not. However, most device drivers are managed as block box. So, the author should suggest the way to recognize cold and hot page even if each device driver is encapsulated, and hide their own information.