카테고리 보관물: Linux

CARLA client를 build해야 하는데 clang-8이 없댄다.

2022년 9월 현재 CARLA simulator의 최신 버전인 0.9.13으로 PythonAPI를 빌드하려고 하면 clang-8 version을 요구하는데 Ubuntu 22.04에서는 clang-8의 repository를 추가하고 설치 시도하면 다음과 같이 의존성 오류가 생긴다.

The following packages have unmet dependencies:
 clang-8 : Depends: libllvm8 (>= 1:8~svn298832-1~) but it is not going to be installed
           Depends: libstdc++-5-dev but it is not installable
           Depends: libgcc-5-dev but it is not installable
           Depends: libobjc-5-dev but it is not installable
           Depends: libclang-common-8-dev (= 1:8.0.1+svn369350-1~exp1~20200112113617.82) but it is not going to be installed
           Depends: libclang1-8 (= 1:8.0.1+svn369350-1~exp1~20200112113617.82) but it is not going to be installed
           Recommends: llvm-8-dev but it is not going to be installed
           Recommends: libomp-8-dev but it is not going to be installed
 lld-8 : Depends: libllvm8 (= 1:8.0.1+svn369350-1~exp1~20200112113617.82) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

그리고 아쉽게도 하위 호환에 문제가 있는 것인지 설치 가능한 최하 버전인 clang-10으로는 CARLA client build가 되지 않는다. 빌드 스크립트에서 버전 점검하는 부분을 건너 뛰도록 수정하고 clang-10으로 강제 빌드를 시도해봤더니 역시나 빌드오류가 나면서 일이 커질것 같다는 느낌이 강하게 든다.

일일이 빌드오류 잡는 삽질을 하고 ‘CARLA client build 삽질기’를 포스팅 할 수도 있었겠지만 이번에는 문명의 이기인 Docker를 한번 누려 보기로했다.

먼저, Docker로 clang-8 설치가 가능한 Ubuntu 18.04에서 빌드를 수행한 다음(참고 CARLA – Linux Build) 빌드가 완료되면 Python client package를 host에 설치한다.

  • Docker로 Ubuntu18.04를 설치하고 CARLA의 소스 코드위치를 /carla로 마운트하여 실행한다.
$ docker pull ubuntu:18.04
$ docker run -ti -v <carla-root-path>:/carla ubuntu:18.04 /bin/bash
  • Clang-8의 repository를 추가하고 관련된 패키지들을 설치한다.
# Clang-8 repository 추가.
DOCKER# apt-get update &&
apt-get install wget software-properties-common &&
add-apt-repository ppa:ubuntu-toolchain-r/test &&
wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key|apt-key add - &&
apt-add-repository "deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-8 main" &&
apt-get update

# Install packages.
DOCKER# apt-get install -y build-essential clang-8 lld-8 g++-7 cmake ninja-build libvulkan1 python python-pip python-dev python3-dev python3-pip libpng-dev libtiff5-dev libjpeg-dev tzdata sed curl unzip autoconf libtool rsync libxml2-dev git
  • Clang-8을 default로 설정한다.
# Set clang-8 as a default clang.
DOCKER# update-alternatives --install /usr/bin/clang++ clang++ /usr/lib/llvm-8/bin/clang++ 180 && update-alternatives --install /usr/bin/clang clang /usr/lib/llvm-8/bin/clang 180
  • Host machine의 python과 동일한 버전(3.8)을 docker에도 설치하고 관련된 Python package들을 pip로 설치해준다. 특별히 setuptools package는 버전의 영향을 받으므로 확인된 버전(47.3.1)을 명시해 준다.
DOCKER# apt install -y python3.8 python3.8-dev

# PIP upgrade
DOCKER# pip3 install --upgrade pip && pip install --upgrade pip

# 중요. Python3의 setuptools version이 안맞으면 빌드에 실패할 수 있으니 버전명을 명시해 준다.
DOCKER# pip2 install setuptools &&
pip3 install -Iv setuptools==47.3.1 &&
pip2 install distro &&
pip3 install distro &&
pip2 install wheel &&
pip3 install wheel auditwheel
  • 이제 해당 버전으로 docker에서 build를 시도 한다.
DOCKER# cd /carla
DOCKER# make PythonAPI ARGS="--python-version=3.8"
  • /carla/PythonAPI/carla/dist 아래에 소스에 포함되어 있는 3.6용 package외에 새롭게 빌드한 3.8용 *.whl, *.egg file들이 생성된 것을 확인하고 host system에 설치해 준다.
DOCKER# ls /carla/PythonAPI/carla/dist/
carla-0.9.13-cp36-cp36m-linux_x86_64.whl  carla-0.9.13-py3.6-linux-x86_64.egg
carla-0.9.13-cp38-cp38m-linux_x86_64.whl  carla-0.9.13-py3.8-linux-x86_64.egg

# CARLA client 설치
$ sudo apt install -y <carla-root-path>/PythonAPI/carla/dist/carla-0.9.13-py3.8-linux-x86_64.egg

Docker로 OpenGrok 설치

잘 쓰고 있던 OpenGrok 서버가 갑자기 맛이 가는 바람에 부랴부랴 대안을 찾아야 했는데 마땅한 서버가 없어서 로컬 머신에 Docker로 설치하는 방법을 찾아 보았다. 여기 소개된 내용은 Docker Hub에서 자세한 설명을 찾을 수 있다.

Docker가 설치되어 있다면 command창에서 다음의 명령으로 OpenGrok docker를 pull한다.

docker pull opengrok/docker

Pulling이 끝나면 목적에 소스와 indexing결과가 저장될 공간을 만들어 준다. src에는 분석할 소스를 넣고 bin에는 편의를 위한 스크립트를 넣을 예정이다.

mkdir -p ~/opengrok/bin
mkdir -p ~/opengrok/src
mkdir -p ~/opengrok/etc
mkdir -p ~/opengrok/data

이제, 8080 port에 접속 설정을 하고 위에서 만든 volume들을 docker에 마운트 시켜준다. Git server에 접근하기 위해 키 관련 설정을 해주어야 하는데, 귀찮아서 그냥 .ssh 디렉토리를 마운트 시켜 주었다.

docker run -d \
    --name opengrok \
    -p 8080:8080/tcp \
    -v ~/opengrok/bin/:/opengrok/bin/ \
    -v ~/opengrok/src/:/opengrok/src/ \
    -v ~/opengrok/etc/:/opengrok/etc/ \
    -v ~/opengrok/data/:/opengrok/data/ \
    -v ~/.ssh:/root/.ssh \
    opengrok/docker:latest

이제 해당 서버의 콘솔을 열고 인덱싱 명령을 수행하면 된다. GUI가 없다면 다음의 명령으로 실행 중인 docker에 접속할 수 있다.

docker exec -it <docker_container_id> bash

서버에 접속한 후 인덱싱을 수행하는 명령어는 다음과 같다.

export OPENGROK_DIR=/opengrok
java \
    -Djava.util.logging.config.file=$OPENGROK_DIR/etc/logging.properties \
    -Xmx1024m \
    -jar $OPENGROK_DIR/lib/opengrok.jar \
    -c /usr/local/bin/ctags \
    -s $OPENGROK_DIR/src -d $OPENGROK_DIR/data -H -P -S -G \
    -W $OPENGROK_DIR/etc/configuration.xml -U http://localhost:8080/

인덱싱이 끝나면 웹브라우져에서 http://localhost:8080으로 접속하면 된다.

위의 인덱싱 명령어가 너무 길어서 입력하기 힘들기 때문에 source code를 업데이트하고 인덱싱 하는 과정을 묶어서 다음과 같이 스크립트로 만들고 ~/opengrok/bin 안에 넣어 두면 편리하게 사용할 수 있다.

Linux에서 메모리 포인터의 유효성 검증

Windows에서와 달리 Linux환경에서는 딱히 포인터의 유효성을 검증할 수 있는 system call이 없다. 이 포스팅은 Linux환경에서 이와 유사한 기능을 구현하기 위해 “정보의 바다”에서 찾은 내용들을 정리해 둔 것이다.

1. _etext를 이용하는 방법

첫번째 방법은 Define and use a pointer validation function 이라는 위키문서에서 가져온 것인데 컴파일러가 생성하는 text 영역의 시작점을 이용해서 포인터 값이 이를 침범 하는지 여부를 검사하고 유효성을 판단한다. 하지만 위 링크의 커멘트에도 나와 있듯이 시스템에 따라 동작하지 않을 수도 있으므로 reliable 한 구현이라 볼 수는 없다.

bool isValidPointer_ET(void *ptr) {
    extern const char _etext;
    return (ptr != nullptr) && ((const char*)ptr > &_etext);
}

2. msync()를 이용하는 방법

Checking whether a pointer is valid in Linux라는 블로그 포스트에 소개된 방법으로 매핑된 메모리 공간을 동기화 할 때 쓰는 msync() 시스템 콜을 호출 하면서 유효하지 않은 page 시작 주소를 넘겨 주면 0이 아닌 음수 값을 반환하는 것을 이용하는 방법이다. (이 경우 errno에 ENOMEM이 설정된다)

#include <sys/mman.h>
#include <unistd.h>

bool isValidPointer_MS(void *ptr) {
    const size_t pageSize = sysconf(_SC_PAGESIZE);
    void *basePtr = (void *)((((size_t)ptr) / pageSize) * pageSize);
    return msync(basePtr, pageSize, MS_SYNC) == 0;
}

3. mincore()를 이용하는 방법

Stackoverflow에 올려진 Testing pointers for validity (C/C++)라는 질문에 대한 답변에 있는 아이디어 중 하나인데 메모리 페이지의 swap 상태를 확인해서 반환해 주는 mincore()을 이용하는 방법이다. 해당 답변에는 다른 아이디어 들도 있으니 필요에 따라 참고.

#include <sys/mman.h>
#include <unistd.h>

bool isValidPointer_MC(void *ptr) {
    unsigned char vec = 0;
    const size_t pageSize = sysconf(_SC_PAGESIZE);
    void *basePtr = (void *)((((size_t)ptr) / pageSize) * pageSize);
    int ret = mincore(basePtr, pageSize, &vec);
    return (ret == 0 && ((vec & 0x1) == 0x1));
}

시험 결과와 결론

위의 함수들에 대해 Linux환경에서 전역 변수 포인터, 지역 변수 포인터, 널 포인터, 널 포인터는 아니지만 명백하게 무효한 포인터(0x04 같은), 동적 할당된 공간에 대한 유효성 여부는 잘 동작한다.

하지만, 이미 해제된 포인터나 할당되지 않은 heap 공간 내의 임의 주소에 대해서는 제대로 유효성 여부를 판단하지 못하고, 주소 범위가 유효 하다면 포인터 역시 유효 하다고 판단하는 오류가 세가지 구현 모두에 있다.

    // 해제된 heap공간에 대한 유효성 여부 확인. 모두 실패함.
    unsigned int* dynamicVar = new unsigned int[100];
    delete[] dynamicVar;
    EXPECT_FALSE(isValidPointer_ET(dynamicVar));
    EXPECT_FALSE(isValidPointer_MS(dynamicVar));
    EXPECT_FALSE(isValidPointer_MC(dynamicVar));


    // 할당 되지 않은 Heap공간 내의 임의 포인터에 대한 유효성 확인. 모두 실패함.
    unsigned int* dynamicUnallocVar = dynamicVar + 100;
    EXPECT_FALSE(isValidPointer_ET(dynamicUnallocVar));
    EXPECT_FALSE(isValidPointer_MS(dynamicUnallocVar));
    EXPECT_FALSE(isValidPointer_MC(dynamicUnallocVar)); 

즉, 위의 구현 들은 주어진 포인터가 유효한 메모리 공간내에 속하는지는 확인할 수 있어도, 동적 할당 영역의 메모리 포인터가 실제 read/write 가능한 상태인지 여부는 정확히 반환 할 수 없다.

시험에 사용한 code는 여기에 붙여 둔다.

Lightsail Ubuntu 20.04 업그레이드 후 ssh 접속 불가 현상

Lightsail의 이미지를 Ubuntu 20.04 LTS로 업그레이드 한 후 web 환경에서 SSH 접속이 되지 않아서 또 망했다며 머리를 쥐어 뜯고 있는데, 우연히, 당연히 안 될 거라고 생각했던 터미널 프로그램을 통한 SSH 접속은 또 되는 기현상을 발견했다. 이 대로도 나쁘진 않지만 좀 찜찜 하기도 하고 해서 좀 더 찾아 보았다.

접속 오류가 발생할 때의 로그를 보면 다음과 같은데,

$ cat /var/log/auth.log|tail
...
sshd[4528]: userauth_pubkey: certificate signature algorithm ssh-rsa: signature algorithm not supported [preauth]
...

이 문제의 해결책에 대해 아주 자세히 설명된 Use RSA CA Certificates with OpenSSH 8.2에 따르면, (Ubuntu 20.04에 포함된) OpenSSH 8.2 부터는 보안 문제로 SHA-1 기반인 ssh-rsa가 기본 CA signature 항목에서 빠지면서 이러한 문제가 발생하게 된다고 한다. 해결 방법은 CASignatureAlgorithms에 ssh-rsa를 지원하도록 명시하는 것이다.

$ cat /etc/ssh/sshd_config|tail
...
# Use RSA CA cert.
# https://ibug.io/blog/2020/04/ssh-8.2-rsa-ca/
CASignatureAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

위의 링크에서 제안하는 대로 sshd_config 파일에 CASignatureAlgorithms 항목을 위와 같이 추가 하고 sshd service를 재 실행 하고나니, web 환경 SSH가 잘 동작하게 되었다. 물론, 터미널도 그대로 잘 된다.

GCC에서 integer arithmetic overflow 방지 대책

Arithmetic overflow는 부호 있는 변수(signed variable)가 표시 할 수 있는 최댓값 / 최솟값을 넘어 섰을 때 부호가 바뀌면서 원하지 않는 결과가 나타나는 경우를 말한다.

#include <iostream>
#include <climits>

using namespace std;
int main(void) {
    int r = 0;
    int op = INT_MAX;
    cout << op << " + 1 = " << op + 1 << endl;
    return 0;
}

위의 코드를 다음과 같이 컴파일하고 실행하면 overflow가 발생한다.

$ g++ ./overflow.cpp
$ ./a.out
2147483647 + 1 = -2147483648

이와 같은 경우를 방지 하려면 물론 꼼꼼한 코드 리뷰도 중요 하지겠만 컴파일러에서 제공하는 overflow를 점검하는 빌트인 함수를 사용하거나 Safeint 혹은 이와 유사한 Boost의 Safe numerics의 사용을 고려해 볼 수도 있겠다. 하지만 이 방법들은 처음부터 사용이 고려되어야 하거나 이미 작성한 코드를 수정해야 하는 단점이 있다.

-ftrapv compiler switch

GCC 컴파일러에서 제공하는 -ftrapv switch를 사용하면 코드 수정 없이 arithmetic overflow가 발생 했을 때 SIGABRT를 발생 시키도록 컴파일러가 trap을 추가하게 할 수 있는데, 발견 되지 않은 overflow를 일으킨 후 오동작을 하게 되는 것 보다는 프로세스 중단이 낫다고 생각하면 이 switch를 고려해 볼 수 있다.

$ g++ -ftrapv ./overflow.cpp
$ ./a.out
Aborted (core dumped)

-fwrapv compiler switch

또 다른 경우로 최적화 옵션에 따라 실행 결과가 달라 지는 경우도 있다. 다음의 예제는 Stack overflow의 What does -fwrapv do?를 약간 변형한 것이다.

#include <iostream>
#include <climits>
 
using namespace std;
int optFunc(int i) {
    return i+1 > i;
}
 
int main(void) {
    int v = INT_MAX;
 
    if (optFunc(v)) {
        cout << "Unexpected." << endl;
    } else {
        cout << "Terminated OK." << endl;
    }
	
    return 0;
}

현실에서 쓰일 법한 코드는 아니지만 optFunc()를 작성한 사람의 의도가 INT_MAX가 인자로 주어질 때 “INT_MAX + 1“이 음수가 되면서 “INT_MAX + 1 > INT_MAX”가 false(0)를 반환하도록 하는 것이었다 하더라도 이 코드는 최적화 옵션에 따라 다른 결과 값을 내게 된다.

디버깅 등의 이유로 컴파일 할 때 최적화를 옵션을 -O0로 주면 원하는 대로 동작한다.

$ g++ -O0 ./fwrapv.cpp
$ ./a.out 
Terminated OK.

하지만, -O3 옵션을 주면, 컴파일러는 optFunc()가 항상 true(1)을 반환 할 것이라 가정하고 컴파일러가 이를 최적화 시켜 버려서 코드가 의도한 대로 동작하지 않게 된다.

$ g++ -O3 ./fwrapv.cpp
$ ./a.out 
Unexpected.

이러한 경우를 방지 하기 위해 -fwrapv switch를 주면 -O3 이상의 최적화 옵션에서도 해당 부분이 ‘wrapping’ 되어서 의도한 대로 코드가 동작하게 된다.

$ g++ -O3 -fwrapv ./fwrapv.cpp
$ ./a.out 
Terminated OK.

-Wconversion compiler switch

보다 쉬운 경우로, 표현 범위가 큰 타입에서 작은 타입으로 변환 될 때 값을 잃어 버려서 원하지 않는 결과가 생길 수도 있는데, 이 경우는 -Wconversion switch를 추가하면 컴파일시간에 잡아내서 경고를 출력하도록 할 수 있다. 예를 들어 64bit 시스템에서 unsigned long type인 size_t를 실수로 unsigned int에 할당한 것과 같은 경우들을 컴파일 시간에 찾아 경고를 출력해 주는데 -Weror와 함께 사용하면 컴파일이 멈추게 된다.

결론

코딩의 처음부터 안전한 연산을 고려 한다면 이를 지원하기 위한 라이브러리들을 고려해 볼 수 있겠지만, 컴파일러 스위치를 활용하여 arithmetic integer overflow 발생에 대한 대비를 할 수도 있다.

* 위의 예제들은 Ubuntu 18.04에서 g++ 7.5.0으로 시험 되었다.
** 위의 fwrapv 예제에 -fwrapv와 -ftrapv switch를 모두 사용하면 -fwrapv로 동작한다.