동적 소프트웨어 업데이트

컴퓨터 과학에서, 동적 소프트웨어 업데이트(DSU)는 프로그램이 실행되는 동안 프로그램 업그레이드와 관련된 연구 분야다.DSU는 현재 산업에서 널리 사용되지 않고 있다.그러나, 연구원들은 DSU를 구현하기 위한 다양한 시스템과 기술을 개발했다. 이 시스템들은 일반적으로 실제 프로그램에서 테스트된다.

현재 운영 체제와 프로그래밍 언어는 일반적으로 DSU를 염두에 두고 설계되지 않는다.이와 같이 DSU 구현은 일반적으로 기존 툴을 활용하거나 전문 컴파일러를 구현한다.이러한 컴파일러는 원래 프로그램의 의미론을 보존하지만, 동적으로 업데이트 가능한 프로그램을 만들기 위해 소스 코드나 객체 코드를 계측한다.연구자들은 안전성과 성능 오버헤드를 평가하기 위해 DSU 지원 프로그램의 변형을 원래 프로그램과 비교한다.

소개

실행 중인 프로그램은 튜플$({\displaystyle \Delta ,}$ P${\displaystyle }$) ${\displaystyle(\delta, P)}$이라고 생각할 수 있으며$,$ 여기서 $\Delta {\displaystyle }$ ${\displaystyle \delta }$은(는) 현재 프로그램 상태이고$$ $P{\displaystyle }$ ${\displaystyle P}$은 현재 프로그램 코드다.동적 소프트웨어 업데이트 시스템은 실행 중인 프로그램$({\displaystyle \Delta }$, ${\displaystyle P}$) ${\displaystyle (\delta$,${\displaystyle {}^{}}$$)}$을(를) 새로운 버전$({\displaystyle {}^{}}$ ${\displaystyle {\prime }^{}}$, P${\displaystyle {\prime }^{}}$ )$${\$displaystyle (\delta ',P')$으로 변환한다$.$ 그러기 위해서는 상태를 $P{\displaystyle {}^{}}$ ${\displaystyle {\prime }^{}}$ ${\$이 기대하는$$ 표현으로 변환해야 한다.이것은 상태 변압기 기능을 필요로 한다.Thus, DSU transforms a program ${\displaystyle (\delta ,P)}$ to ${\displaystyle (S(\delta ),P')}$. An update is considered valid if and only if the running program ${\displaystyle (S(\delta ),P')}$ can be reduced to a point tuple ${\displaystyle (\delta ,P')}$프로그램의 새 버전의 시작점에서 도달할 수 있는 것$.{\displaystyle }$ (${\displaystyle {}_{}}$ ${\displaystyle i_{}}$ ${\displaystyle n_{}}$ ${\displaystyle i_{}}$ t${\displaystyle {}_{}}$, ${\displaystyle {}^{}}$ ${\displaystyle {\prime }^{}}$) ${\displaystyle (\delta _{init}P$^[1]

프로그램 내에서 동적 업데이트가 발생하는 위치를 업데이트 지점이라고 한다.기존 DSU 구현은 업데이트 포인트 처리에 있어 매우 다양하다.UpStare 및 PoLUS와 같은 일부 시스템에서는 실행 중에 언제든지 업데이트가 발생할 수 있다.인삼의 컴파일러는 업데이트 포인트의 좋은 위치를 유추하려고 하지만 프로그래머가 지정한 업데이트 포인트를 사용할 수도 있다.Kitsune과 Ekiden은 개발자가 모든 업데이트 지점을 수동으로 지정하고 이름을 지정하도록 요구한다.

시스템 업데이트는 지원하는 프로그램 변경 유형에 따라 다르다.예를 들어 Ksplice는 함수에서 코드 변경만 지원하며, 국가 대표성의 변경은 지원하지 않는다.Ksplice는 일반 업데이트보다는 보안 변경을 주로 타깃으로 하기 때문이다.대조적으로, Ekiden은 다른 프로그래밍 언어로 쓰여진 프로그램이라도 실행될 수 있는 다른 프로그램으로 프로그램을 업데이트할 수 있다.시스템 설계자는 업데이트 범위를 제한하여 값진 성능 또는 안전 보장을 추출할 수 있다.예를 들어 모든 업데이트 안전 검사는 해당 안전 검사를 통과한 업데이트로 업데이트 범위를 제한한다.코드와 상태를 변환하는 데 사용되는 메커니즘은 시스템이 지원할 업데이트의 종류에 영향을 미친다.

DSU 시스템은 도구로서 개발자의 사용 편의성과 명확성에 대해서도 평가할 수 있다.인삼과 같은 많은 DSU 시스템은 다양한 정적 분석을 통과하기 위한 프로그램을 필요로 한다.이러한 분석은 DSU에 가치가 있는 프로그램의 속성을 증명하지만, 그것들은 본질적으로 정교하고 이해하기 어렵다.정적 분석을 사용하지 않는 DSU 시스템은 전문 컴파일러를 사용해야 할 수 있다.일부 DSU 시스템은 정적 분석이나 특수 컴파일러를 요구하지 않는다.

DSU 시스템에 의해 업데이트된 프로그램을 대상 프로그램이라고 한다.DSU 시스템의 학술 간행물에는 사례 연구로서 몇 가지 목표 프로그램이 포함되어 있다.vsftpd, OpenSSH, PostgreSQL, Tor, Apache, GNU Zebra, memcached, Redis 모두 다양한 시스템의 동적 업데이트 대상이다.동적 업데이트 지원을 염두에 두고 작성된 프로그램이 거의 없기 때문에 기존 프로그램을 리폼하는 것은 DSU 시스템을 실제 사용으로 평가하는 데 귀중한 수단이다.

관련분야

동적 업데이트로 해결되는 문제 공간은 다른 여러 문제들의 교차점이라고 생각할 수 있다.예를 들어 체크포인트, 동적 링크, 지속성이 포함된다.예를 들어, 이전 버전의 온디스크 파일 형식과 역호환되어야 하는 데이터베이스는 동적 업데이트 시스템에서 예상되는 것과 동일한 유형의 상태 변환을 수행해야 한다.마찬가지로 플러그인 아키텍처가 있는 프로그램도 런타임에 새로운 코드를 로드하고 실행할 수 있어야 한다.

유사한 기법도 로드나 런타임에 조건부로 죽거나 연결할 수 없는 코드를 제거하고 남은 코드를 재결합하여 메모리 공간을 최소화하거나 속도를 향상시키기 위해 동적 데드코드 제거를 목적으로 채택되는 경우가 있다.^[2][3]

역사

동적 소프트웨어 업데이트의 가장 초기 선행조건은 중복 시스템이다.예비 시스템은 중복 환경에서 주 시스템의 고장 발생 시 능동 계산을 제어할 준비가 되어 있다.이 시스템들은 메인 기계와 핫 스페어를 포함하고 있다.핫 스페어는 주기적으로 1차 시스템의 체크포인트로 시드된다.고장이 나면 핫 스페어가 자리를 잡게 되고, 메인 기계가 새로운 핫 스페어가 된다.이러한 패턴은 업데이트로 일반화될 수 있다.업데이트 시 핫 스페어가 활성화되고, 메인 시스템이 업데이트되며, 업데이트된 시스템이 제어를 재개한다.

최초의 진정한 동적 소프트웨어 업데이트 시스템은 DYMOS(Dynamic Modification System)이다.^[4]1983년 인섭 리 박사학위 논문에서 제시된 DYMOS는 인터랙티브 사용자 인터페이스, 모둘라 변종용 컴파일러 및 런타임, 소스 코드에 접근할 수 있는 완전 통합형 시스템이었다.이를 통해 DYMOS는 기존 프로그램에 대한 업데이트를 타이핑 체크할 수 있었다.

실행

DSU 시스템은 실행 중인 프로그램에 새로운 코드를 로드해야 하며, 새로운 코드로 이해되는 형식으로 기존 상태를 변환해야 한다.DSU의 많은 동기부여적 사용 사례는 시간적으로 중요하므로(예: 라이브 및 취약한 시스템에 보안 픽스를 배치하는 경우), DSU 시스템은 적절한 업데이트 가용성을 제공해야 한다.일부 DSU 시스템도 업데이트를 적용하기 전에 업데이트가 안전한지 확인하려고 시도한다.

이 문제들 중 어느 하나에도 표준적인 해결책은 없다.일반적으로 한 문제 영역에서 우수한 성능을 발휘하는 DSU 시스템은 다른 문제 영역과의 트레이드오프에서 그렇게 한다.예를 들어 동적 업데이트의 경험적 테스트는 업데이트 지점의 수를 증가시키면 안전하지 않은 업데이트의 수가 증가한다는 것을 나타낸다.^[5]

코드 변환

대부분의 DSU 시스템은 업데이트를 위한 코드 단위로 서브루틴을 사용하지만, 새로운 DSU 시스템은 전체 프로그램 업데이트를 구현한다.^[6][7]

대상 프로그램이 가상 시스템 언어로 구현되면 최신 가상 머신은 DSU(주로 디버깅) 이외의 다른 사용 사례에 대한 런타임 로드를 지원하므로 VM은 기존 인프라를 사용하여 새 코드를 로드할 수 있다.HotSpot JVM은 런타임 코드 로딩을 지원하며, 자바(프로그래밍 언어)를 대상으로 하는 DSU 시스템이 이 기능을 활용할 수 있다.

C 또는 C++와 같은 원어민 언어에서 DSU 시스템은 프로그램에 양방향으로 삽입하는 특수 컴파일러를 사용할 수 있다.업데이트 시 이 리디렉션은 최신 버전을 가리키도록 업데이트된다.DSU 시스템이 컴파일러를 사용하여 이러한 들여쓰기를 정적으로 삽입하지 않는 경우, 이진 재작성으로 런타임에 삽입한다.바이너리 재작성은 실행 중인 네이티브 프로그램의 메모리 영상에 로우레벨 코드를 작성해 기능을 재다이렉트하는 과정이다.이것은 프로그램의 정적 분석을 필요로 하지 않지만, 플랫폼 의존도가 높다.

Ekiden과 Kitsune은 포크-실행 또는 동적 로딩을 통해 완전히 새로운 프로그램을 시작함으로써 새로운 프로그램 코드를 로드한다.그런 다음 기존 프로그램 상태가 새로운 프로그램 공간으로 이전된다.^[6][7]

상태 변환

업데이트하는 동안 프로그램 상태를 원래 표현에서 새 버전의 표현으로 변환해야 한다.이것을 상태 변환이라고 한다.상태 객체 또는 상태 객체의 그룹을 변환하는 기능을 변압기 함수 또는 상태 변압기라고 한다.

DSU 시스템은 변압기 기능을 합성하려고 시도하거나 개발자가 변압기를 수동으로 공급하도록 요구할 수 있다.일부 시스템은 이러한 접근방식을 혼합하여 변압기의 일부 요소를 유추하는 동시에 다른 시스템에 대한 개발자 입력을 요구한다.

이러한 변압기 기능은 각 구버전 상태에 액세스하기 때문에 느리게 프로그램 상태에 적용하거나 업데이트 시 모든 상태를 변환하는 데 사용할 수 있다.게으른 변환은 업데이트가 일정한 시간에 완료되도록 보장하지만, 개체 액세스에 대한 정상 상태 오버헤드를 유발하기도 한다.빠른 변환은 업데이트 시 더 많은 비용을 유발하며, 모든 변압기가 작동하는 동안 시스템이 세상을 멈추게 해야 한다.그러나, 열성적인 변환은 컴파일러가 상태 접근을 완전히 최적화할 수 있도록 해주며, 게으른 변환과 관련된 안정적 상태 오버헤드를 피할 수 있다.

안전 업데이트

대부분의 DSU 시스템은 업데이트에 대한 일부 안전 속성을 표시하려고 시도한다.안전 점검의 가장 일반적인 변형은 형식 안전이며, 이 경우 업데이트가 이전 상태 표시에서 작동되는 새로운 코드를 초래하지 않을 경우 안전하다고 간주되거나, 그 반대의 경우도 마찬가지다.

형식 안전성은 일반적으로 활동성 안전 또는 동의성 안전의 두 가지 특성 중 하나를 표시하여 점검한다.업데이트 시 호출 스택에 업데이트된 기능이 없을 경우 프로그램은 활동성-안전한 것으로 간주된다.이는 통제가 새로운 데이터 표현에 접근할 수 있는 이전 코드로 되돌아갈 수 없기 때문에 안전성이 입증된다.

반대-자유도는 형식 안전성을 증명하는 또 다른 방법이다. 코드 섹션이 형식 표현에 대한 지식이 필요한 방식으로 지정된 형식의 상태에 접근하지 않으면 안전하다고 간주된다.이 코드는 국가에 추상적으로 접근할 수 있는 반면 국가에 구체적으로 접근하지 않는다고 말할 수 있다.코드의 어떤 부분에서든 모든 타입에 대한 동의나 반증이 가능하며, DSU 시스템 인삼은 이것을 타입의 안전성을 증명하기 위해 사용한다.^[8][9]기능이 무상으로 입증된 경우 기존 표현을 사용하여 상태에 액세스하여 형식 오류를 발생시키지 않으므로 스택에서 라이브 상태라도 업데이트할 수 있다.

Hayden et의 동의성과 능동성 안전성에 대한 경험적 분석은 두 기법 모두 가장 정확한 업데이트를 허용하고 가장 잘못된 업데이트를 거부한다는 것을 보여준다.그러나 수동으로 업데이트 지점을 선택하면 업데이트 오류가 발생하지 않으며, 여전히 빈번한 업데이트 가용성이 허용된다.^[5]

기존 시스템

다이모스

다이모스는 가장 초기 제안된 DSU 시스템이라는 점에서 눈에 띈다.DYMOS는 Modula의 파생상품으로 작성된 프로그램을 위한 완전한 통합 환경으로 구성되며, 시스템은 REF와 유사한 명령 통역기, 소스 코드, 컴파일러 및 런타임 환경에 접근할 수 있다.DYMOS에서 업데이트는 사용자가 대화형 환경에서 명령을 실행함으로써 시작된다.이 명령에는 업데이트가 발생할 수 있는 시기를 지정하는 지침(when-conditions)이 포함된다.DYMOS가 이용할 수 있는 정보는 실행 중인 대상 프로그램과 관련하여 업데이트의 형식 안전을 강제할 수 있도록 한다.^[4]

Ksplice, Kpatch 및 Kcriptor

ksplice는 리눅스 커널만을 대상으로 하는 DSU 시스템으로 운영체제 커널을 타깃 프로그램으로 지원하는 전문 DSU 시스템 중 하나이다.Ksplice는 Linux 커널의 현재 버전과 업데이트된 버전 사이의 변경을 결정하기 위해 소스 레벨 디프프를 사용하고, 실행 중인 커널에 변경 사항을 삽입하기 위해 바이너리 재작성을 사용한다.^[10]ksplice는 2011년 7월 오라클코퍼레이션이 인수한 원작자 ksplice Inc.가 설립한 상업용 벤처에 의해 유지되었다.^[11]Ksplice는 상업적 기반에 사용되며 Oracle Linux 배포에 독점적으로 사용된다.^[12]

SUSE는 라이브 커널 패치를 위한 오픈소스 대안으로 KCriptor를 개발했고, Red Hat도 kpatch를 개발했다.둘 다 ftrace에 의해 설정된 라이브 패치 적용 메커니즘에 의존하면서 실행 중인 리눅스 커널에 기능 수준의 변경을 적용할 수 있도록 한다.반면 뜨거운 패치 적용된다. kGraft과 kpatch은 리눅스 커널 푹 빠지다 4월 2014년과 5월 2014년에 포함, respectively,[13][14]과 라이브 패치의minimalistic 재단 그에 합병되었다에 제출된 업데이트된 코드 섹션의 런타임 일관성을 보장하는 kGraft과 kpatch 사이에 주된 차이점은 방법이다.e리눅스2015년 4월 12일에 출시된 커널 버전 4.0의 커널 메인라인.^[15]

2015년 4월부터 리눅스 커널 메인라인이 제공하는 공통 라이브 패치 코어에 kpatch와 kCriptor를 포팅하는 작업이 진행 중이다.그러나 Linux 커널이 제공하는 콜 스택이 적절한 스택 프레임 없이 어셈블리 코드를 포함하는 상황에서 Linux 커널이 제공하는 콜 스택이 신뢰할 수 없을 수 있기 때문에 기능의 원래 버전과 패치가 적용된 버전 사이의 안전한 전환에 필요한 기능 수준 일관성 메커니즘의 구현이 지연되었다. 그 결과, 포팅 작업 리마(Porting Work Rema)2015년^[update] 9월 현재 진행 중이다.커널의 콜 스택의 안정성을 향상시키기 위한 시도로, 전문화된 건전성 검사stacktool userspace 유틸리티는 또한 커널의 컴파일 시간 객체 파일을 확인하고 콜 스택이 항상 유지되도록 하기 위한 목적으로 개발되었다. 또한 커널 ops 메시지의 일부로서 보다 신뢰할 수 있는 콜 스택을 달성할 수 있는 가능성을 열어준다.^[16][17]

인삼

인삼은 범용 DSU 시스템이다.DSU 시스템으로는 유일하게 동의-자유도 안전기법을 적용, 업데이트 유형에 대한 구체적인 접근만 하지 않으면 스택에 라이브로 존재하는 기능을 업데이트할 수 있다.

인삼은 OCaml에서 C중간언어 프레임워크를 사용하여 작성한 소스 대 소스 컴파일러로 구현된다.이 컴파일러는 모든 기능 호출과 유형 액세스에 양방향으로 삽입하여 인삼이 프로그램 실행 전체에 대해 일정 시간 오버헤드를 부과하는 비용으로 느리게 상태를 변환할 수 있도록 한다.^[9]인삼의 컴파일러는 초기 프로그램 전체와 동적 패치의 완전성을 증명한다.

인삼의 후기 버전도 거래 안전의 개념을 뒷받침한다.이를 통해 개발자는 일련의 함수 호출에 논리 단위로 주석을 달 수 있으며, 활성도 안전성 또는 동의도 안전성 중 하나로 탐지할 수 없는 방식으로 업데이트 내용이 프로그램 의미론을 위반하는 것을 방지할 수 있다.예를 들어 인삼의 저자가 조사한 OpenSSH의 두 버전에서는 중요한 사용자 검증 코드를 순차적으로 호출한 두 기능 사이에서 이동시켰다.첫 번째 기능의 첫 번째 버전이 실행되고, 업데이트가 발생하며, 두 번째 기능의 새 버전이 실행된다면, 검증은 절대 수행되지 않을 것이다.이 섹션을 거래로 표시하면 업데이트로 인해 확인 작업이 수행되는 것을 방해하지 않는다.^[18]

업스타어

UpStare는 고유한 업데이트 메커니즘인 스택 재구성을 사용하는 DSU 시스템이다.UpStare로 프로그램을 업데이트하기 위해 개발자는 가능한 스택 프레임 간의 매핑을 지정한다.UpStare는 이 매핑을 사용하여 임의의 지점, 임의의 수의 스레드 및 스택에 있는 모든 기능을 사용하여 프로그램을 즉시 업데이트할 수 있다.^[19]

PoLUS

PoLUS는 C를 위한 이진법 DSU 시스템이다.수정되지 않은 프로그램은 실행의 어느 지점에서나 업데이트할 수 있다.기능을 업데이트하기 위해 새로운 기능으로 리디렉션하기 위해 대상 함수의 서막을 다시 작성하며, 여러 버전에 걸쳐 이러한 재조정을 체인으로 한다.이는 업데이트되지 않은 기능에서 정상 상태 오버헤드를 방지한다.^[20]

카타나

카타나는 사용자-모드 ELF 바이너리에 대해 제한된 동적 업데이트(Ksplice 및 그 포크와 유사)를 제공하는 연구 시스템이다.카타나 패치 모델은 ELF 오브젝트 레벨에서 동작하므로, 컴파일 대상이 ELF인 한 언어에 구애받지 않을 수 있는 용량을 가지고 있다.

키츠네와 에키덴

Ekiden과 Kitsune은 C로 작성된 프로그램에 대해 DSU의 상태 전이 스타일을 구현하는 단일 DSU 시스템의 두 가지 변형이다.Ekiden과 Kitsune은 단일 프로그램 내에서 기능을 업데이트하는 대신 전체 프로그램에 걸쳐 업데이트를 수행하여 두 실행 간에 필요한 상태를 전송한다.에키덴이 포크-실행이라는 UNIX 관용어를 사용하여 새로운 프로그램을 시작하고, 대상 프로그램의 상태를 직렬화하여 전송함으로써 이를 달성하는 반면, 키츠네는 동적 링크를 사용하여 "인플레이스" 상태 전송을 실시한다.키츠네(Kitsune)는 에키덴의 코드베이스에서 파생된 것으로, 에키덴의 후기 버전이라고 볼 수 있다.

Ekiden과 Kitsune은 전문적인 런타임이나 컴파일러가 아닌 주로 애플리케이션 레벨 라이브러리로 구현된다는 점에서도 주목할 만하다.이와 같이, Ekiden이나 Kitsune을 이용하기 위해서, 어플리케이션 개발자는 수동으로 전송될 상태를 표시하고, 프로그램 내에서 업데이트가 발생할 수 있는 지점을 수동으로 선택해야 한다.이러한 과정을 완화하기 위해 키츠네에는 주 변압기 작성을 위한 도메인별 언어를 구현하는 전문 컴파일러가 포함되어 있다.^[6][7]

얼랑

Erlang은 일반적으로 "핫 코드 로드"라고 부르지만 동적 소프트웨어 업데이트를 지원한다.얼랑에는 업데이트에 대한 안전 보장이 필요 없지만 얼랑 문화는 개발자들이 업데이트에 의해 발생하는 유형 오류를 우아하게 처리하는 방어적인 스타일로 글을 쓸 것을 제안한다.^{[citation needed]}

피물트

Pymoult는 Python으로 작성된 동적 업데이트를 위한 시제품 제작 플랫폼이다.그것은 다른 시스템으로부터 많은 기법을 수집하여 이들의 조합과 구성을 허용한다.이 플랫폼의 목적은 개발자들이 자신의 필요에 더 적합하다고 생각하는 업데이트 기법을 선택하도록 하는 것이다.예를 들어 인삼처럼 게으른 상태 업데이트를 병행하면서 키츠네나 에키덴처럼 어플리케이션의 전체 코드를 변경할 수 있다.^[21][22]

Microsoft Visual C++

마이크로소프트는 패치의 기능적 정확성을 유지하면서 개별 C++ 기능 패치를 지원하는 마이크로소프트 비주얼 C++ 내부 패칭 기술을 활용하고 있다.현재 알려진 응용프로그램은 Azure SQL 데이터베이스에 있는 SQL Server이다.^[23]

참고 항목

• 핫 스와핑 § 소프트웨어
• 지속성(컴퓨터 과학)
• 런타임 확인

참조

외부 링크

• Ksplice 홈페이지
• Ksplice 소스 코드
• 인삼 프로젝트 페이지 및 소스 코드/업스테이어 페이퍼/PoLUS 페이퍼
• 얼랑 홈페이지
• 카타나 홈페이지
• Visual C++ 패치 적용에 대한 백서 블로그 게시물