4.1 프로세스 소개

 

1) 프로세스란?

 

→ 리눅스 시스템 메모리에서 실행 중인 프로그램 (태스크와 유사한 의미)

※ 멀티프로세싱 : 다수의 프로세스를 실시간으로 사용

※ 멀티태스킹 : 같은 시간에 여러 프로그램 실행

 

- 프로세스를 관리하는 자료구조이자 객체를 태스크 디스크립터라고 부르고, task_struct 구조체로 표현됨

→ task_struct 구조체에는 메모리 리소스, 프로세스 이름, 실행 시각, 프로세스 아이디, 프로세스 스택의 최상단 주소와 같은 속성 정보가 저장됨

 

프로세스의 실행 흐름을 표현하는 중요한 공간은 스택 공간이며, 이 프로세스 스택의 최상단 주소에 thread_info 구조체가 있다.

 

- 리눅스 커널에서 프로세스를 표현할 수 있는 자료구조

① task_struct 구조체 : 태스크 디스크립터

② thread_info 구조체 : 프로세스 스레드 정보

→ 프로세스를 잘 알려면 프로세스 속성 정보와 실행 흐름을 저장하는 구조체를 잘 알아야 함

 

2) 태스크란?

 

→ 실행(Execution)의 의미, 실행 및 작업 단위

 

- 리눅스 커널에서 태스크는 프로세스와 같은 개념으로 쓰는 용어이다.

- 소스코드나 프로세스에 대한 설명을 읽을 때 태스크라는 단어를 보면 프로세스와 같은 개념으로 이해하자.

 

3) 스레드란?

 

→ 유저 레벨에서 생성된 가벼운 프로세스

 

- 일반 프로세스에 비해 컨텍스트 스위칭을 수행할 때 시간이 적게 걸림

   (자신이 속한 프로세스 내의 다른 스레드와 파일 디스크립터, 파일 및 시그널 정보에 대한 주소 공간을 공유하기 때문)

- 스레드 그룹 안의 다른 스레드와 주소 공간 공유

- 커널 입장에서는 스레드를 다른 프로세스와 동등하게 관리

 

4.2 프로세스 확인하기

 

1) ps 명령어로 프로세스 목록 확인

 

★ ps : 실행 중인 프로세스를 출력하는 명령어

→ 리눅스 커널 내부의 init_task 전역변수를 통해 전체 프로세스 목록 출력

 

라즈베리파이에 "ps -ely" 명령어 입력

 

라즈베리파이에 "ps -ejH" 명령어 입력

 

- "-ejH" 옵션 : 부모 자식 프로세스 관계를 토대로 출력

- 위 목록에서 보이는 프로세스를 커널 스레드, 커널 프로세스라고 하며, 커널 공간에서만 실행된다.

 

※ PID(Process Identifier) : 프로세스에 부여하는 고유의 정수형 ID

→ 리눅스 커널에서 pid_t라는 타입으로 <sys.types.h> 헤더 파일에 저장되어 있음

→ 리눅스 커널에서는 프로세스가 생성될 때 PID를 프로세스에게 알려줌

 

커널은 PID를 증가시키면서 프로세스에게 부여함

 

 

'2021 SUMMER STUDY > LINUX KERNEL' 카테고리의 다른 글

Week05_프로세스3  (0) 2021.08.21
Week04_프로세스2  (0) 2021.08.15
Week02_커널 디버깅과 코드 학습  (0) 2021.07.25
Week01_리눅스 소개와 전망  (0) 2021.07.18

<Daedalus: Breaking Non-Maximum Suppression in Object Detection via Adversarial Examples>

라는 논문에서 NMS의 오작동을 유발하는 적대적 예시 공격을 제안한다.

이 논문을 정확히 이해하기 위해서 NMS에 대한 내용을 자세히 알아보고자 한다.

★ NMS란?

 

→ object detector가 예측한 bounding box 중에서 정확한 bounding box를 선택하도록 하는 기법

 

비-최대 억제를 뜻하는 NMS(Non-Maximum Suppression)을 알기 전에 IoU에 대한 내용을 살펴봐야 한다.

 

▶ IoU란 무엇일까?

 

IoU(Intersection over Union)은 object detector의 정확도를 측정하는데 이용되는 평가 지표이다.

→ object detector가 예측한 bounding box는 IoU를 이용해서 평가될 수 있다.

 

IoU를 적용하기 위해서는 두 가지가 필요하다.

① ground-truth bounding boxes : testing set에서 object 위치를 labeling한 것

② prediceted bounding boxes : model이 출력한 object 위치 예측값

 

이미지에서 정지 신호를 감지하는 예시

 

위 그림에서 predicted bounding box는 빨간색, ground-truth bounding box는 녹색으로 그려진다.

 

object detector가 얼마나 정확하게 객체 위치를 탐지했는지 알아보기 위한 IoU 계산법은 다음과 같다.

 

Area of Overlap : prediceted bounding box와 ground-truth bounding box가 겹치는 부분

Area of Union : prediceted bounding box와 ground-truth bounding box를 둘러싸는 영역

 

→ 겹치는 영역을 합집합 영역으로 나누면 합집합에 대한 교차 점수를 알아낼 수 있다.

→ Intersection over Union 점수 > 0.5는 일반적으로 좋은 예측으로 간주된다.

 

▶ 그렇다면 왜 IoU를 사용할까?

 

predicted bounding box가 ground-truth bounding box와 얼마나 일치하는지 측정하기 위해 평가 지표를 정의해야 함

 

다양한 bounding box에 대한 IoU를 계산한 예

 

위처럼 정확한 일치는 아니더라도 predicted bounding box가 얼마나 가깝게 일치하는지 확인할 수 있음

 

 

▶ NMS란 무엇일까?

 

이미지에서 객체는 다양한 크기와 형태로 존재하고,

이를 완벽하게 검출하기 위해 object detection 알고리즘은 여러 개의 bounding boxes를 생성한다.

 

이때 하나의 정확한 bounding box만을 선택하도록 하는 기법이 Non-Maximum Suppression이다.

 

 

위와 같이 여러 개의 boxes 중 NMS를 이용하여 하나의 box를 생성해준다.

 

▶ Non-Maximum Suppression 알고리즘

 

<input>

- bounding box list

- bounding box confidence scores

- threshold

 

<output>

- filtered bounding box list

 

 

NMS 알고리즘

 

① 하나의 클래스에 대한 bounding boxes 목록에서 가장 높은 점수를 갖고 있는 bounding box를 선택하고 목록에서 제거한 후 final box에 추가한다.

② 선택된 bounding box를 bounding boxes 목록에 있는 모든 bounding box와 IoU를 계산하여 비교한 후 IoU가 threshold(임계값)보다 높으면 bounding boxes 목록에서 제거한다.

③ bounding boxes에 아무것도 남아 있지 않을 때까지 반복

④ 각각의 클래스에 대해 위 과정 반복

 

 

 

※ 참고자료

https://www.pyimagesearch.com/2016/11/07/intersection-over-union-iou-for-object-detection/

 

Intersection over Union (IoU) for object detection - PyImageSearch

Discover how to apply the Intersection over Union metric (Python code included) to evaluate custom object detectors.

www.pyimagesearch.com

docs.google.com/presentation/d/1aeRvtKG21KHdD5lg6Hgyhx5rPq_ZOsGjG5rJ1HP7BbA/pub?

 

YOLO

YOLO You Only Look Once: Unified, Real-Time Object Detection Joseph Redmon, Santosh Divvala, Ross Girshick, Ali Farhadi

docs.google.com

https://inspace4u.github.io/dllab/lecture/2017/09/27/NMS_Algorithm.html

 

비최대값 억제 (NMS) 알고리즘

본 포스트에서는 영상 처리 및 객체 검출에서 흔히 사용되는 비최대값 억제(Non maximum supression) 알고리즘에 대해서 설명하겠습니다. 캐니 엣지 비최대값 억제 알고리즘은 국지적인 최대값을 찾아

inspace4u.github.io

https://www.youtube.com/watch?v=XXYG5ZWtjj0 

 

3.1 디버깅이란?

 

버그를 수정하고 있다는 의미

리눅스 커널과 드라이버가 정상 동작할 때 자료구조와 함수 호출 흐름까지 파악하는 과정

 

1) 문제 해결 능력의 지름길

 

커널 디버깅은 문제 해결 능력 그 자체이다.

임베디드 리눅스 활용 분야

- 부팅 도중 커널 크래시 발생

- 인터럽트 핸들러를 설정했는데 호출되지 않음

- 시스템 응답 속도가 매우 느려짐

- 파일 복사가 안 됨

 

문제를 해결하기 위해서는 문제 발생의 원인을 분석해야 하고,

문제 발생의 원인은 문제 발생 시 확보한 커널 로그와 메모리 덤프를 정확히 분석해야 한다.

 

임베디드 BSP 개발에서 커널 로그와 메모리 덤프를 정확히 분석하는 스킬을 커널 디버깅이라고 한다.

 

※ 리눅스 커널을 구성하는 서브시스템이 정상적으로 동작할 때 파악할 내용

- 함수가 실행될 때 변경되는 자료구조

- 함수가 실행되는 빈도와 실행 시각

- 실행 중인 코드를 어떤 프로세스가 실행하는지 확인

프로그램이 정상적으로 동작할 때의 함수 호출 흐름과 자료구조를 알고 있어야 오류나 버그 발생 시 무엇이 문제인지 식별 가능하기 때문

 

★ 커널 로그 분석

 

https://www.unix.com/programming/148285-what-unbalanced-irq.html

 

① 오류 메시지를 커널의 어느 코드에서 출력했는지 확인

 

 

__enable_irq( ) 함수에서 오류 조건을 검출한 것으로 보이고, 어느 코드에서 콜 스택을 출력했는지 살펴봐야 함

 

https://github.com/raspberrypi/linux/blob/rpi-4.19.y/kernel/irq/manage.c

 

irq_desc 구조체의 depth 필드는 인터럽트를 활성화하면 0, 비활성화하면 1을 설정

6번째 줄 코드는 인터럽트를 2번 활성화했을 때 실행되며 이미 인터럽트를 활성화했으면 depth 필드가 0인데 다시 활성화했기 때문에 콜 스택을 출력한다.

※ warn( ) 매크로 함수가 호출되면 커널 로그로 콜 스택을 출력한다.

 

② 소스코드에서 에러 메시지를 출력한 이유 살펴보기

 

 

IRQ 4 : 4번 인터럽트를 두 번 활성화했기 때문에 오류 발생

위 에러 메시지는 enable_irq( ) 함수에서 출력하는데 함수 내부에 있는 논리적 오류 때문이 아닌 

enable_irq( ) 함수를 호출한 드라이버 코드에 있는 오류 때문일 가능성이 높다.

 

 

커널 에러 메시지를 보면  svsknfdrvr 드라이버 모듈이 보이고,

만약 enable_irq( ) 함수를 호출한 코드가 svsknfdrvr 드라이버 코드에 있다면 관련 코드를 분석한 후 논리적인 오류가 있는지 점검해야 함

 

③ 필요에 따라 디버깅 코드를 작성해 다시 문제가 발생했을 때 추가 커널 로그 확보 시도

 

패치 코드를 입력해 문제 현상을 재현하여 커널 로그를 받아보면 누가 4번 인터럽트를 2번 활성화했는지 알려줄 것이다.

 

패치 코드 ( 디버깅 패치 )

 

 __disable_irq ( ) 함수와 __ enable_irq( ) 함수의 2번째 인자는 인터럽트 번호를 나타내는 irq이다.

위 코드에서는 이 인터럽트 번호가 4일 때 콜 스택을 호출한다.

위 패치 코드를 빌드해서 시스템에 반영한 후 문제를 다시 재현하면 4번 인터럽트를 활성화 혹은 비활 
성화할 때 콜스택을 커널 로그로 출력하여 어떤 코드에서 연속으로 활성화했는지 알아낼 수 있다.

 

 

2) 디버깅과 코드 학습 능력

 

디버깅을 하면서 리눅스 커널 코드를 함께 분석하면 다음과 같은 정보를 얻을 수 있다.

- 분석 대상 코드가 동작하는 콜 스택 
- 함수가 실행될 때 변경되는 자료구조 
- 함수가 실행되는 빈도와 실행 시각 
- 분석 대상 코드를 실행하는 프로세스

 

★ 커널 디버깅 과정 예시

 

※ 명령어 "cat /proc/interrupts" : 인터럽트의 세부 속성

 

https://github.com/raspberrypi/linux/blob/rpi-4.19.y/kernel/irq/proc.c

 

"/* 이 부분에 번째 패치 코드를 입력하세요 */"라는 주석으로 표시된 부분에 다음 코드를 입력

 

 

irqaction 구조체 타입인 action 포인터형 변수가 NULL 이 아닐 때 action 인자와 함께 rpi_get_interrupt_info( ) 함수를 호출하는 코드

 

 

rpi_get_interrupt_info( ) 함수는 ftrace 로 다음 정보를 출력 하는 기능

- 프로세스 이름

- 인터럽트 번호

- 인터럽트 이름

- 인터럽트 핸들러 함수 이름

 

위와 같은 패치 코드를 입력한 이유는??

 

 

위와 같이 인터럽트의 속성 정보는 action 필드에 저장된다.

 

 

irqaction 구조체 오른쪽 부분에 표시된 주석이 인터럽트의 속성 정보이고,

이 정보를 라즈비안에서 확인하기 이해 패치 코드를 입력한 것이다.

 

ftrace를 설정하는 명령어로 작성한 셸 스크립트 코드

 

echo rpi_get_interrupt_info > /sys/kernel/debug/tracing/set_ftrace_filter 

패치 코드에서 작성한 rpi_get_interrupt_info( )라는 함수명을 /sys/kernel/debug/tracing/set_ftrace_filter 파일에 지정하는 명령어

→  rpi_get_interrupt_info( ) 함수를 누가 호출했는지 알 수 있음

 

./irq_trace_ftrace.sh : 셸 스크립트 실행

 

 

cat /proc/interrupts : rpi_get_interrupt_info( ) 함수가 호출되도록 커널을 동작시키는 역할

 

 

ftrace 로그를 라즈비안 시스템에서 안전하게 추출하기 위한 셸 스크립트 코드

 

get_ftrace.sh

 

./get_ftrace.sh : ftrace 로그가 현재 디렉터리에 복사되어 ftrace 로그를 확인할 수 있음

 

 

함수의 흐름은 11번째 줄에서 3번째 줄 방향으로 이어짐

01 : pid가 884인 cat 프로세스가 rpi_get_interrupt_info( ) 함수 호출

05 : seq_read( ) 함수에서 show_interrupts( ) 함수 호출

10 : sys_read( ) 함수가 호출된 후 유저 공간에서 read 시스템 콜 실행

 

egrep -nr irq_handler * : 현재 디렉토리에 있는 파일에서 irq_handler라는 문자열을 검색한 다음과 같은 결과 출력

- 인터럽트 번호

- 인터럽트 이름

- 인터럽트 핸들러 이름

 

ex)

 

- 인터럽트 번호 : 86

- 인터럽트 이름 : mmc1

- 인터럽트 핸들러 이름 : bcm2835 mmc_irq

 

 

3.2 printk( ) 함수

 

→ printk( ) 함수를 호출하면 커널 로그를 볼 수 있다.

 

https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/kernel/process.c

 

위와 같이 레지스터 정보를 출력해준다.

 

▶ printk로 함수 심벌 정보를 보는 방법

 

- printk로 포인터를 출력하고 싶을 때는 %p를 쓰면 된다.

- %pS를 쓰면 함수 주소를 심벌로 출력한다. → 함수 포인터를 디버깅할 때 자주 쓰는 기법

 

- 리눅스 커널 코드에 printk 코드 입력해보기

 

https://github.com/raspberrypi/linux/blob/rpi-4.19.y/kernel/workqueue.c

 

08 : 프로세스 이름 출력

09~10

- __ func __ : 현재 실행 중인 함수의 이름 
- __ LINE__: 현재 실행 중인 코드 라인 
- _builtin_return_address(0): 현재 실행 중인 함수를 호출한 함수의 주소 

 

 

빌드 후 설치하면 위와 같은 커널 로그를 볼 수 있고, 로그에 담긴 디버깅 정보는 다음과 같다.

- printk 로그를 실행한 포로세스의 이름은 kworker/2 : 3이다. 
- printk가 추가된 곳은 insert_wq_barrier( ) 함수의 2354번째 줄이다. 
- insert_wq_barrier( ) 함수는 workqueue_cpu_down_callback( ) 함수가 호출했다. 

 

★ printk를 쓸 때 주의해야 할 점

→ printk의 호출 빈도를 반드시 체크해야 한다.

리눅스 커널에서 1초에 수백 번 이상 호출되는 함수에 printk를 사용하면 시스템이 락업되거나 커널 패닉으로 오동작할 수 있음

∵ printk가 커널 입장에서 많은 비용이 드는 함수이기 때문

락업 : 리눅스 디바이스에서 마우스를 움직이거나 키보드를 입력해도 아무런 반응이 없는 상황

 

 

3.3 dump_stack( ) 함수

 

→ 커널 로그를 통해 커널 동작을 보여주는 기능

 

▶ dump_stack( ) 함수 사용법

 

- "linux/kernel.h" 헤더 파일 추가하기

- asmlinkage __visible void dump_stack (void); 인자와 반환값 모두 void

 

▶ dump_stack( ) 함수로 커널 로그에서 콜 스택 확인하기 

 

 

_do_fork( ) 함수 : 함수 콜 스택을 확인하기 위한 코드

 

부팅 후 출력되는 커널 로그

 

01 : 콜 스택을 실행한 프로세스 정보

02~07 : 콜 스택

06 : sys_clone( ) 함수에서 _do_fork( ) 함수를 호출한다고 알려줌

 

_do_fork ( ) 항수에 dump_stack ( ) 함수를 추가했을 때의 콜 스택

 

함수 호출은 07번째 줄에서 03번째 줄 방향으로 이뤄짐

 

★ dump_stack( ) 함수를 쓸 때 주의해야 할 점

→ dump_stack( ) 함수를 호출하여 콜 스택을 보려는 코드가 자주 호출되는지 점검해야 함

dump_stack( )은 현재 실행 중인 프로세스 스택 주소를 읽어 스택에 푸시된 프레임 포인터 레지스터를 읽고,

ARM 아키텍처의 함수 호출 규약에 따라 프레임 포인터 레지스터를 읽어 함수 호출 내역을 추적하는 동작 반복

 

 

3.4 ftrace

→ 리눅스 커널에서 제공하는 강력한 디버그 기능

 

- 함수 호출 흐름을 소스코드를 수정하지 않고도 볼 수 있음

- 커널의 세부 실행 정보 출력

- 1초에 수십 번 호출해도 성능에 부담 없음

- 커널 로그 함께 볼 수 있음

 

※ ftrace의 특징

① 인터럽트, 스케줄링 커널 타이머 등의 커널 동작을 상세히 추적한다.
② 함수 필터를 지정하면 지정한 함수를 호출한 함수와 전체 콜 스택까지 출력하며 코드를 수정할 필요가 없다.
③ 함수를 어느 프로세스가 실행하는지 알 수 있다.
④ 함수가 실행된 시각 정보를 알 수 있다. 
⑤ ftrace 로그를 활성화해도 시스템 동작에 부하를 거의 주지 않는다.

 

▶ ftrace 설정

 

 

/sys/kernel/debug/tracing에서 ftrace 설정 파일을 확인할 수 있다.

 

- sleep 1 : 1초 동안 딜레이를 주는 동작

- tracing_on : 트레이서 활성화

- tracer 설정

① nop : 기본 트레이서, ftrace 이벤트만 출력
② function : 함수 트레이서, set_ftrace filter로 지정한 함수를 누가 호출하는지 출력
③ function_graph : 함수 실행 시간과 세부 호출 정보를 그래프 포맷으로 출력

- set_ftrace_filter : 필터 설정

→ 리눅스 커널에 존재하는 모든 함수를 필터로 지정할 수는 없고, available_filter_functions 파일에 포함된 함수만 지정할 수 있음

 

▶ 추가 설정 파일

- buffer_size_kb : ftrace 로그의 버퍼 크기, 킬로바이트 단위, ftrace 로그를 더 많이 저장하고 싶을 때 설정

- available_filter_functions : 트레이싱할 수 있는 함수 목록을 저장한 파일

- events : ftrace에서 제공하는 이벤트의 종류를 알 수 있는 디렉터리

     - sched : 프로세스가 스케줄링되는 동작과 스케줄링 프로파일링을 트레이싱하는 이벤트를 볼 수 있음
     • sched_switch: 컨텍스토 스위칭 동작 
     • sched_wakeup: 프로세스를 우는 동작 
     - irq : 인터럽트와 Soft IRQ를 트레이싱하는 이벤트
     • irq_handler_entry: 인터럽트가 발생한 시각과 인터럽트 번호 및 이름을 출력 
     • irq_handler_exit: 인터럽트 핸들링이 완료 
     • softirq_raise: Soft IRQ 서비스 실행 요청 

     • softirq_entry: Soft lRQ 서비스 실행 시작 

     • softirq_exit: Soft IRQ 서비스 실행 완료 

 

▶ ftrace 로그 추출

 

 

./get_ftrace.sh로 셸 스크립트를 실행하면 같은 폴더에 ftrace 로그가 담긴 ftrace log.c 라는 파일이 생성됨

 

★ ftrace는 커널 코드 분석의 안내자이다.

→ ftrace 이벤트의 이름으로 커널 내부의 어떤 소스코드에서 이벤트를 출력하는지 알 수 있기 때문

 

각 이벤트를 출력하는 함수 목록

 

3.5 임베디드 디버거의 전설 TRACE32

 

▶ 주소로 코드 정보 파악

 

 

▶ 전역 변수 확인

 

 

▶ 구조체를 주소로 캐스팅

 

 

▶ 어셈블리 코드 보기

 

 

 

'2021 SUMMER STUDY > LINUX KERNEL' 카테고리의 다른 글

Week05_프로세스3  (0) 2021.08.21
Week04_프로세스2  (0) 2021.08.15
Week03_프로세스  (0) 2021.08.09
Week01_리눅스 소개와 전망  (0) 2021.07.18

1.5 임베디드 리눅스 개발 단체

 

1) 리눅스 커널 커뮤니티

→ 리눅스 커널 개발의 심장으로 논리적 오류나 문제점을 개선하는 패치를 논의하고 관리함

 

① 버그 수정 패치

② 코드 리팩터링

③ 신규 알고리즘

④ 문서화

 

리눅스 커널 패치 배포 시 발송되는 메일

 

리눅스 커널 버전과 코드 내역은 리눅스 커널 https://www kern l.org/) 사이트에서 확인 가능

 

리눅스 커널 소스 저장소

 

- longterm : 안정화된 리눅스 커널 버전

→ 리눅스 커널 커뮤니티에서 관리하는 안정화된 리눅스 커널 버전을 LTS(Long Term Support)라고 부름

 

 

2) CPU 벤더

→ CPU를 설계하는 회사를 뜻함

 

- 대표 업체 : ARM(ARMv7/ARMv8), 인텔(x86), IBM(PowerPC)

- 리눅스 커널 개발에 참여 

- 리눅스 커널 핵심 기능 : 시스템 콜, 익셉션, 컨텍스트 스위칭

 

CPU 아키텍처와 리눅스 드라이버 계층도

 

커널의 핵심 동작은 서로 다른 CPU 어셈블리 코드로 구현되어 있고, 컨텍스트 스위칭의 세부 동작은 CPU 별로 구현 방식이 다름

 

라즈비안과 같이 ARMv7 기반 리눅스 커널을 쓰려면?

→ ARMv7에 맞는 빌드 스크립트로 커널을 빌드하면 된다.

 

즉, 리눅스 커널은 다양한 CPU 아키텍처를지원하는 소스 트리를 갖추고 있으며 사용하고자 하는 CPU 아키텍처에 맞춰 빌드하면 이에 맞는 커널 이미지를 생성한다.

 

 

3) SoC 벤더

→  SoC를 개발하는 업체인 브로드컴, 삼성전자(시스템 LSI), 퀄컴, 인텔, 미디어택 엔비디아 같은 회사를 뜻함

 

※ SoC(System-on-Chip) :  하나의 컴퓨터 또는 다른 전자 시스템들의 모든 구성 요소를 통합한 집적회로

 

- SoC 벤더에서 개발하는 제품명

• 브로드컴: BCM(bcm2837. 라즈베리 파이에 탑재) 
• 삼성전자(시스템 LS|): 엑시노스(Exynos) 
• 퀄컴:스냅드래곤 
• 인텔아톰무어필드 
• 마디어텍헬리오 
• 엔비디아: 테그라 

 

soc 벤더에서 개발하는 리눅스 드라이버 계층도

 

→ 리눅스 커널을 사용하여 SoC 하드웨어를 제어하는 디바이스 드라이버 작성

 

 

4) 보드 벤더 및 OEM

→ 보드 벤더는 라즈베리 파이 재단과 같은 업체이고 OEM은 삼성전자, LG 전자와 같이 상용 제품을 개발하는업체를 뜻함

 

보드 벤더 및 OEM 이 개발하는 리눅스 드라이버 계층도

 

→ SoC 벤더에서 작성한 드라이버에서 버그를 확인하면, 

보드 벤더 및 OEM 업체는 버그를 리포트하고 개선 패치를 받아 수정하는 경우가 많음

 

 

1.6 임베디드 리눅스 개발을 잘 하려면 무엇을 알아야 할까?

 

★ 임베디드 리눅스 개발자가 알아야 할 지식

 

- 디바이스 드라이버

- 리눅스 커널

- CPU 아키텍처

- SoC

※ 알아두면 좋음

- 유저 공간 HAL(Hardware Abstraction Layer) 코드 구현 
- 빌드 스크립트구현 
- 테스트용 디바이스 드라이버 구현 
- Git과 형상 관리

 

 

1) 디바이스 드라이버

- 인터럽트 핸들러 함수와 인터럽트를 처리하는 방식 
- 디바이스 파일로 open/read/write 연산에 대한 함수를 등록하는 방법 
- 디바이스 트리를 읽어 디바이스 속성을 저장하는 방식 

 

2) 리눅스 커널

- 디바이스 드라이버는 리눅스 커널에서 제공하는 함수로 구성되어 있음

- 디바이스 드라이버를 개발하는 과정은 인증 테스트 부서를 통해 드라이버 안정화 테스트 과정을 거치며,

   이 과정에서 다양한 버그나 문제 증상이 리포트됨

 

3) CPU 아키텍처

- 리눅스 커널의 핵심 개념은 어셈블리 코드로 구현됨

ex) 컨텍스트 스위칭, 익셉션 벡터, 시스템 콜, 시그널 핸들러, 메모리 관리(MMU)

 

4) 빌드 스크립트와 Git

- 다른 업체가 개발한 드라이버나 응용 프로그램을 현재 사용 중인 소스트리에 추가할 때 사용

 

 

1.7 라즈베리 파이와 리눅스 커널

 

1) 라즈베리 파이 실습 보드

 

라즈베리 파이 3 모델 B의 기본 하드웨어 스펙

• Soc: Broadcom BCM2837 Soc 
• CPU: 1.2GHz ARM Cortex- A53 MP4 
• GPU: Broadcom VideoCore IV MP2 400 MHz 
• 메모리: 1GB LPDDR2 
• SD 카드: Micro SD, push-pull type 

 

 

2) 리눅스 커널 버전

 

- 라즈비안 리눅스 커널 코드 아래에서 확인 가능

https://github.com/raspberrypi/linux/tree/rpi-4.19.y 

 

- 리눅스 커널 커뮤니티에서 관리하는 리눅스 커널 코드를 보려면 다음 URL 참고

https://elixir.bootlin.com/linux/v4.19.30/source

 

 

3) 라즈비안 버전

 

- 책에서 다룬 커널 패치는 다음 버전의 라즈비안 이미지에서 테스트함

2019-07-10-raspbian-buster-full 

 

- 다음과 같은 리눅스 커널 버전에서 활용 가능

4.14/4.9/4.4/3.18 

 

 

4) ARM 아키텍처

 

라즈베리 파이 3 모델 B는 ARMv7 아키텍처를 기반으로 동작하므로

이 책에서는 이를 기준으로 ARM 아키텍처와 관련된 동작을 설명한다.

'2021 SUMMER STUDY > LINUX KERNEL' 카테고리의 다른 글

Week05_프로세스3  (0) 2021.08.21
Week04_프로세스2  (0) 2021.08.15
Week03_프로세스  (0) 2021.08.09
Week02_커널 디버깅과 코드 학습  (0) 2021.07.25

<Daedalus: Breaking Non-Maximum Suppression in Object Detection via Adversarial Examples> - Derui Wang, Chaoran Li, Sheng Wen, Qing-Long Han, Fellow, IEEE, Surya Nepal, Xiangyu Zhang, and Yang Xiang, Fellow, IEEE

 

 

중복 탐지 결과를 필터링하기 위해 OD 작업에서 일반적으로 사용되는 NMS가 더 이상 안전하지 않음을 보여준다.

※ OD(Object Detection) : 객체 검출

- 어떤 이미지를 입력했을 때 그 결과가 해당 객체를 Localization 해주고, 해당 box 안에 있는 객체가 무엇인지 분류

※ NMS(Non-Maximum Suppression) : 네트워크 관리 시스템

- 컴퓨터 네트워크 또는 네트워크들을 모니터링하고 관리하는데 사용되는 하드웨어와 소프트웨어의 조합을 총칭

 

NMS는 OD 시스템의 필수적인 부분이므로 NMS 기능 방해 시 시스템에 치명적인 결과 초래 가능

 

이 논문에서는 end-to-end OD 모델에서 NMS의 오작동을 유발하는 적대적 예시 공격을 제안한다.

 

 

1. Introduction

 

 

YOLO-v3 에 대한 디지털  Daedalus  공격의 데모

 

위 그림과 같이 적절하게 제작된 적대적 예제는 YOLO-v3에서 NMS 구성 요소의 오작동을 유발할 수 있으며, 이는 밀집되고 노이즈가 많은 탐지 결과를 출력하는 방식이다.

오탐지 결과로 구성된 미로를 생성하기 때문에 이 공격을 Daedalus라고 명명한다.

 

OBJECT Detection(OD)은 컴퓨터 비전 분야의 기본 작업이며 자율주행차, 로봇 공학, 감시 시스템 및 생체 인증 분야에서 반복적으로 사용된다.

CNN(Convolutional Neural Network)은 많은 최첨단 OD 모델의 핵심에 내장되어 있다.

 

왼쪽 상단 이미지 : COCO 데이터 세트에서 가져온 원본 이미지

오른쪽 상단 이미지 : OD 결과

왼쪽 하단 이미지 : 적대적 예

오른쪽 하단 이미지 : 적대적 예의 OD 결과

적대적인 예는 NMS 이후에 최종 탐지 상자의 수를 크게 늘리고 탐지기를 사용할 수 없게 만든다.

 

OD 시스템의 NMS 구성 요소가 제대로 작동하지 않으면 시스템이 실패하고, CNN은 적대적 예시 공격에 취약하다.

 

※ 가양성률(False Positive Rate, FPR) : 인벤토리 관리 및 군용 물체 인식과 같은 OD 임무에서 중요한 메트릭

 

가양성 비율을 높이는 공격은 OD 시스템에 매우 치명적이다.

 

이 논문의 기여 내용은 다음과 같다.

1) 단순히 오분류를 목표로 하는 기존의 최첨단 공격과 달리 NMS를 깨는 것을 목표로 하는 새로운 적대적 예제 공격을 제안하여 결과적으로 공격은 탐지 결과에 많은 오탐지를 생성한다.

2) 다양한 모델에서 NMS 오작동을 일으킬 수 있는 보편적인 적대 사례를 생성하기 위해 ensemble-of-substitutes 공격이 제안되었는데, 이러한 방식으로 블랙박스 공격은 부분적으로 화이트박스 공격으로 전환될 수 있다.

3) Daedalus의 작은 변화가 포함된 실제 포스터는 실제 OD 응용 프로그램을 실제로 공격하도록 제작되었다.

 

 

2. PRELIMINARIES

 

A. 적대적 예제

 

 

 

F : DNN 모델

x : 원본 데이터 예제

δ : 섭동(작은 변화)

L : 공격자가 설정한 적대적 목표

y : F에 대한 정답 출력 또는 원하는 적대적 출력

c : 적대적 손실과 왜곡의 균형을 맞추기 위한 상수

|δ|p : δ의 표준p값에 의해 경계가 지정된 허용된 왜곡

x+δ : 적대적 예제 생성

 

F와 x가 주어지면 공격자는 섭동 δ를 추가하여 x의 기능을 변경하고, x의 적대적 예제를 만들 수 있다.

 

적대적 예를 생성하는 것은 적대적 목표를 향한 예시 기능을 최적화하는 것으로 해석될 수 있고,

기울기 기반 최적화 방법은 일반적으로 적대적 예를 검색하는 데 사용된다.

box-constrained non-convex 최적화 문제는 일반적으로 경사하강법으로 해결된다.

 

 

B. 객체 감지 모델의 인기 조사

 

 

Github에서 수행한 OD 프로젝트의 인구 조사

 

OD 작업에 사용되는 모델과 백본이 매우 제한적이다.

※ 백본(backbone) : 다양한 네트워크를 상호 연결하는 컴퓨터 네트워크의 일부

 

OD 모델에 대한 블랙박스 공격은 부분적으로 화이트박스 공격으로 전환될 수 있다.

→ 공격자는 먼저 모든 인기 있는 화이트박스 OD 모델을 깨는 보편적인 적대적 예제를 만든 다음 이 예제를 사용하여 블랙박스 모델에 대한 공격을 시작할 수 있고, 이 공격은 블랙박스 모델과 동일한 매개변수를 가질 수 있기 때문에 블랙박스 모델을 깨뜨릴 가능성이 높기 때문이다.

 

 

C. 객체 감지

 

입력 프레임이 주어지면 종단 간 OD 모델은 FCN을 통해 감지된 회귀 상자 및 분류 확률을 출력한다.

여기서는 YOLO-v3(You Only Look Once) 감지기를 예로 사용

→ YOLO-v3는 서로 다른 스케일(즉, 13 × 13, 26 × 26, 52 × 52)의 3개의 메쉬 그리드를 사용하여 입력 이미지를 분할

→ 모델은 이 세 가지 척도에 대한 검출 결과를 출력

 

Darknet-53 백본은 경계 상자 매개변수, 상자 신뢰도 및 객체 클래스 확률을 포함하는 기능 맵을 출력

→ 높이 th, 너비 tw, 중심 좌표(tx, ty), 클래스 확률 p1, p2, ..., pn 및 객체 t0이 포함

→ t0은 상자에 개체가 포함되어 있다는 신뢰도

→ 각 감지 상자의 위치는 pw 및 ph 이전의 앵커 상자 차원과 이미지의 왼쪽 상단 모서리로부터의 중심 오프셋(cx, cy)을 기반으로 계산

 

최종 상자 치수 및 위치

 

bw : 상자 너비

bh : 상자 높이

bx, by : 상자 중심의 좌표

 

상자 신뢰도 b0

 

물체가 미리 설정된 임계값 미만인 상자는 폐기되고, 출력은 NMS에서 처리되어 최종 감지 결과 생성

 

 

D. NMS(Non-Maximum Suppression)

 

NMS는 OD 알고리즘에 통합되어 탐지 상자를 필터링한다.

NMS는 탐지 상자 중 IoU(Intersection over Union)를 기반으로 선택하고,

IoU는 두 상자 간의 결합 영역에 대한 중첩 영역의 비율을 측정한다.

 

※ NMS의 단계

→ 나머지 상자 내에서 NMS는 후보 집합에 남은 상자가 없을 때까지 아래 두 단계를 반복

1) 주어진 객체 범주에 대해 범주(즉, 후보 집합)에서 감지된 모든 경계 상자는 상자 신뢰도 점수에 따라 높음에서 낮음으로 정렬

2) NMS는 가장 높은 신뢰도 점수를 가진 상자를 탐지 결과로 선택하고 선택된 상자의 IoU 값이 임계값을 초과하는 다른 후보 상자를 폐기

 

NMS 알고리즘

 

NMS는 모든 원시 제안이 처리될 때까지 모든 객체 범주의 원시 탐지 제안에서 중복 탐지 상자를 재귀적으로 버린다.

 

 

3. THE DAEDALUS ATTACK

 

Daedalus 공격 가이드라인

→ NMS를 깨기 위해 악용하는 취약점 분석

→ 적대적 예제를 만드는 데 사용되는 일반적인 최적화 기술 소개

→ Daedalus 적대적 예제를 생성하기 위한 일련의 적대적 손실 함수 제안

→ 알고리즘을 조합하여 Daedalus 공격 제시

 

이 공격은 탐지 네트워크가 NMS의 오작동을 일으키는 적대적 특징 맵을 출력하도록 할 수 있다.

 

NMS를 공격하는 데 사용한 체계

 

1) 모든 상자 쌍 간의 IoU(중첩 영역의 비율) 최소화 → 왼쪽 체계

2) 모든 상자의 차원을 최소화하고 모든 상자의 상자 중심 간의 유클리드 거리를 최대화 → 오른쪽 체계

3) 모든 상자의 차원만 최소화 → 저비용 근사

 

 

A. NMS 공격

 

★ NMS 취약점

- NMS는 IoU를 기반으로 상자 필터링

- 원시 탐지 상자를 얻은 후 주어진 임계값 미만의 신뢰도 점수를 가진 상자는 폐기

- 주어진 객체 클래스와 상자 신뢰도 점수가 가장 높은 이 클래스의 상자(즉, 최종 탐지 상자)에 대해 NMS는 최종 탐지 상자가 있는 IoU를 기반으로 다른 나머지 상자를 버림

→ NMS가 출력 경계 상자 간의 IoU를 억제하는 공격에 취약하게 만듦

 

다음 세 가지 기본 체계가 NMS를 깨는 것으로 간주된다.

1) 대부분의 경계 상자가 상자 신뢰도에 따라 상자를 버리는 첫 번째 필터링 라운드에서 살아남을 수 있도록 하기 위해 상자 신뢰도를 최대화한다.

2) IoU를 압축하기 위해 각 상자 쌍에 대한 IoU를 직접 최소화한다.

3) 모든 경계 상자에 대한 상자 차원의 기대치를 최소화하고 모든 상자 쌍에 대한 상자 중심 간의 유클리드 거리 기대치를 최대화한다.

 

 

B. 적대적 예시 생성

 

최적화된 문제로 공격 공식화

 

x : 원본 예제

x' : x의 적대적 예제

δ = x' − x : 적대적 섭동

f : 적대적 손실 함수

c : 왜곡과 적대적 손실 f의 균형을 유지하는 상수

 

적대적 예제의 픽셀 값을 0과 1 사이로 제한하기 위해 변수를 변경하는 아이디어 채택

→ 최적화 변수를 δ에서 ω로 변경

 

 

최적화 수렴을 더 빠르게 하기 위해 쌍곡선 탄젠트 함수를 선택하여 변수 변경

→ δ의 δi에 대해 위와 같은 쌍곡선 탄젠트 함수를 적용

 

 

C. 적대적 손실 함수

 

NMS의 오작동을 유발하는 적대적 예를 찾기 위해 아래와 같은 세 가지 손실 함수를 설계

 

세 가지 손실 함수 f1, f2, f3

 

f1 : 먼저 탐지된 개체가 공격 범주 집합 Λ에 있는 모든 상자에 대해 상자 신뢰도와 1 사이의 평균 제곱 오차의 기대치를 최소화

f2 : 상자 차원의 기대치를 최소화하고 상자 거리의 기대치를 최대화

→ 상자 크기를 압축하고 감지된 영역에 상자를 더 고르게 분배하여 IoU를 직접 최소화하는 효과

f3 : IoU의 기대치를 직접 최소화하는 대신 상자 크기의 기대치를 최소화

 

∴ 상자는 NMS에 의해 필터링되는 것을 피할 수 있다.

 

 

D. Ensemble of Alternatives

 

현재 OD 작업에 대한 관찰을 기반으로 블랙박스 공격을 화이트박스 공격으로 변환하는 앙상블 방법 개발

 

※ 블랙박스 공격 : 공격자가 모델에 대한 정보를 알지 못하고 공격하는 것

→ 공격자는 사전에 제작된 값을 입력하여 출력되는 결과를 관찰하며 모델의 취약성을 분석한다.

※ 화이트박스 공격 : 공격자가 모델에 대한 모든 정보를 알고 공격하는 것

→ 공격자는 모델의 취약성을 파악하기 쉬워지고 적대적 예제를 만들어 충분한 시뮬레이션을 수행할 수 있기 때문에 치명적인 결과를 초래할 수 있다.

 

Daedalus 공격은 오분류를 유발하는 대신 다른 공격 목적을 가지고 있다. (즉, NMS 비활성화)

 

백본에서 추출한 피쳐 맵이 매우 다양하기 때문에 OD 분야에서 블랙박스 모델을 공격하는 또 다른 경로를 선택함

→ Daedalus를 사용하여 블랙박스 공격을 시작하기 위해 인기 있는 OD 모델의 앙상블을 대용으로 사용하여 적대적 예제를 생성

 

생성된 적대적 예제는 모든 인기 있는 모델에 대해 효과적일 수 있고,

보편적인 적대적 사례는 블랙박스 모델의 NMS를 깨뜨릴 가능성이 높다.

 

 

 

M : 인기 있는 OD 모델과 백본을 포함하는 인기 있는 백본이 있는 OD 모델 세트

fm : M에서 m번째 모델의 손실 값

 

 

E. NMS에 대한 Daedalus 공격

 

Daedalus 공격은 모든 FCN 기반 탐지기에 적용될 수 있고,

FCN 기반 감지기는 감지된 상자 크기, 상자 위치 및 분류 확률을 완전히 미분 가능한 종단 간 방식으로 출력한다.

∴ 공격은 종단 간 적대적 기울기를 계산하고 FCN 기반 탐지기에 대한 적대적 예를 최적화할 수 있다.

 

 

 

 

 

입력으로 이미지 x가 있는 OD 작업이 주어지면 NMS의 경계 상자 수가 최대화된다.

1) 최종 탐지 결과를 얻기 위해 특징 맵 뒤에 변형 레이어 추가

2) 변환 레이어는 기능 맵의 tx 및 ty에 시그모이드 변환을 적용하여 상자 중심 좌표 bx 및 by를 얻음 

3) 상자 너비 bw와 상자 높이 bh를 얻기 위해 tw와 th에 지수 변환이 적용

4) 손실 함수 값 계산

5) 왜곡과 함께 손실 값을 최소화하여 Daedalus 적대적 예제 생성

 

※ Daedalus는 공격을 시작하기 위해 상자 매개변수만 필요로 한다.

 

다른 백본 네트워크를 사용하더라도 경계 상자의 기하학적 정보를 포함하는 특징 맵을 출력하는 탐지 모델에

공격이 적용될 수 있다.

 

 

4. EVALUATION

 

A. 실험 설정

- 이 실험에서는 공격 대상 모델로 YOLO-v3를 이용했으며, YOLO-v3에서는 임계값이 0.5로 사용된다.

- 최적의 손실 함수를 선택한 다음 NMS를 사용한 YOLO-v3 기반 Daedalus 공격의 성능을 정량화한다.

- 최상의 상수 c를 찾기 위한 이진 검색 중 최대 검색 단계 수는 5로 설정된다.

- 평가 결과를 통합하기 위해 COCO 데이터셋의 80개 객체 범주를 모두 공격 대상 집합 Λ에 포함시킨다.

- 공격 대상인 사람과 자동차 카테고리를 선택한다.

 

B. 손실 함수 선택

- COCO 데이터 세트에서 10개의 임의 이미지를 선택한 후 이 이미지에 대한 적대적 예시가 생성된다.

- 각 기능의 성능은 서로 다른 신뢰 점수에서 적대적 사례를 찾는 성공률을 보고 측정된다.

- 기록된 런타임과 GPU 사용률은 평균을 낸다.

 

이 논문에서는 f3(수식8)이 서로 다른 γ 값에서 적대적 사례를 찾는 데 가장 좋은 성공률을 보이는 것을 관찰할 수 있었다.

또한, f3은 런타임과 GPU 활용도가 가장 낮기 때문에 Daedalus의 손실 함수로 선택된다.

 

C. 정량적 성능

- 이 공격을 다음과 같은 두 가지 관점에서 평가할 필요가 있다.

① Daedalus 공격이 다양한 NMS 임계값에서 어떻게 수행되는지 평가

② 공격 신뢰 수준(γ)이 탐지 결과에 어떤 영향을 미치는지 조사

- 공격 성능은 FP(False Positive) 비율, 평균 mAP(Average Precision) 및 예제의 왜곡이라는 세 가지 메트릭을 기반으로 정량화됨

 

 

Nφ : 위양성 탐지 상자의 수

N : 다음으로 찾은 경계 상자의 총 수

 

NMS 임계값 및 공격 신뢰도와 관련한 IoU 임계값 0.5에서 위양성 비율

 

NMS 임계값 범위 : 0.5~0.95

신뢰도 범위 : L2공격 - 0.1~0.9, L0공격 - 0.1~0.8

 

NMS 임계값 및 공격 신뢰도와 관련한 IoU 임계값 0.75에서 위양성 비율

 

FP rate : NMS에 의해 필터링되지 않은 중복 상자의 비율 측정

→ FP는 최대 1이며 FP 값이 높을수록 공격 성공률이 높아진다.

 

NMS 임계값과 관련한 IoU 임계값 0.5에서 L0 공격 오탐지율

 

각 FP rate는 100개의 Daedalus 사례의 탐지 결과에서 평균을 낸다.

 

NMS 임계값과 관련한 IoU 임계값 0.75에서 L0 공격 오탐지율

 

공격 신뢰도가 0.1인 경우에도 다양한 NMS 임계값에서 최소 90%의 FP rate가 존재하고,

NMS 임계값을 높이면 신뢰도가 낮은 공격의 FP rate가 약간 감소한다.

 

 

mAP : 평균 정밀도, OD 모델의 성능을 평가하는 데 사용

M : 객체 범주의 수

 

NMS 임계값 및 공격 신뢰도에 대한 Daedalus 예제 탐지 결과의 mAPIoU=.50

 

임계값 범위 : 0.5~0.95

 

NMS 임계값 및 공격 신뢰도에 대한 Daedalus 예제 탐지 결과의 mAPIoU=.75

 

위 2개의 그림들은 NMS 임계값과 γ를 변경했을 때의 검출 결과의 mAP 값을 보여준다.

결과에 따르면 L0 및 L2 공격 모두 탐지기의 mAP를 45% ~ 59%에서 0% ~ 17.8% 사이의 값으로 감소시키고,

공격의 신뢰도가 0.2를 초과하면 mAP가 0%로 떨어진다.

 

적대적 사례의 왜곡은 γ와 양의 상관관계가 있음을 알 수 있다.

신뢰도가 0.6에 도달하기 전까지는 왜곡이 천천히 증가하다가 신뢰도가 0.6을 넘으면 왜곡량이 급격히 증가한다.

→ L0 및 L2 공격 모두 신뢰도가 낮은 예를 만들기 위해 중간 정도의 왜곡이 필요하다.

 

NMS 임계값에 대한 L0 및 L2 Daedalus 공격의 mAPIoU=.50

 

임계값 범위 : 0.5~0.95

각 mAP는 100개의 Daedalus 예제의 탐지 결과에서 평균을 낸다.

 

NMS 임계값에 대한 L0 및 L2 Daedalus 공격의 mAPIoU=.75

 

L0 공격은 신뢰도가 0.8 이상일 때 왜곡을 줄일 수 있다.

FCN 기반 물체 감지기에서 분할한 각각의 그리드 셀은 정상적인 검출 결과를 출력할 수 있고, 이는 NMS로 필터링 할 수 있다.

결과적으로 L0 공격은 대부분의 픽셀을 교란시켜 잘 검증된 적대적 예제를 생성하며, 이는 예제에서 높은 왜곡을 의미한다.

 

 

5. ANALYSIS OF THE ATTACK

 

A. Soft-NMS 깨기

→ Daedalus 공격이 NMS 알고리즘의 변형, 즉 soft-NMS로 확장될 수 있는지의 여부를 알아보자.

 

Soft-NMS : 겹치는 상자를 버리는 대신 신뢰 점수를 반복적으로 감소시키는 공격

Soft-NMS가 처리할 수 있는지의 여부를 조사하기 위해 L0과 L2 버전을 모두 공격했다.

 

(a) soft-NMS에 대한 L0 Daedalus 공격, (b) soft-NMS에 대한 L2 Daedalus 공격

 

왼쪽 상단 : 신뢰도 0.3으로 제작된 예시

오른쪽 상단 : NMS 탐지 결과

왼쪽 하단 : 선형 soft-NMS의 결과

오른쪽 하단 : 가우시안 soft-NMS의 결과

 

위의 그림을 통해 결과적으로 L0과 L2 모두 선형 Soft-NMS와 Gaussian Soft-NMS를 깨뜨릴 수 있음을 알 수 있다.

 

B. Universal Daedalus의 예

→ RetinalNetResnet-50 공격에 적용하여 공격의 보편성을 시연해보자.

 

YOLO-v3, SSD 및 RetinaNet에 대한 범용 Daedalus 예는 이미 1,696개 리포지토리 중 54.9%를 깰 수 있다.

 

적대적 예시는 모든 모델에 대해 NMS 오작동을 유발할 수 있다.

OD 모델이 많은 경우 공격자는 Multi-task Learning과 같은 방법을 사용하여 손실 함수에서 각 항에 대한 적절한 계수를 찾아 공격 성능을 향상시킬 수 있다.

 

적대적 예시의 탐지 결과는 다음과 같다.

 

ensemble-of-substitutes 접근 방식으로 만든 Daedalus 적대적 예제의 탐지 결과

 

위와 같이 RetinaNet, SSD, YOLO-v3를 사용하여 적대적인 예를 감지한다.

첫 번째 행에는 원본 예제와 탐지 결과, 두 번째 행에는 적대적 예제와 적대적 예제의 탐지 결과를 나타낸다. 

 

C. 물리적 Daedalus의 예

 

실제 세계에서 Daedalus 공격을 시작하기 위해 발견된 섭동을 포스터로 인스턴스화해야 한다.

포스터가 물체 감지 시스템의 카메라에 포착되면 NMS 오작동을 유발한다.

 

 

Φ : 임의의 변환(확대/축소, 회전)의 집합

SNPS : 포스터 δ의 하위 샘플링된 비인쇄성 점수

NPS(Non-Printability Score) : 인쇄된 픽셀과 해당 디지털 픽셀 간의 오류를 측정하는 데 사용됨

 

큰 이미지의 NPS를 계산하는 데는 비용이 많이 들기 때문에 샘플 속도 β와 δ의 픽셀이 주어지면 픽셀의 하위 집합을 샘플링하여 SNPS를 계산한다.

효과적인 Daedalus 포스터를 만들기 위해서는 0.1% ~ 1%의 픽셀에서만 NPS를 계산해야 한다.

 

D. Adaptive defences

 

Daealus는 탐지 상자를 최소화하여 NMS 오작동을 유발한다.

 

YOLO-v3의 탐지 결과에서 경계 상자 차원의 분포

 

분포는 각각 100개의 COCO 이미지 및 적대적 사례의 탐지 결과를 기반으로 한다.

양성 결과에는 총 812개의 상자가 있고 적대적 결과에는 286,469개의 적대적 상자가 있는데, 방어를 위해 NMS 프로세스에서 치수가 103.62 미만인 상자는 폐기된다.

 

NMS 방어가 있는 YOLO-v3의 FP 속도 및 mAP

 

NMS 프로세스(즉, NMS 방어)에서 허용되는 최소 탐지 상자 크기를 제한한다.

위 그림에서 볼 수 있는 것과 같이 결과에 따르면 NMS 방어는 효과적인 방어가 아니다.

 

▶ 방어에 대한 평가

① 방어가 적대적 예제를 재구성하여 mAP를 증가시키고 FP 비율을 감소시킬 수 있는지의 여부

② 적대적 사례를 양성으로 전환할 수 없는 경우 재구성 오류를 감지할 수 있는지의 여부

→ 이 두가지의 질문에 답하기 위해 FP rate를 측정한다.

 

MagNet 방어가 있는 YOLO-v3의 FP 속도 및 mAP

 

위와 같이 자동 인코더로 Daedalus 예제를 수정하면 YOLO-v3의 성능이 약간 향상될 수 있다.

그러나 FP-rate@.50은 여전히 ​​0.6 이상, FP-rate@.75는 0.7 이상으로 유지되고, mAP@.50은 0.45 미만, mAP@.75는 0.3 미만으로 유지된다.

또한, 공격 신뢰도가 0.7 이상으로 올라가면 모델 성능이 떨어진다.

 

★ 평가 결과

① 적대적 사례를 재구성하는 것은 탐지 모델의 성능을 거의 향상시킬 수 없다.

② 공격 신뢰도가 0.5에 도달한 후에야 재구성 오류가 증가한다. (즉, 신뢰 수준이 0.5 미만인 공격을 탐지하기 어렵다.)

∴ Daedalus 공격은 OD 작업에 위협적이며 NMS는 더 이상 OD에 대한 보안 솔루션이 아니다.

 

 

6. CONCLUSION

 

이 논문에서는 객체 탐지 모델에서 NMS 기능을 비활성화하는 것을 목표로 하는 새로운 유형의 적대적 예제를 제안했다.

Daedalus 공격은 기존의 모든 공격과 달리 NMS의 오작동을 일으키는 적대적 사례를 생성하며 공격 대상 개체 클래스를 모두 제어하여 공격받은 모델은 더 이상 작동하지 않을 정도로 노이즈가 심한 탐지 결과를 출력한다.

즉, Daedalus 공격은 실제 세계에서 치명적인 결과를 초래할 수 있는 객체 탐지 알고리즘 자체의 취약점을 보여준다.

또한, Daedalus 공격의 전송 가능성은 선택한 대체물의 영향을 받기 때문에 상자 차원의 기대치를 최소화하는 데 의존하며, 이는 여러 감지 모델에서 NMS가 오작동할 수 있다.

'2021 INCOGNITO > Object Detection' 카테고리의 다른 글

NMS(Non-Maximum Suppression)  (1) 2021.07.28
Perception  (0) 2021.07.13

1. Ubuntu 18.04 LTS Desktop

 

 

설치 과정 중 오류가 저장용량의 문제인 것 같아 하드디스크 40GB, 메모리 8GB로 설정하였다.

 

 

2. ROS Melodic

 

 

Ubuntu 18.04에 맞는 ROS Melodic 버전을 설치해야 한다.

 

1) source.list, keys 설정

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'

sudo apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654

 

 

2) Desktop-Full 설치

sudo apt update 

 

 

sudo apt install ros-melodic-desktop-full

 

 

3) 환경(환경변수) 설정

echo "source /opt/ros/melodic/setup.bash" >> ~/.bashrc
source ~/.bashrc

 

 

4) 패키지 빌드를 위한 의존성

sudo apt install python-rosdep python-rosinstall python-rosinstall-generator python-wstool build-essential

 

 

5) rosdep 초기화

sudo apt install python-rosdep

sudo rosdep init
rosdep update

 

 

6) roscore

 

 

roscore했을 때 별 문제 없이 실행된다면 성공

 

 

3. Qt 5.14.2

 

http://download.qt.io/archive/qt/

위 링크에서 qt-opensource-linux-x64-5.14.2.run 다운로드

 

1) 패키지 업데이트

sudo apt-get update

 

 

2) build-essential 패키지 설치

sudo apt-get install build-essential

 

 

3) 기존 Qt 설치되어 있다면 제거 

sudo apt-get purge --auto-remove libqt4-dev

 

 

4) Qt 설치 프로그램 실행

chmod +x qt-opensource-linux-x64-5.14.2.run

./qt-opensource-linux-x64-5.14.2.run

 

 

Qt 설치가 처음이라면 sign-up 부분에 정보 입력 후 이메일 인증하기

 

 

인증 완료 후 모두 체크 후 설치

 

5) .bashrc 파일 수정

nano ~/.bashrc

 

 

nano 편집기 저장: Ctrl+O, 끝내기: Ctrl+X

 

6) 수정 파일 적용 후 버전 확인

source ~/.bashrc
qmake -version

 

 

 

4. Autoware.ai

 

 

Ubuntu 18.04이므로 여기에서는 Autoware 1.14.0버전을 설치했다.

 

 

1) System dependencies for Ubuntu 18.04 / Melodic

 

sudo apt update

 


sudo apt install -y python-catkin-pkg python-rosdep ros-$ROS_DISTRO-catkin

 


sudo apt install -y python3-pip python3-colcon-common-extensions python3-setuptools python3-vcstool

 


pip3 install -U setuptools

 

 

2) build

 

Create a workspace

mkdir -p autoware.ai/src 

cd autoware.ai

 

 

② Download the workspace configuration for Autoware.AI

wget -O autoware.ai.repos "https://raw.githubusercontent.com/Autoware-AI/autoware.ai/1.14.0/autoware.ai.repos"

 

 

③ Download Autoware.AI into the workspace

vcs import src < autoware.ai.repos

 

 

④ Install dependencies using rosdep

rosdep update

 

 

rosdep install -y --from-paths src --ignore-src --rosdistro $ROS_DISTRO

 

 

⑤ Compile the workspace

 

without CUDA Support (그래픽 X)

colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release

 

 

3) run

 

cd autoware.ai
source install/setup.bash
roslaunch runtime_manager runtime_manager.launch

 

 

 

위 화면이 뜨면 성공!!

 

 

※ 참고자료

1. 우분투 18.04 Desktop
https://gabii.tistory.com/entry/Ubuntu-1804LTS-%EC%84%A4%EC%B9%98
2. ros melodic
https://whiteknight3672.tistory.com/248
3. qt
https://webnautes.tistory.com/1413
4. autoware.ai
https://github.com/Autoware-AI/autoware.ai/wiki/Source-Build

'2021 INCOGNITO > ROS' 카테고리의 다른 글

Week02_ROS_TOPIC  (0) 2021.06.27
Week 01_ROS  (0) 2021.05.30

1) Topic이란?

 

 

- 노드들 간에 통신할 수 있는 채널

- 프로세스 간의 통신 발생 시 주고 받는 메시지의 경로

- Publisher node : 메시지를 전송하는 노드

- Subscriber node : 메시지를 수신하는 노드

 

 

2) Topic 예제 과정

 

- 패키지 생성 

- 패키지 설정 파일, 빌드 설정 파일 수정

- 메시지 파일 작성

- Publisher node 작성

- Subscriber node 작성

- 패키지 빌드 및 노드 실행

 

 

3) Topic 실습

 

① 패키지 생성

 

 

cd catkin_ws/src                

catkin_create_pkg ros_tutorials_topic message_generation std_msgs roscpp

→ message_generation, stsd,_msgs, roscpp를 의존성으로 하는 ros_tutorials_topic 패키지 생성

 

 

 

 

② 패키지 설정 파일, 빌드 설정 파일 수정

 

- 패키지 설정 파일 ( package.xml )

 

 

<?xml version="1.0"?>

→ xml 버전 명시
<package format="2">

<name>ros_tutorials_topic</name> 

→ 위에서 정한 패키지 이름 명시

<version>0.0.0</version>
<description>The ros_tutorials_topic package</description>

→ 생성한 패키지의 간략한 설명

 

 

- 의존성 관계를 설명해주는 명령어들

<buildtool_depend>catkin</buildtool_depend>

<build_depend>message_generation</build_depend>

→ 빌드할 때의 의존성
<build_depend>roscpp</build_depend>
<build_depend>std_msgs</build_depend>
<build_export_depend>roscpp</build_export_depend>

→ 헤더를 export할 때 해당 헤더가 포함되어 있다면 추가해야 함
<build_export_depend>std_msgs</build_export_depend>
<exec_depend>roscpp</exec_depend>

→ 패키지를 실행하는 도중 의존성이 필요하다면 추가해야 함
<exec_depend>std_msgs</exec_depend>

 

 

- 빌드 설정 파일 ( CMakeLists.txt )

 

 

cmake_minimum_required(VERSION 3.0.2)

project(ros_tutorials_topic)

→ 위에서 생성한 패키지명과 동일해야 함

 

find_package(catkin REQUIRED COMPONENTS message_generation std_msgs roscpp)

→ catkin을 빌드할 때 요구되는 구성요소 패키지

→ 의존성 패키지로 message_generation, std_msgs, roscpp를 의미

 

 

include_directories(${catkin_INCLUDE_DIRS})

→ 인클루드 디렉터리 설정

 

 

MsgTutorial.msg add_message_files(FILES MsgTutorial.msg) 

→ 메시지 선언 ( MsgTutorial.msg )

generate_messages(DEPENDENCIES std_msgs) 

→ catkin 패키지 옵션으로 라이브러리, catkin 빌드 의존성, 시스템 의존 패키지 기술

 

add_executable(publisher src/publisher.cpp)

add_dependencies(publisher ${${PROJECT_NAME}_EXPORTED_TARGETS} ${catkin_EXPORTED_TARGETS})

target_link_libraries(publisher ${catkin_LIBRARIES})

→ publisher 노드에 대한 빌드 옵션

 

add_executable(subscriber src/subscriber.cpp)

add_dependencies(subscriber ${${PROJECT_NAME}_EXPORTED_TARGETS} ${catkin_EXPORTED_TARGETS})

target_link_libraries(subscriber ${catkin_LIBRARIES})

→ subscriber노드에 대한 빌드 옵션

 

 

 

③ 메시지 파일 작성

 

cd catkin_ws/src/ros_tutorials_topic

mkdir msg

cd msg   

gedit MsgTutorial.msg 

 

 

- time, int32 : 메시지 형식

- stamp, data : 메시지 이름

 

※ ROS 변수 형식

 

 

 

 

④ Publisher node 작성

 

cd catkin_ws/src/ros_tutorials_topic/src/

gedit publisher.cpp

 

 

 

 

⑤ Subscriber node 작성

 

cd catkin_ws/src/ros_tutorials_topic/src/

gedit subscriber.cpp

 

 

 

 

⑥ 패키지 빌드 및 노드 실행

 

cm ros_tutorials_topic

 

 

위 명령어 정상 실행 시 3개의 터미널 열고 아래 명령어 입력 

 

roscore

rosrun ros_tutorials_topic publisher

rosrun ros_tutorials_topic subscriber

 

 

 

※ 참고자료

https://www.g.camp/41

 

표윤석 박사 ROS 강의 자료

로보티즈의 표윤석 박사의 ROS강의 노트사이트입니다. https://github.com/robotpilot/ros-seminar ROS 강의 Chapter1. 로봇 소프트웨어 플랫폼 ROS 강의 Chapter2. 로봇 운영체제 ROS ROS 강의 Chapter3. ROS 개..

www.g.camp

 

'2021 INCOGNITO > ROS' 카테고리의 다른 글

Ubuntu 18.04 + Autoware 설치  (0) 2021.07.13
Week 01_ROS  (0) 2021.05.30

+ Recent posts