警戒 檢査

위키百科, 우리 모두의 百科事典.

警戒 檢査 (bounds checking)는 變數 가 使用되기 前에 어떤 境界 內 에 位置하는지를 檢査하는 技法으로, 主로 數字 데이터가 特定 範圍 內에 存在하는지 與否나 (範圍 檢事), 配列 인덱스 가 配列의 境界 안에 있는지 與否를 檢査하는데 使用된다 (인덱스 檢事). 警戒 檢査에서 失敗한 境遇 (假令, 接近할 配列 인덱스가 配列 境界 바깥에 있는 境遇)는 普通 프로그램 例外 로 處理된다.

警戒 檢査는 主로 컴퓨터 保安 과 關聯하여 메모리 脆弱點 發生을 根本的으로 防止하는 目的으로 使用되지만, 性能 側面에서 相當한 오버헤드 를 發生시켜 通常 모든 境遇에 恒常 隨行되지는 않는다. 이와 關聯한 컴파일러 最適化 技法 가운데 하나는 不必要한 警戒 檢査 코드를 除去하는 것을 目標로 하기도 한다. ( Bound-checking elimination )

範圍 檢事 [ 編輯 ]

範圍 檢事는 어떤 數字가 特定 範圍(Range) 內에 存在하는지 與否를 檢査하는 것이다. 範圍 檢事의 代表的인 例는 다음과 같다.

  • (어떤 數字를 16비트 정수형 變數에 代入하는 狀況에서) 數字가 "16비트 整數形으로 表現될 수 있는 範圍" 內에 있는지에 對한 檢査
  • (月을 表現하는 變數의 境遇) 값이 1부터 12 사이에 있는지에 對한 檢査

範圍 檢査는 데이터 타입 檢事 와는 다른 種類의 檢査이다.

인덱스 檢事 [ 編輯 ]

인덱스 檢査는 接近할 配列의 인덱스가 (配列 정의 時點에 決定된) 配列의 境界 안에 存在하는지 與否를 檢査하는 것으로, 通常的인 警戒 檢査 라고 함은 이러한 인덱스 檢査를 이르는 말이다. 인덱스 檢事 失敗는 通常的으로 에러로 인한 프로그램 終了로 이어진다. 많은 高級 프로그래밍 言語 들이 인덱스 檢査 機能을 內藏하고 있는데, 이는 配列 境界 바깥에 데이터 읽기/쓰기가 許容되면 프로그램 吳動作, 衝突, 甚至於 ( 버퍼 오버플로 와 같은) 保安 脆弱點 等이 發生할 수 있기 때문이다.

파스칼 , 포트란 , 자바 와 같은 高級 프로그래밍 言語들은 인덱스 檢査를 內藏하고 있다. VAX 컴퓨터는 INDEX 라는 配列 인덱스 檢査를 위한 어셈블리 命令語 가 存在하는데, 이 命令語는 總 6個의 被演算子 를 받아들이며, 各各의 被演算子는 VAX에서 支援하는 모든 魚드레싱 모드 를 使用할 수 있다. B6500 및 이와 類似한 Burroughs 社의 컴퓨터는 作成된 프로그래밍 言語 와 無關하게 하드웨어 次元에서 警戒 檢査를 遂行하였다. 以後 世代의 CPU 모델 中에선 少數만이 警戒 檢査를 위한 特殊 命令語 를 導入하였는데, CHK2 命令語가 있는 모토로라 68000 系列 CPU가 그 中 하나이다.

한便 (C를 包含한) 많은 프로그래밍 言語는 빠른 實行 速度를 위해 警戒 檢査를 自動으로 遂行하지 않으며, 이 點으로 인해 大多數의 Off-by-one 에러 버퍼 오버플로 脆弱點 等이 發見되지 않은 채 放置되기도 한다. 大多數의 프로그래머들은 이러한 言語들이 速度를 위해 지나치게 많은 것을 犧牲하고 있다고 생각한다고 한다. [1] 英國의 컴퓨터 科學者 C. A. R. Hoare 는 1980年 튜링上 講演에서 過去 ALGOL 60 프로그래밍 言語를 디자인하던 時節의 經驗에 對해 다음과 같이 述懷하였다. ( ALGOL 60 은 自動 警戒 檢査 機能을 內藏한 言語이다.)

이러한 原則의 結果는 바로, 모든 添字를 갖는 變數의 모든 添字 (예: 配列의 인덱스)는 實行 時間 恒常, 미리 宣言된 配列의 上/下限 사이에 있는지 체크된다는 것이었다. 몇年 後에 우리는 顧客들에게 商用 서비스 中인 프로그램의 效率的인 動作을 위해 이런 警戒 檢査 機能을 켜고 끌 수 있는 옵션을 包含시키면 어떤지에 對해 意見을 물었는데, 顧客들 모두 滿場一致로 그런 機能이 있으면 안된다 고 主張했다. 그들 모두 商用 서비스 中에 添字 誤謬 (境界 바깥을 接近하는 誤謬)가 얼마나 자주 發生하는지, 또 그것들이 發見되지 않을 때 얼마나 破壞的일 수 있는지 알고 있었던 것이다. 甚至於 1980年씩이나 되어서 衝擊과 恐怖로 내가 깨달은 點이 있다면, 많은 프로그래밍 言語 디자이너와 使用者들이 아직도 이 點에서 크게 敎訓을 얻지 못했다는 것이다. 어떤 멀쩡한 工學 部分이든 間에, 이런 基本的인 注意 事項을 看過하는 것 自體가 오래 前부터 不法 水準 으로 看做될 수도 있는 일이었다.

酒類 프로그래밍 言語 가운데 實行 時間 (런타임) 警戒 檢査 機能을 支援하는 言語로는 Ada , C# , 하스켈 , 자바 , 자바스크립트 , 리스프 , PHP , 파이썬 , Ruby 비주얼 베이직 等이 있다. D 言語와 OCaml 은 컴파일러 옵션을 통해 實行 時間 警戒 檢査 機能을 켜고 끌 수 있다. C# 亦是 一定 部分의 코드에 對해서는 一時的으로 警戒 檢査를 遂行하지 않도록 하는 機能을 支援한다 (unsafe 區域). 이런 機能들은 全體 프로그램의 安全性을 毁損시키지 않으면서도 一部 實行 時間 甁목 을 解消시킬 수 있어 性能 改善에 有用하게 使用될 수 있다.

하드웨어 警戒 檢査 [ 編輯 ]

소프트웨어 敵人 警戒 檢査는 프로그램의 安全性을 높여주는 代身 追加 CPU 時間 을 消耗시키지만, 하드웨어 敵人 警戒 檢査는 理論的으로는 實行 時間 損失 없이 "空짜로" 安全性의 利點만을 取할 수 있다. 1974年 草創期 컴퓨터 시스템 中 하나인 ICL 2900 시리즈 시스템이 하드웨어 警戒 檢査를 借用한 以來로, [2] 일러도 2005年에 들어 x86 시스템의 內臟 메모리 管理 유닛 (MMU)을 配列 및 버퍼 接近 詩에 安全性을 確保하는 데 使用할 方法에 對한 硏究가 始作되었다. [3] 2015年에는 Intel 社에서 配列 境界를 CPU 레지스터 메모리 床에 테이블로 貯藏해두는 新型 Skylake 프로세서 아키텍처 擴張을 發表하고 ( Intel MPX ), 2017年 GCC 컴파일러 에서 Intel MPX 擴張을 支援하기 始作했다. 하지만 以後 多數의 硏究에 依해 旣存 소프트웨어的 技術들과 比較해 性能上/機能上 이點을 갖추지 못한 것으로 評價받으며 [4] [5] [6] 實世界 適用이 鈍化되거나 萎縮되는 趨勢이다. [7]

같이 보기 [ 編輯 ]

參照 [ 編輯 ]

  1. Cowan, C; Wagle, F; Calton Pu; Beattie, S; Walpole, J (1999). 〈Buffer overflows: Attacks and defenses for the vulnerability of the decade〉. 《Proceedings DARPA Information Survivability Conference and Exposition. DISCEX'00》 2 . 119?129쪽. doi : 10.1109/DISCEX.2000.821514 . ISBN   978-0-7695-0490-2 .  
  2. J. K. Buckle (1978). 《The ICL 2900 Series》 (PDF) . Macmillan Computer Science Series. 17,77쪽. ISBN   978-0-333-21917-1 . 2018年 4月 20日에 原本 文書 (PDF) 에서 保存된 文書 . 2018年 4月 20日에 確認함 .  
  3. J. K. Buckle (1978). 《The ICL 2900 Series》 (PDF) . Macmillan Computer Science Series. 17,77쪽. ISBN   978-0-333-21917-1 . 2018年 4月 20日에 原本 文書 (PDF) 에서 保存된 文書 . 2018年 4月 20日에 確認함 .  
  4. Oleksenko, Oleksii; Kuvaiskii, Dmitrii; Bhatotia, Pramod; Felber, Pascal; Fetzer, Christof (2017). “Intel MPX Explained: An Empirical Study of Intel MPX and Software-based Bounds Checking Approaches”. arXiv : 1702.00719 [ cs.CR ].  
  5. “Konstantin Serebryany - Research at Google” . 《research.google.com》.  
  6. “Discussion of Intel Memory Protection Extensions (MPX) and comparison with AddressSanitizer” . Google . 2013年 11月 4日에 確認함 .  
  7. “GCC 9 Looks Set To Remove Intel MPX Support” (英語). Phoronix . 2018年 4月 27日에 確認함 .  

外部 링크 [ 編輯 ]