20150618 – Research

1. MARSS 개발
– 시뮬레이션이 모두 끝난 다음 캐시 접근 횟수를 출력하는 루틴을 작성해야 함.
– machine.cpp에서 시뮬레이션이 끝났음을 확인한다.
– 그 외에 basecore.h, basecore.cpp, atomcore.h, atomcore.cpp, ooo.h, ooo.cpp를 수정함.
– 끝나는 시점에 dump_shared_cache_access_count()가 두 번 호출되는 것은 static 변수를 사용해 방지함.
– 다음 코드는 어플리케이션별 캐시 접근 기록을 추출하는 코드

#!/usr/bin/python
import sys
import os
 
dst_dir    = "/home/gumdaeng/Experiment_Results/debug"
cache_access_file_postfix = "cache_access_footprint.log"
input_data = [
                ["1cpu.1ms.nam.0.sje.0", "116533000", "1175f2000"],
                ["1cpu.1ms.nam.0.h26.0", "116132000", "11853b000"],
                ["1cpu.1ms.sje.0.ast.0", "1163bc000", "1186f2000"],
                ["1cpu.1ms.sje.0.sop.0", "11965d000", "1185d2000"],
                ["1cpu.1ms.sje.0.bzi.0", "118336000", "118521000"],
                ["1cpu.1ms.nam.0.mil.0", "116597000", "116944000"],
                ["1cpu.1ms.sje.0.lib.0", "11965c000", "115f75000"],
                ["1cpu.1ms.h26.0.mcf.0", "1162c2000", "1165da000"],
                ["1cpu.1ms.omn.0.gcc.0", "1196cd000", "1196d4000"],
                ["1cpu.1ms.ast.0.xal.0", "11751a000", "11974c000"],
                ["1cpu.1ms.bzi.0.sop.0", "11758b000", "36f4c000"],
                ["1cpu.1ms.gcc.0.lib.0", "1169d1000", "11658d000"],
                ["1cpu.1ms.bzi.0.lib.0", "1166b4000", "36f67000"],
                ["1cpu.1ms.omn.0.lib.0", "115e56000", "116b70000"],
                ["1cpu.1ms.ast.0.lib.0", "1182fb000", "115f50000"],
                ["1cpu.1ms.xal.0.lib.0", "117438000", "116491000"],
                ["1cpu.1ms.mil.0.lib.0", "116368000", "36f81000"]
            ]  
 
 
def extract_cache_access_footprint(exp_name, app_name, app_cr3, cache_access_footprint_filename, cache_level):
    f_footprint = open(cache_access_footprint_filename, "r")
    f_result = open(app_name + ".from." + exp_name + ".csv", 'w')
    cr3=""
    for line in f_footprint:
        stripped_line = line.strip()
        splitted_line = stripped_line.split(",")
        real_cache_level = splitted_line[0][0:2]
        cr3              = splitted_line[1]
        if app_cr3 == cr3 and real_cache_level == cache_level:
            f_result.write(line)
        else:
            pass
    f_footprint.close()
    f_result.close()
 
if __name__ == "__main__":
    if len(sys.argv) == 2:
        cache_level = sys.argv[1]
    else:
        print "%s <cache level>" % (sys.argv[0])
        sys.exit()
 
    for record in input_data:
        exp_name = record[0]
        app1_name = exp_name.split(".")[2]
        app2_name = exp_name.split(".")[4]
        app1_cr3  = record[1]
        app2_cr3  = record[2]
        cache_access_footprint_filename = exp_name + "." + cache_access_file_postfix
 
        print exp_name
        extract_cache_access_footprint(exp_name, app1_name, app1_cr3, cache_access_footprint_filename, cache_level)
        extract_cache_access_footprint(exp_name, app2_name, app2_cr3, cache_access_footprint_filename, cache_level)

– 아래 코드는 캐시 접근 횟수에 따른 캐시 블록의 수를 히스토그램으로 표현한 것

#!/usr/bin/python
import matplotlib
import pylab as P
import numpy as np
import os
 
def draw_histogram(exp_name, app_name, facecolor):
    app_cache_access_footprint_filename = "%s.from.%s.csv" % (app_name, exp_name)
    app_cache_access_footprint_file     = open(app_cache_access_footprint_filename)
 
    x = []
    cache_access_num = 0
    for line in app_cache_access_footprint_file:
        cache_access_num += 1
        stripped_line    = line.strip()
        splitted_line    = stripped_line.split(",")
 
        access_count = int(splitted_line[4])
        x.append(access_count)
 
    app_cache_access_footprint_file.close()
 
    title = "%s, %d accesses" % (app_cache_access_footprint_filename, cache_access_num)
    P.title(title)   
    n, bins, patches = P.hist(x, 105, histtype='stepfilled')
 
    P.setp(patches, 'facecolor', facecolor)
    P.figure()
    P.show()
 
cache_access_file_postfix = "cache_access_footprint.log"
input_data = [
                ["1cpu.1ms.nam.0.sje.0", "116533000", "1175f2000"],
                ["1cpu.1ms.nam.0.h26.0", "116132000", "11853b000"],
                ["1cpu.1ms.sje.0.ast.0", "1163bc000", "1186f2000"],
                ["1cpu.1ms.sje.0.sop.0", "11965d000", "1185d2000"],
                ["1cpu.1ms.sje.0.bzi.0", "118336000", "118521000"],
                ["1cpu.1ms.nam.0.mil.0", "116597000", "116944000"],
                ["1cpu.1ms.sje.0.lib.0", "11965c000", "115f75000"],
                ["1cpu.1ms.h26.0.mcf.0", "1162c2000", "1165da000"],
                ["1cpu.1ms.omn.0.gcc.0", "1196cd000", "1196d4000"],
                ["1cpu.1ms.ast.0.xal.0", "11751a000", "11974c000"],
                ["1cpu.1ms.bzi.0.sop.0", "11758b000", "36f4c000"],
                ["1cpu.1ms.gcc.0.lib.0", "1169d1000", "11658d000"],
                ["1cpu.1ms.bzi.0.lib.0", "1166b4000", "36f67000"],
                ["1cpu.1ms.omn.0.lib.0", "115e56000", "116b70000"],
                ["1cpu.1ms.ast.0.lib.0", "1182fb000", "115f50000"],
                ["1cpu.1ms.xal.0.lib.0", "117438000", "116491000"],
                ["1cpu.1ms.mil.0.lib.0", "116368000", "36f81000"]
            ]
 
for record in input_data:
    exp_name = record[0]
    app01_name = exp_name.split(".")[2]
    app02_name = exp_name.split(".")[4]
    app01_cr3  = record[1]
    app02_cr3  = record[2]
    cache_access_footprint_filename = exp_name + "." + cache_access_file_postfix
     
    draw_histogram(exp_name, app01_name, "b")
    draw_histogram(exp_name, app02_name, "r")   

2. Security 관련 논문 조사
국내에서는 백윤흥 교수님께서 rootkit을 비롯해 하드웨어적인 보안 관련 문제를 다루고 있음. [CCS’12] Vigilare toward snoop-based kernel integrity monitor를 간단하게 읽고, [’14] 시스템 보안을 위한 하드웨어 기반 모니터 기술을 읽으면 이해가 쉬움.

[’14] 시스템 보안을 위한 하드웨어 기반 모니터 기술
– 백윤흥 교수님께서 KCC에 기고한 글이다. 두 번째 섹션부터 읽으면 빠르게 이해할 수 있다. 최근 하드웨어 보안 기술 동향과 관련 연구에 대해 소개하고 있음. 하드웨어에 기반한 커널 무결성 검증과 사용한 코드 재사용 공격 방어에 대해 소개하고 있다.
– 최근에 커널 무결성을 보장하기 위한 하드웨어 지원 방법에 대한 연구가 많이 진행됨. [’04] Copilot-a Coprocessor-based Kernel Runtime Integrity Monitor에서 PCI를 사용한 snapshot-based kernel integrity check을 시도함. 하지만 PCI로 장착된 특성 상 그 기능에 제약이 있고, 한계점이 있다.
– 이를 해결하고자 연구팀에서 Vigilare, KI-Mon을 제안함. 이들을 사용하면 snapshot-based kernel integrity check techniques에서는 잡아내지 못했던 transient attack을 해결할 수 있음.
– 추가로 code reuse attack(CRA)을 방어하는데 하드웨어 기술을 사용할 수 있다. CRA는 원하는 코드 조각을 모아 공격 코드를 작성하는 기법이다. 이러한 공격 기법의 특징을 파악해, 하드웨어적으로 확인하고 방어할 수 있다. (SCRAP 논문 참고)

[CCS’12] Vigilare toward snoop-based kernel integrity monitor
– 이 논문에서는 snoop-based monitoring system인 Vigilare를 제안한다. 시스템에서 kernel을 신뢰할 수 있는 것이 중요한데, 시스템이 공격받아 장악당하면 kernel을 신뢰할 수 없는 현상이 발생한다. kernel을 신뢰할 수 있는지를 확인하기 위해 여러가지 monitoring 기법이 제안되었다. 크게 두 가지 분류로 나눌 수 있는데, 하드웨어 기반의 접근 방식과 하이퍼바이저 기반의 접근 방식이다. 최근 들어 하이퍼바이저 기반의 접근 방식이 주목받았으나, 하이퍼바이저 기반의 커널 무결성 검증은 어려운 점이 많다. 하이퍼바이저는 복잡해지고 있으며, 그 자체로 소프트웨어이므로 취약점이 발생할 수 있다. 실제로 몇몇 연구에서는 커널 무결성 검증에 하이퍼바이저를 사용하지 않는 것이 좋다고 이야기한다.
– 지금까지 제안된 하드웨어 기반 무결성 검증 방식은 대개 snapshot을 기반으로 하고 있다. HyperSentry, Copilot, HyperCheck 등이 snapshot을 기반으로 하는 무결성 검증 방식이다. Copilot에서는 PCI를 사용한 DMA를 사용해 snapshot을 생성했으며, HyperCheck과 HyperSentry에서는 SMM을 사용해 snapshot을 생성했다.
– snapshot 기반 커널 무결성 검증 기법은 그 특성 상 매우 취약하다. 스냅샷을 일정한 간격으로 찍어야 하기 때문이다. 따라서 그 사이에 확인할 수 없는 구간이 발생하게 된다. 스냅샷이 다시 찍히기 전에 복구해놓는 방식으로 무결성 검증을 회피할 수 있다. 스냅샷을 자주 찍으면 오버헤드가 발생하고, 스냅샷을 랜덤하게 찍으면 검증하지 못하는 구간이 발생한다. 이런 문제점을 해결하기 위해, 이 논문에서는 전혀 다른 접근 방법인 snoop-based integrity check 기법 Vigilare를 제안한다.
Vigilare는 프로세서가 만들어내는 결과물이 결국 입출력 장치를 통한다는 점에 주목한다. 입출력 장치를 보고 있다가, 비정상적인 행위가 발생하면 이를 저지한다. 이를 통해 Vigilare는 사실상 모든 시스템 행위를 관찰하고 제어할 수 있게 된다. Vigilare는 Snooper와 Verifier로 구성되는데, Snooper는 시스템의 시스템 버스에 연결되어 정보를 수집한다. Snooper가 보낸 정보를 Verifier가 검증한다.
– 시스템 버스의 데이터 처리 대역폭이 상당히 넓으므로, snooper는 이 중에서 일부 데이터만 추출해 verifier에게 넘겨준다. Verifier는 이 데이터를 확인해, 변경되면 안 되는 데이터(interrupt descriptor table 등)에 변경이 가해졌는지 확인한다. 이를 통해 시스템의 무결성이 침해되었는지 아닌지를 알 수 있다. 이를 SnoopMon이라하고, 추가로 기존의 snapshot 방식의 SnapMon도 제안한다.

[USENIX’13] KI-Mon A Hardware-assisted Event-triggered Monitoring Platform for Mutable Kernel Object
– 앞서의 Vigilare에서는 변경되면 안 되는 커널 공간에 대해 이야기했다면, 변경 가능한 커널 데이터에 대해 무결성을 검증하는 기법에 대해 이야기한다.

[’04] Copilot – a Coprocessor-based Kernel Runtime Integrity Monitor
– 커널 무결성 검증 기법에 대한 초기 연구에 해당함. (제대로 읽어보지는 않음)

[ASPLOS’15] Nested Kernel An Operating System Architecture for Intra-Kernel Privilege Separation
– 일종의 가상화를 통한 커널 무결성 검증 기법이다. nested kernel을 사용해 실제 어플리케이션은 nested kernel을 접하므로, real kernel은 공격받지 않는다. (제대로 읽어보지는 않음)

[DATE’15] Extrax security extension to extract cache resident information for snoop-based external monitors
– 모니터링 기법을 더 빠르게 하기 위한 연구이다.

Advertisements
Tagged with: , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in 1) Memo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

누적 방문자 수
  • 93,418 hits
%d bloggers like this: