지돌이의 블로그 입니다!

github를 사칭한 피싱메일도 오네요..

 

실제 제가 github에서 사용하고 있는 메일 주소로 아래와 같은 메일이 왔습니다.

 

디자인이 깔끔해서 진짜같네요...ㅎㅎ

 

링크를 클릭하면 두번째 사진 페이지로 갑니다.

 

그런데 아무렇게나 입력하면 비밀번호가 틀렸다고 나오네요.. 보통 피싱사이트를 보면 무조건 맞다고 하거나 진짜 페이지로 니동시키는데 그러진 않습니다.

 

실제로 정보를 확인하는 것 일수도요..

 

암튼 이젠 계장탈취 뿐 아니라 소스까지 탐을 내나 봅니다.. 깃허브 피싱이라니.. 다들 조심하시길 바랍니다.

 

Comment +0

WIMCreateFile에는 CreateFile와는 달리 dwShareMode옵션이 없다.

 

이를 사용할 수 있는지 확인해 보기 위해 분석을 시도한다.

 

volatile const void* p_WIMCreateFile = WIMCreateFile;
const void* p_CreateFileW = CreateFileW;
HANDLE hTemp = CreateFileW(_T("E:\\ISO\\boot.wim"), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
CloseHandle(hTemp);
HANDLE hWim = WIMCreateFile(_T("E:\\ISO\\boot.wim"), WIM_GENERIC_READ, WIM_OPEN_EXISTING, 0, 0, 0);
printf("hWim = %p\n", hWim);

 

일단 위 코드를 실행하고 VisualStudio Debug Window중에 디스어셈블창을 열어서 CreateFile의 구현에 브레이크를 건다.

 

[사진1] _CreateFileW@28에 브레이크가 걸린 모습

CreateFileW의 구조는 아래와 같다.

HANDLE CreateFileW(
  LPCWSTR               lpFileName,
  DWORD                 dwDesiredAccess,
  DWORD                 dwShareMode,
  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  DWORD                 dwCreationDisposition,
  DWORD                 dwFlagsAndAttributes,
  HANDLE                hTemplateFile
);

WIMFileCreateFile에서 _CreateFileW@28을 호출하는 부분을 보면..

[사진2] WIMFileCreateFile함수내에서 _CreateFileW@28 호출하는 부분

dwShareMode에 단순히 0이 아니라 *(ebp+8)의 값을 넣는것을 볼 수 있다. 희망이 있다!

 

[사진3] (사진2)에서 dwShareMode의 값

근데 값을 보면 이미 FILE_SHARE_READ 가 있다... 근데 왜 CreateFile으로 열고 있으면 WIMCreateFile이 안되었던 거지??? 뭔가 잘못했었나 보다...ㅠㅠ

 

아쉬우니 좀더 뒤져보면...

 

v7 = GetWimDesiredAccess(v3) & 0x40000000 /* GENERIC_WRITE */;
v20 = (v7 == 0) ? FILE_SHARE_READ : 0;
if ( GetFlagsAndAttributes(v3) & 0x40 /* FILE_ATTRIBUTE_DEVICE */)
  dwShareMode = 3; // FILE_SHARE_READ | FILE_SHARE_WRITE
else
  dwShareMode = v20;

결국...
GENERIC_WRITE가 없으면 FILE_SHARE_READ를 자동으로 넣는다.

 

끝.

Comment +0

Kubernetes Offline 사용

개요

Kubernetes(이하 K8s)를 인터넷과 연결되지 않은 상태(이하 Offline 상태)에서 정상적으로 동작시킬 수 있도록 한다. K8s는 기본적으로 Docker Image를 인터넷 상에 있는 Docker Registry에서 받아오게 된다. 잘 알려진 Docker Registry는 docker.io, quay.io, k8s.gcr.io 등이 있다. Offline 상태에서는 Docker Image를 Online에 있는 Docker Registry에서 받아올 수 없기 때문에 필요한 이미지를 Offline상에 가지고 있어야 한다. 이를 위해 필요한 사항들을 정리한다.

고려해야 할 부분들

1. K8s 설치

여기서는 K8s 설치를 microk8s를 통한 설치를 사용한다. Ubuntu에서 microk8s는 snap으로 설치할 수 있다. snap은 어플리케이션을 패키징화 하는 것으로 추가적인 dependency없이 즉시 설치 가능하게 한다. microk8s을 오프라인 설치하기 위해 snap을 미리 다운받아야 한다.

2. K8s 내부 동작

K8s는 Pod의 Container를 동작시키기 위한 Docker Image뿐만 아니라 sandbox image 가 필요하다. 이에 대해서는 159. [Kubernetes] Pause 컨테이너의 역할과 원리 (원문: The Almighty Pause Container) 을 참고하길 바란다. 간단히 설명하면 sandbox container는 Pod의 부모 컨테이너로써 하나의 Pod의 Container들을 관리하고 동일한 namespace를 공유할 수 있게 해 주는 K8s의 필수적인 컨테이너이다.

sandbox image 의 위치는 /var/snap/microk8s/current/args/containerd.toml/var/snap/microk8s/current/args/containerd-template.toml 에서 plugins -> plugins.cri -> sandbox_image 에서 위치를 지정할 수 있다. 기본 위치는 k8s.gcr.io/pause:3.1 이다.

(해당 containerd argument는 clustered 서버 구성에서도 자기 자신의 node에만 적용된다.)

Offline 상태에서 K8s을 동작시키기 위해서는 해당 이미지 또한 Offline 상에 저장되어 있어야 한다.

3. Helm

$ microk8s.enable helm 명령을 통해 helm을 쉽게 설치할 수 있다. microk8s.enable 명령은 내부적으로 /snap/microk8s/current/actions/enable.helm.sh을 실행시킨다. 해당 파일은 https://get.helm.sh/helm-$HELM_VERSION-linux-$(arch).tar.gz 을 다운받아 실행한다. 하지만 Offline인 경우에 해당 파일을 다운받을 수 없을 것이다. 따라서 microk8s에 helm을 설치하려면 이를 미리 다운받아 놓아야 한다.

뿐만 아니라 helm을 설치하는 과정에서 _tiller_이미지를 Online에서 다운받게 된다.

4. 사용자가 구성하는 Docker Image

microk8s에서는 microk8s.enable 명령을 통해 local registry를 설치할 수 있다. 이렇게 설치한 local registry의 주소에서 Docker Image를 가져오게 하면 문제되지 않는다.

고려해야 할 것들 총정리...

  1. microk8s 설치
  2. sandbox image (pause 이미지)
  3. microk8s.enable시 사용되는 shell script & helm & tiller
  4. 사용자 docker image들

오프라인 설치 방법

1. microk8s 설치

snap을 오프라인으로 설치하는 방법은 아래와 같다.

Online 상태의 Ubuntu Machine에서 패키지 다운로드

$ snap download microk8s
# 이후 microk8s_xxxx.snap, microk8s_xxxx.assert 두개의 파일이 생성된다.

Offline 상태의 Ubuntu Machine에서 패키지 설치

$ sudo snap ack microk8s_xxxx.assert
$ sudo snap install microk8s_xxxx.snap --classic

2.1. Docker Image

k8s 노드가 한개일 경우에는 야매로 containerd에 이미지를 저장시켜 놓을 수 있다. 그런데 containerd v1.2.x 버전(v1.3.x 이전)에서는 image export/import에 버그(#2862 참고)가 있다... 일단 기본적으로..

$ sudo microk8s.ctr image pull k8s.gcr.io/pause:3.1
k8s.gcr.io/pause:3.1:                                                             resolved
...
elapsed: 2.2 s                                                                    total:  3.7 Ki (1.7 KiB/s)
unpacking linux/amd64 sha256:f78411e19d84a252e53bff71a4407a5686c46983a2c2eeed83929b888179acea...
done

$ sudo microk8s.ctr image export pause.tar k8s.gcr.io/pause:3.1
ctr: export failed: content digest sha256:c84b0a3a07b628bc4d62e5047d0f8dff80f7c00979e1e28a821a033ecda8fe53: not found (헐?)

이렇게 오류가 나는데 이를 해결하기 위해서는 image pull 에 --all-platforms 옵션을 줘서 모든 platform (i386/arm64/arm/arm64/ppc... * linux/windows)의 이미지를 한번에 받아야 하는데 그러면 이미지 크기가 어머어마 하다... 여러 Platform에서 k8s을 동작시킨다면 --all-platforms이 필요하겠지만 그렇지 않다면 특정 platform만 export할 수 있어야 하는데 그럴려면 containerd 1.3.x 을 사용해야 한다.

$ sudo apt install containerd

ubuntu 18.04에서는 기본적으로 apt-get으로 containerd를 설치하면 1.3.3 버전이 설치된다.

$ sudo ctr -a /var/snap/microk8s/common/run/containerd.sock image pull k8s.gcr.io/pause:3.1
$ sudo ctr -a /var/snap/microk8s/common/run/containerd.sock image export --platform linux/amd64 pause.tar k8s.gcr.io/pause:3.1

이렇게 하면 linux/amd64용으로 pause이미지가 export된다.

$ sudo ctr -a /var/snap/microk8s/common/run/containerd.sock image import --base-name k8s.gcr.io/pause pause.tar

이렇게 임포트!

2.2. Docker Registry 사용하기

하지만 위 방법은 노드가 2개 이상이면 골치아파 진다. 모든 노드에 이미지를 저장시켜놓아야 하기 때문이다. 따라서 registry를 구축해놓고 해당 registry에 필요한 이미지들을 모아놓는 것이 좋다.

microk8s에는 local registry을 간편하게 설치할 수 있다. microk8s.enable registry 하면 끝이다! 하지만 여기에는 큰 문제가 하나 있다...

  1. 닭이 먼저냐 달걀이 먼저냐...

    local registry를 돌릴려면 pause 이미지와 registry 이미지가 필요하다.. 근데 이건 어디서 받아오냐...? 클러스터링해서 ceph을 쓰려면 ceph이미지도 필요한데 ceph이미지는 또 어디서 받아오고...?
    물론.. hostPath를 이용한다면 pause이미지와 registry이미지만 먼저 containerd에다가 저장시켜놓고 해당 노드 주소를 이용해서 registry를 이용하면 된다.

  2. 그런데 해당 노드가 죽으면...? 클러스터의 중요한 장점인 HA(고가용성)이 떨어진다..

  3. 근데 또... ctr에 버그가 있어...ㅠㅠ 이어서 설명함..

  4. 그러고 보니 docker 리포 주소를 다 바꾸는 수고가 엄청난데...? 이것도 이어서...

(3. ctr에 버그가 있어... - 1)

일단 registry만 Kubernetes밖에 저장한다 치고, 위에서 export한 도커 이미지를 registry에 다시 부어야 한다.

한가지 예시이다.

$ ctr -a /var/snap/microk8s/common/run/containerd.sock image push 127.0.0.1:32000/quay.io/cephcsi/cephcsi:v1.2.2 quay.io/cephcsi/cephcsi:v1.2.2
...
elapsed: 2.3 s                                                                    total:  302.8  (131.6 MiB/s)
ctr: failed commit on ref "manifest-sha256:fd16e128b5831a4c73e57181b890445c4eb73726f5210ebc8e408855f99912dd": unexpected status: 400 Bad Request

이건 뭘까... (모든 이미지가 위 오류가 나진 않는다. 잘 되는 이미지만 테스트 해보고 offline지역으로 이동해서 이런 이미지를 push 하려고 하면 대략난감... => 물론 나는 이러한 대략난감을 경험했다.. 화가난다.. containerd가 미워진다.. 근데 containerd만큼 잘 만든것도 없고 containerd를 안쓰면 k8s못쓴다..ㅎㅎ)

위 tar 파일을 풀어보면 index.json이 나오는데 manifest파일의 mediaType이 application/vnd.oci.image.manifest.v1+json 인것들이 그렇다. 일단... v2에 맞게 일일히 수정해주면 되긴 하는데.. 노가다이다. (난 nodejs로 짜서 변환했는데... 그래도 이건 아니다 싶었다.. v2.list로 바꾸고 리스트 파일 만들고 blobs에 hash이름으로 추가하고 이렇고 저렇고... ㅠㅠv2.list로 바꾸고 리스트 파일 만들고 blobs에 hash이름으로 추가하고 이렇고 저렇고...ㅠㅠ)

근데 나중에 알아서 이 방법을 썼는데...

$ sudo docker image load < cephcsi_v1.2.0.tar
$ sudo docker tag quay.io/cephcsi/cephcsi:v1.2.0 127.0.0.1:32000/cephcsi/cephcsi:v1.2.0
$ sudo docker push 127.0.0.1:32000/cephcsi/cephcsi:v1.2.0

이렇게 하면 된다... (모든 이미지가 이 방법이 먹히는건 아니다.. 휴...)

(3. ctr에 버그가 있어... - 2)

multi-platform 이미지를 자기 platform 것만 pull받은 경우 push가 되지 않는다. (export -> import 또는 pull) -> push 과정이 안되는 것이다.

#3915 PR에서 해결된거 같은데.. master에 merge되고 아직 release는 안된듯...ㅠㅠ

이건 우째야 할지 모르겠다... 하지만 위 방법처럼 그냥 docker를 통해서는 되는거 같다.

(4. 그러고 보니 docker 리포 주소를 다 바꾸는 수고가 엄청난데...?)

그렇다... 일단 다시 containerd.toml 파일을 보면 중간이 이런 부분이 있다.

    [plugins.cri.registry]
      [plugins.cri.registry.mirrors]
        [plugins.cri.registry.mirrors."docker.io"]
          endpoint = ["https://registry-1.docker.io"]
        [plugins.cri.registry.mirrors."localhost:32000"]
          endpoint = ["http://localhost:32000"]

registry 주소를 override할 수 있는 부분인데 유용하게 사용할 수 있다.

예를 들어 docker.io(docker hub)에 저장되는 이미지들을 로컬에서 받아오고 싶으면

    [plugins.cri.registry]
      [plugins.cri.registry.mirrors]
        [plugins.cri.registry.mirrors."docker.io"]
          endpoint = ["http://10.1.2.3:32000"]

이런식으로 하면 alpine:1.23.4 => 10.1.2.3:32000/library/alpine:1.23.4 에서 받아오게 된다. 이런식으로 override하면 image 를 일일히 바꿔주는 수고는 안해도 된다. (물론 node가 여러개면 여러개 각각 수정해줘야 한다...ㅠㅠ k8s전체 적용하는 방법 있음 알려주오...ㅠㅠ)

위에서 보았던 _sandbox_image_또한 local registry주소로 바꾸는걸 잊지 말길!

2.3. 더 좋은 방법 없을까?

thirdparty들을 쓰다 보면 quay.io, docker.io, k8s.gcr.io 등... 여러 registry를 쓰게 되며 이름이 중복될 가능성도 있고.. registry를 로컬에다 설치해야 하는데 registry들이 다 docker용으로 만들어져 있다...

기쁜 소식은 containerd.toml에서 [plugins.cri.registry.mirrors."*"] 이러한 문법이 동작한다는 것이다!

근데 그럼 뭐해.. 필요한 이미지를 로컬에다 저장하고 이미지를 검색하는 기능을 가진 서버가 없는데...

따라서 그건 내가 만들테니... 조금만 기다리길...ㅠㅠ

Comment +0

Ceph 설치 후 서버 동작중에 서버가 죽어버리는 문제가 발생했다.

 

어떤 상황이냐면...

 

1. 초기 동작시에는 문제가 없지만 IO가 좀 발생하면 문제가 발생함.

2. 문제 발생시 특정 동작에 hangs이 걸리고 아무것도 동작하지 않음 (Deadlock)

-> ps -aux 명령이 그러함.

ps aux 을 하면 프로세스 목록이 보이다가 곧 멈춰버리는데 보여줘야 할 프로세스 (마지막으로 보여지는 pid의 다음 것)에 문제가 있음.

cat /proc/(문제pid)/cmdline 등의 명령도 멈춰버림.

3. 시스템 정상종료 불가

-> unmonut 불가로 보임

 

커널 로그는 아래와 같다.

[ 5092.890984] libceph: osd2 up
[ 6646.588531] INFO: task containerd:18390 blocked for more than 120 seconds.
[ 6646.588868]       Tainted: G          I      4.15.0-91-generic #92-Ubuntu
[ 6646.589070] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6646.589294] containerd      D    0 18390      1 0x00000000
[ 6646.589297] Call Trace:
[ 6646.589306]  __schedule+0x24e/0x880
[ 6646.589311]  ? __memcg_init_list_lru_node+0x70/0xd0
[ 6646.589313]  schedule+0x2c/0x80
[ 6646.589316]  rwsem_down_write_failed+0x1ea/0x360
[ 6646.589319]  ? ida_get_new_above+0x110/0x320
[ 6646.589325]  call_rwsem_down_write_failed+0x17/0x30
[ 6646.589326]  ? call_rwsem_down_write_failed+0x17/0x30
[ 6646.589328]  down_write+0x2d/0x40
[ 6646.589332]  register_shrinker_prepared+0x19/0x50
[ 6646.589336]  sget_userns+0x419/0x490
[ 6646.589338]  ? get_anon_bdev+0x100/0x100
[ 6646.589340]  sget+0x7d/0xa0
[ 6646.589342]  ? get_anon_bdev+0x100/0x100
[ 6646.589346]  ? ovl_posix_acl_xattr_set+0x300/0x300 [overlay]
[ 6646.589348]  mount_nodev+0x30/0xa0
[ 6646.589351]  ovl_mount+0x18/0x20 [overlay]
[ 6646.589353]  mount_fs+0x37/0x160
[ 6646.589357]  vfs_kern_mount.part.24+0x5d/0x110
[ 6646.589359]  do_mount+0x5ed/0xce0
[ 6646.589361]  ? copy_mount_options+0x2c/0x220
[ 6646.589363]  SyS_mount+0x98/0xe0
[ 6646.589367]  do_syscall_64+0x73/0x130
[ 6646.589370]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 6646.589371] RIP: 0033:0x55635d40f28a
[ 6646.589372] RSP: 002b:000000c00186e358 EFLAGS: 00000216 ORIG_RAX: 00000000000000a5
[ 6646.589374] RAX: ffffffffffffffda RBX: 000000c00004e000 RCX: 000055635d40f28a
[ 6646.589375] RDX: 000000c0014d8818 RSI: 000000c002ef45a0 RDI: 000000c0014d8810
[ 6646.589376] RBP: 000000c00186e3f0 R08: 000000c0038e8b00 R09: 0000000000000000
[ 6646.589377] R10: 0000000000000000 R11: 0000000000000216 R12: ffffffffffffffff
[ 6646.589378] R13: 0000000000000010 R14: 000000000000000f R15: 0000000000000055
[ 6646.589400] INFO: task containerd:16952 blocked for more than 120 seconds.
[ 6646.589598]       Tainted: G          I      4.15.0-91-generic #92-Ubuntu
[ 6646.589790] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6646.590013] containerd      D    0 16952      1 0x00000000
[ 6646.590016] Call Trace:
[ 6646.590020]  __schedule+0x24e/0x880
[ 6646.590023]  ? __memcg_init_list_lru_node+0x70/0xd0
[ 6646.590025]  schedule+0x2c/0x80
[ 6646.590028]  rwsem_down_write_failed+0x1ea/0x360
[ 6646.590031]  ? ida_get_new_above+0x110/0x320
[ 6646.590035]  call_rwsem_down_write_failed+0x17/0x30
[ 6646.590037]  ? call_rwsem_down_write_failed+0x17/0x30
[ 6646.590040]  down_write+0x2d/0x40
[ 6646.590043]  register_shrinker_prepared+0x19/0x50
[ 6646.590046]  sget_userns+0x419/0x490
[ 6646.590048]  ? get_anon_bdev+0x100/0x100
[ 6646.590052]  sget+0x7d/0xa0
[ 6646.590054]  ? get_anon_bdev+0x100/0x100
[ 6646.590059]  ? ovl_posix_acl_xattr_set+0x300/0x300 [overlay]
[ 6646.590062]  mount_nodev+0x30/0xa0
[ 6646.590067]  ovl_mount+0x18/0x20 [overlay]
[ 6646.590070]  mount_fs+0x37/0x160
[ 6646.590073]  vfs_kern_mount.part.24+0x5d/0x110
[ 6646.590076]  do_mount+0x5ed/0xce0
[ 6646.590079]  ? copy_mount_options+0x2c/0x220
[ 6646.590082]  SyS_mount+0x98/0xe0
[ 6646.590085]  do_syscall_64+0x73/0x130
[ 6646.590088]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 6646.590090] RIP: 0033:0x55635d40f28a
[ 6646.590091] RSP: 002b:000000c0018725b0 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
[ 6646.590094] RAX: ffffffffffffffda RBX: 000000c000054f00 RCX: 000055635d40f28a
[ 6646.590095] RDX: 000000c0030c7ce8 RSI: 000000c00148bf60 RDI: 000000c0030c7ce0
[ 6646.590096] RBP: 000000c001872648 R08: 000000c00300f680 R09: 0000000000000000
[ 6646.590098] R10: 0000000000000000 R11: 0000000000000202 R12: ffffffffffffffff
[ 6646.590099] R13: 00000000000000fc R14: 00000000000000fb R15: 0000000000000100
[ 6646.590540] INFO: task xfsaild/rbd2:8223 blocked for more than 120 seconds.
[ 6646.590743]       Tainted: G          I      4.15.0-91-generic #92-Ubuntu
[ 6646.590939] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6646.591165] xfsaild/rbd2    D    0  8223      2 0x80000000
[ 6646.591168] Call Trace:
[ 6646.591171]  __schedule+0x24e/0x880
[ 6646.591175]  ? lock_timer_base+0x6b/0x90
[ 6646.591178]  schedule+0x2c/0x80
[ 6646.591245]  _xfs_log_force+0x159/0x2a0 [xfs]
[ 6646.591250]  ? wake_up_q+0x80/0x80
[ 6646.591301]  ? xfsaild+0x1b6/0x7e0 [xfs]
[ 6646.591350]  xfs_log_force+0x2c/0x80 [xfs]
[ 6646.591400]  xfsaild+0x1b6/0x7e0 [xfs]
[ 6646.591404]  ? __schedule+0x256/0x880
[ 6646.591408]  kthread+0x121/0x140
[ 6646.591458]  ? xfs_trans_ail_cursor_first+0x90/0x90 [xfs]
[ 6646.591460]  ? kthread+0x121/0x140
[ 6646.591510]  ? xfs_trans_ail_cursor_first+0x90/0x90 [xfs]
[ 6646.591513]  ? kthread_create_worker_on_cpu+0x70/0x70
[ 6646.591517]  ret_from_fork+0x35/0x40
[ 6646.591539] INFO: task prometheus:10749 blocked for more than 120 seconds.
[ 6646.591740]       Tainted: G          I      4.15.0-91-generic #92-Ubuntu
[ 6646.591936] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6646.592162] prometheus      D    0 10749  10332 0x00000000
[ 6646.592164] Call Trace:
[ 6646.592168]  __schedule+0x24e/0x880
[ 6646.592171]  schedule+0x2c/0x80
[ 6646.592173]  io_schedule+0x16/0x40
[ 6646.592176]  wait_on_page_bit+0xf4/0x130
[ 6646.592182]  ? page_cache_tree_insert+0xe0/0xe0
[ 6646.592186]  wait_for_stable_page+0x61/0x80
[ 6646.592188]  grab_cache_page_write_begin+0x37/0x40
[ 6646.592192]  iomap_write_begin.constprop.18+0x5b/0x140
[ 6646.592195]  iomap_write_actor+0x92/0x170
[ 6646.592198]  ? iomap_write_begin.constprop.18+0x140/0x140
[ 6646.592200]  iomap_apply+0xa5/0x120
[ 6646.592203]  ? iomap_write_begin.constprop.18+0x140/0x140
[ 6646.592205]  iomap_file_buffered_write+0x6e/0xa0
[ 6646.592207]  ? iomap_write_begin.constprop.18+0x140/0x140
[ 6646.592256]  xfs_file_buffered_aio_write+0xca/0x290 [xfs]
[ 6646.592261]  ? sock_read_iter+0x8f/0xf0
[ 6646.592309]  xfs_file_write_iter+0xac/0x160 [xfs]
[ 6646.592347]  new_sync_write+0xe7/0x140
[ 6646.592350]  __vfs_write+0x29/0x40
[ 6646.592353]  vfs_write+0xb1/0x1a0
[ 6646.592355]  SyS_write+0x5c/0xe0
[ 6646.592359]  do_syscall_64+0x73/0x130
[ 6646.592363]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 6646.592365] RIP: 0033:0x47a170
[ 6646.592366] RSP: 002b:000000c006545278 EFLAGS: 00000212 ORIG_RAX: 0000000000000001
[ 6646.592369] RAX: ffffffffffffffda RBX: 000000c00004a000 RCX: 000000000047a170
[ 6646.592370] RDX: 000000000000023f RSI: 000000c000b4b88b RDI: 0000000000000026
[ 6646.592372] RBP: 000000c0065452c8 R08: 0000000000000000 R09: 0000000000000000
[ 6646.592373] R10: 0000000000000000 R11: 0000000000000212 R12: 000000000000477e
[ 6646.592374] R13: 000000000000387b R14: 0000000000004785 R15: 000000c000b4b88b
[ 6646.592397] INFO: task WTJourn.Flusher:13661 blocked for more than 120 seconds.
[ 6646.592611]       Tainted: G          I      4.15.0-91-generic #92-Ubuntu
[ 6646.592812] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6646.593038] WTJourn.Flusher D    0 13661  11503 0x00000000
[ 6646.593040] Call Trace:
[ 6646.593044]  __schedule+0x24e/0x880
[ 6646.593045]  schedule+0x2c/0x80
[ 6646.593048]  io_schedule+0x16/0x40
[ 6646.593049]  wait_on_page_bit_common+0xd8/0x160
[ 6646.593053]  ? page_cache_tree_insert+0xe0/0xe0
[ 6646.593055]  __filemap_fdatawait_range+0xfa/0x160
[ 6646.593057]  ? __filemap_fdatawrite_range+0xcf/0x100
[ 6646.593060]  ? __filemap_fdatawrite_range+0xdb/0x100
[ 6646.593062]  file_write_and_wait_range+0x86/0xb0
[ 6646.593094]  xfs_file_fsync+0x5f/0x230 [xfs]
[ 6646.593100]  vfs_fsync_range+0x51/0xb0
[ 6646.593104]  do_fsync+0x3d/0x70
[ 6646.593107]  SyS_fdatasync+0x13/0x20
[ 6646.593109]  do_syscall_64+0x73/0x130
[ 6646.593112]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 6646.593113] RIP: 0033:0x7fe3337432e7
[ 6646.593114] RSP: 002b:00007fe32c6c2400 EFLAGS: 00000293 ORIG_RAX: 000000000000004b
[ 6646.593116] RAX: ffffffffffffffda RBX: 0000000000000011 RCX: 00007fe3337432e7
[ 6646.593117] RDX: 0000000000000000 RSI: 0000000000000011 RDI: 0000000000000011
[ 6646.593118] RBP: 00007fe32c6c2440 R08: 0000000000000000 R09: 0000000000000000
[ 6646.593119] R10: 0000000000000020 R11: 0000000000000293 R12: 0000560acb599f40
[ 6646.593120] R13: 0000560ac884130b R14: 0000000000000000 R15: 0000560acdf52158
[ 6646.593235] INFO: task xfsaild/rbd13:20644 blocked for more than 120 seconds.
[ 6646.593444]       Tainted: G          I      4.15.0-91-generic #92-Ubuntu
[ 6646.593640] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6646.593975] xfsaild/rbd13   D    0 20644      2 0x80000000
[ 6646.593978] Call Trace:
[ 6646.593981]  __schedule+0x24e/0x880
[ 6646.593983]  ? lock_timer_base+0x6b/0x90
[ 6646.593986]  schedule+0x2c/0x80
[ 6646.594020]  _xfs_log_force+0x159/0x2a0 [xfs]
[ 6646.594023]  ? wake_up_q+0x80/0x80
[ 6646.594055]  ? xfsaild+0x1b6/0x7e0 [xfs]
[ 6646.594087]  xfs_log_force+0x2c/0x80 [xfs]
[ 6646.594120]  xfsaild+0x1b6/0x7e0 [xfs]
[ 6646.594123]  kthread+0x121/0x140
[ 6646.594155]  ? xfs_trans_ail_cursor_first+0x90/0x90 [xfs]
[ 6646.594157]  ? kthread+0x121/0x140
[ 6646.594189]  ? xfs_trans_ail_cursor_first+0x90/0x90 [xfs]
[ 6646.594192]  ? kthread_create_worker_on_cpu+0x70/0x70
[ 6646.594195]  ret_from_fork+0x35/0x40
[ 6646.594233] INFO: task mongod:28103 blocked for more than 120 seconds.
[ 6646.594423]       Tainted: G          I      4.15.0-91-generic #92-Ubuntu
[ 6646.594616] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6646.594839] mongod          D    0 28103  27425 0x00000000
[ 6646.594841] Call Trace:
[ 6646.594843]  __schedule+0x24e/0x880
[ 6646.594845]  schedule+0x2c/0x80
[ 6646.594847]  io_schedule+0x16/0x40
[ 6646.594848]  wait_on_page_bit+0xf4/0x130
[ 6646.594851]  ? page_cache_tree_insert+0xe0/0xe0
[ 6646.594853]  wait_for_stable_page+0x61/0x80
[ 6646.594855]  grab_cache_page_write_begin+0x37/0x40
[ 6646.594856]  iomap_write_begin.constprop.18+0x5b/0x140
[ 6646.594858]  iomap_write_actor+0x92/0x170
[ 6646.594860]  ? iomap_write_begin.constprop.18+0x140/0x140
[ 6646.594862]  iomap_apply+0xa5/0x120
[ 6646.594864]  ? iomap_write_begin.constprop.18+0x140/0x140
[ 6646.594865]  iomap_file_buffered_write+0x6e/0xa0
[ 6646.594866]  ? iomap_write_begin.constprop.18+0x140/0x140
[ 6646.594898]  xfs_file_buffered_aio_write+0xca/0x290 [xfs]
[ 6646.594931]  xfs_file_write_iter+0xac/0x160 [xfs]
[ 6646.594933]  new_sync_write+0xe7/0x140
[ 6646.594935]  __vfs_write+0x29/0x40
[ 6646.594937]  vfs_write+0xb1/0x1a0
[ 6646.594940]  SyS_pwrite64+0x95/0xb0
[ 6646.594942]  do_syscall_64+0x73/0x130
[ 6646.594945]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 6646.594946] RIP: 0033:0x7f9b8d65e963
[ 6646.594947] RSP: 002b:00007f9b8b2a9970 EFLAGS: 00000293 ORIG_RAX: 0000000000000012
[ 6646.594949] RAX: ffffffffffffffda RBX: 0000000000000100 RCX: 00007f9b8d65e963
[ 6646.594949] RDX: 0000000000000100 RSI: 000055e0a90fd000 RDI: 000000000000000f
[ 6646.594950] RBP: 00007f9b8b2a99c0 R08: 000055e0a90fd000 R09: 0000000000000100
[ 6646.594951] R10: 0000000000064a80 R11: 0000000000000293 R12: 0000000000000100
[ 6646.594952] R13: 000055e0a90fd000 R14: 000055e0a62f4be0 R15: 0000000000064a80
[ 6646.594956] INFO: task WTJourn.Flusher:28149 blocked for more than 120 seconds.
[ 6646.595166]       Tainted: G          I      4.15.0-91-generic #92-Ubuntu
[ 6646.595367] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6646.595590] WTJourn.Flusher D    0 28149  27425 0x00000000
[ 6646.595592] Call Trace:
[ 6646.595595]  __schedule+0x24e/0x880
[ 6646.595597]  schedule+0x2c/0x80
[ 6646.595598]  io_schedule+0x16/0x40
[ 6646.595600]  wait_on_page_bit_common+0xd8/0x160
[ 6646.595602]  ? page_cache_tree_insert+0xe0/0xe0
[ 6646.595604]  __filemap_fdatawait_range+0xfa/0x160
[ 6646.595606]  ? __filemap_fdatawrite_range+0xcf/0x100
[ 6646.595607]  ? __filemap_fdatawrite_range+0xdb/0x100
[ 6646.595609]  file_write_and_wait_range+0x86/0xb0
[ 6646.595640]  xfs_file_fsync+0x5f/0x230 [xfs]
[ 6646.595644]  vfs_fsync_range+0x51/0xb0
[ 6646.595646]  do_fsync+0x3d/0x70
[ 6646.595649]  SyS_fdatasync+0x13/0x20
[ 6646.595651]  do_syscall_64+0x73/0x130
[ 6646.595654]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 6646.595655] RIP: 0033:0x7f9b8d39060d
[ 6646.595656] RSP: 002b:00007f9b882a3690 EFLAGS: 00000293 ORIG_RAX: 000000000000004b
[ 6646.595657] RAX: ffffffffffffffda RBX: 000055e0a631b840 RCX: 00007f9b8d39060d
[ 6646.595658] RDX: 000055e0a60bc8d0 RSI: 000000000000000f RDI: 000000000000000f
[ 6646.595659] RBP: 00007f9b882a36c0 R08: 0000000000000020 R09: 0000000000000020
[ 6646.595660] R10: 6769546465726957 R11: 0000000000000293 R12: 000055e0a60bc8d0
[ 6646.595661] R13: 000055e0a3172ef1 R14: 000055e0a60cc138 R15: 0000000000000000
[ 6646.595879] INFO: task msgr-worker-1:14875 blocked for more than 120 seconds.
[ 6646.596083]       Tainted: G          I      4.15.0-91-generic #92-Ubuntu
[ 6646.596277] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6646.596631] msgr-worker-1   D    0 14875  14766 0x00000000
[ 6646.596634] Call Trace:
[ 6646.596637]  __schedule+0x24e/0x880
[ 6646.596639]  schedule+0x2c/0x80
[ 6646.596641]  rwsem_down_read_failed+0xf0/0x160
[ 6646.596645]  call_rwsem_down_read_failed+0x18/0x30
[ 6646.596647]  ? call_rwsem_down_read_failed+0x18/0x30
[ 6646.596649]  down_read+0x20/0x40
[ 6646.596654]  __do_page_fault+0x40a/0x4b0
[ 6646.596657]  ? vfs_read+0x115/0x130
[ 6646.596659]  do_page_fault+0x2e/0xe0
[ 6646.596662]  ? page_fault+0x2f/0x50
[ 6646.596664]  page_fault+0x45/0x50
[ 6646.596665] RIP: 0033:0x7f2fe6e16628
[ 6646.596666] RSP: 002b:00007f2fe0bdf250 EFLAGS: 00010206
[ 6646.596672] RAX: 00005585a80de000 RBX: 00000000000012ef RCX: 00005585a5208e80
[ 6646.596673] RDX: 0000000000002000 RSI: 0000000000000fff RDI: 00005585a5208880
[ 6646.596675] RBP: 0000000000001000 R08: 00007f2fe71e9f60 R09: 0000000000000060
[ 6646.596676] R10: 00007f2fe0bdf420 R11: 000000000000004a R12: 0000000000001000
[ 6646.596678] R13: 0000000000000030 R14: 00000000000012ef R15: 0000000000000000
[ 6646.596681] INFO: task log:14885 blocked for more than 120 seconds.
[ 6646.596865]       Tainted: G          I      4.15.0-91-generic #92-Ubuntu
[ 6646.597060] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6646.597408] log             D    0 14885  14766 0x00000000
[ 6646.597419] Call Trace:
[ 6646.597422]  __schedule+0x24e/0x880
[ 6646.597424]  schedule+0x2c/0x80
[ 6646.597426]  schedule_preempt_disabled+0xe/0x10
[ 6646.597427]  __mutex_lock.isra.5+0x276/0x4e0
[ 6646.597430]  __mutex_lock_slowpath+0x13/0x20
[ 6646.597431]  ? __mutex_lock_slowpath+0x13/0x20
[ 6646.597433]  mutex_lock+0x2f/0x40
[ 6646.597467]  xfs_reclaim_inodes_ag+0x2b5/0x340 [xfs]
[ 6646.597471]  ? shrink_page_list+0x3e4/0xbc0
[ 6646.597474]  ? radix_tree_gang_lookup_tag+0xd9/0x160
[ 6646.597478]  ? __list_lru_walk_one.isra.5+0x37/0x140
[ 6646.597482]  ? iput+0x230/0x230
[ 6646.597513]  xfs_reclaim_inodes_nr+0x33/0x40 [xfs]
[ 6646.597545]  xfs_fs_free_cached_objects+0x19/0x20 [xfs]
[ 6646.597549]  super_cache_scan+0x165/0x1b0
[ 6646.597551]  shrink_slab.part.51+0x1e7/0x440
[ 6646.597554]  shrink_slab+0x29/0x30
[ 6646.597555]  shrink_node+0x11e/0x300
[ 6646.597558]  do_try_to_free_pages+0xc9/0x330
[ 6646.597560]  try_to_free_mem_cgroup_pages+0xfa/0x1e0
[ 6646.597565]  try_charge+0x245/0x6a0
[ 6646.597567]  mem_cgroup_try_charge+0x93/0x180
[ 6646.597571]  __handle_mm_fault+0x8de/0x1290
[ 6646.597573]  handle_mm_fault+0xb1/0x210
[ 6646.597576]  __do_page_fault+0x281/0x4b0
[ 6646.597578]  ? SyS_futex+0x13b/0x180
[ 6646.597580]  do_page_fault+0x2e/0xe0
[ 6646.597583]  ? page_fault+0x2f/0x50
[ 6646.597585]  page_fault+0x45/0x50
[ 6646.597588] RIP: 0033:0x55859c29203e
[ 6646.597589] RSP: 002b:00007f2fdfbdda70 EFLAGS: 00010206
[ 6646.597590] RAX: 000055859cc89e60 RBX: 00005585a5ce6200 RCX: 00005585a5ce6240
[ 6646.597591] RDX: 00005585a59ae800 RSI: 00005585a684404f RDI: f0f0f0f0f0f0f0f1
[ 6646.597592] RBP: 000000000000000f R08: 0000000000000000 R09: 0000000000000000
[ 6646.597593] R10: 0000000000000000 R11: 00007f2fe3a63610 R12: 00005585a6844440
[ 6646.597593] R13: 000000000000000a R14: 00005585a59dc780 R15: 15fde929947b3030
[ 7202.983375] libceph: osd2 down

 

이 문제는 CephBlockPool을 사용하며 storage class의 filesystem을 xfs으로 사용할 때 문제가 발생한다.

 

현재 (2020/03/22) rook-ceph v1.2 & ceph v14.2.8으로써 최신버전임에도 문제가 발생하며

지금 kernel 4.15.0-91-generic 을 사용중인데 이후 커널버전에서 패치가 되었단 그런 내용이 있다.

 

관련 이슈는 아래내용을 참고하시길...

 

일단 ext4를 써야겠다.

 

https://github.com/rook/rook/issues/3132

 

Very high CPU usage on Ceph OSDs (v1.0, v1.1) · Issue #3132 · rook/rook

I am not sure where the problem is but I am seeing very high CPU usage since I started using v1.0.0. With three small clusters load average skyrockets to the 10s quite quickly making the nodes unus...

github.com

 

Comment +0

Full guide는 아니구... 단순히.. 방법만...

 

microk8s.enable helm 명령을 실행 하면 실제로는 /snap/microk8s/xxxx/actions/enable.helm.sh 가 실행된다.

 

문제는 /snap/microk8s/xxxx 가 그냥 디렉터리가 아니라 설치이미지가 read-only 으로 마운트된 디렉터리라 수정이 불가능하단 것이다.

 

처음에는 microk8s의 systemd mount관련 파일을 수정해서 해당 위치를 다른 디렉터리로 bind하고.. 참 별걸 다했었는데 이후 생각해보니 더 간단한 방법이 있었다.

 

그냥 해당 파일 하나만 bind 하는 것이다.

 

1. 미리 http://get.helm.sh/helm-$HELM_VERSION-linux-$(arch).tar.gz 을 다운받아 놓고 필요한 대로 수정 (image 경로를 local-registry 로 바꾼다는 등)해서 저장시켜 놓고 (e.g. /tmp/helm.tar.gz)

 

2. /snap/microk8s/xxxx/actions/enable.helm.sh 을 /tmp/enable.helm.sh 같은데 복사한 뒤 해당 파일에서 curl로 helm.tar.gz을 다운받는 대신에 /tmp/helm.tar.gz을 이용하도록 수정하고

 

3. chmod +x /tmp/enable.helm.sh 권한주는거 잊지 마시구..^^

 

4. mount -o bind /tmp/enable.helm.sh /snap/microk8s/xxxx/actions/enable.helm.sh

으로 해당 파일을 새로운 파일로 bind시켜준다.

 

이렇게 하면 microk8s.enable helm 을 하면 /tmp/enable.helm.sh 이 먹게 된다.

 

 

microk8s을 offline으로 설치하는 것은 참 복잡하다..

 

1. $ snap download microk8s

명령으로 microk8s 설치 파일을 미리 다운받아 놓고

2. 필요한 기본 이미지(pause, coredns, tiller, registry 등)들을 이미 다운받아 놓고 (ctr image pull => ctr image export)

# snap ack microk8s.assets

# snap install microk8s.snap

으로 microk8s을 설치한 뒤 다시 이미지를 임포트한다. (ctr image import)

3. 필요한 것들을 microk8s.enable 으로 설치하고 (deployment등은 이미 microk8s내에 존재해서 인터넷 연결이 불필요하지만 docker 이미지는 없기 때문에 필요한건 미리 import 해놓아야 한다.)

4. 쓰면 된다... :)

 

* 참고

필요한 이미지를 export 하기 위해서 리스트를 볼 때
$ sudo ctr -a /var/snap/microk8s/common/run/containerd.sock -n k8s.io images ls
이렇게 볼 수 있긴 하지만 이유는 모르겠으나 이러면 누락된게 생긴다.

위 방법을 통해 리스트를 1차로 뽑고 (아래 방법에서는 pause등이 나오지 않기 때문에 위 방법을 먼저 써야 한다.)

$ microk8s.kubectl get pods --all-namespaces -o yaml | grep "image:" | cut -d':' -f 2 | cut -c2- | uniq

이렇게 보면 실제 pod에서 쓰는 이미지 목록을 얻을 수 있다!

 

Comment +0

<Axxxxx 로그인 예시>

1.     국내 유명 주요 보안 업체인 Axxxxx의 정상 로그인 테스트

 

TLS암호화 여부와 상관없이 개발자모드에서 Network Traffic을 확인해 본다.
캡처 부분 중 “SECRET_PASSWORD” 부분이 입력한 비밀번호임.

 

2.     Progress Telerik Fiddler 으로 HTTPS Decode옵션을 켜놓고 로그인 시도시
(Fidder
의 인증서는 PC에 등록하지 않음)

Fiddler 가 패킷캡쳐를 위해 MITM(중간자공격)를 수행하였고, 이를 감지하여 브라우저에서는 이를 경고한다.

 

3.     무시하고 강제 로그인시 fiddler에서 캡처

암호가 그대로 보이게 된다.

 

 

<하지만 위 상황은 안전하지 않다고 할 수 없다>

해당 연결은 TLS을 이용한 HTTPS연결을 사용하고 있다. TLS연결의 경우 비대칭 키 암호화 방식을 기반으로 한다. TLS연결의 방식을 대강 설명하자면, 서버가 가지고 있는 인증서의 Public Key을 클라이언트(브라우저)에게 보내어 클라이언트가 랜덤으로 생성한 세션 키를 서버의 Public Key로 암호화하여 서버에게 전달한다. 이 과정을 키 교환이라고 한다. 이후 과정부터는 해당 키를 통해 대칭키 암호화를 이용해 서버와 클라이언트가 보안 통신을 한다. TLS인증 방식을 무력화 하는 방법은 MITM(중간자 공격)방식이 있다. MITM방식은 중간에 Proxy서버가 자기 자신을 클라이언트에게 대상서버라고 속이는 방식이다. 그리고 서버와는 정상적인 보안 통신을 하고, 클라이언트와는 자기가 만든 가짜 인증서를 사용하여 오고가는 패킷을 볼 수 있게 된다. TLS에서는 이러한 공격을 무력화 시키기 위해 PKI(공개키 기반 구조)의 인증서를 사용한다. 이는 신뢰할 수 있는 루트 인증 기관(CA)의 인증서를 미리 컴퓨터에 저장해 놓고, CA에서 서버의 인증서의 키를 전자서명하여 인증서에 포함시킨다. 이러한 과정을 통해 MITM공격이 발생하여 서버의 인증서가 변경되면 CA의 전자서명이 없기 때문에 클라이언트 브라우저에서는 이를 인지할 수 있게 되고 따라서 사용자에게 해킹위험을 경고하여 더 이상 진행하지 않도록 한다.

 

<HSTS 적용시>

일반적인 웹 사이트의 경우 MITM공격이 발생한 경우 웹 브라우저에서 경고를 하지만 사용자 선택에 의해 해당 경고를 무시하고 다음 과정을 실행할 수 있다. 이러한 경우 사용자의 과실이지만 위 예시처럼 사용자의 크리덴셜이 노출될 수 있다.

이러한 일 또한 방지하기 위해서는 HSTS(HTTP Strict Transport Security)을 사용해야 한다. 이는 한번 이상 정상적인 방법으로 웹사이트에 접근했을 경우 브라우저가 서버 인증서를 저장하고 유지하도록 하여 이후 MITM공격이 발생하였을 때 아래 사진과 같이 더 이상 다음 과정으로 진행하지 못하게 막는 기능이다.

HSTS가 적용되어 무시하고 더이상 넘어갈 수 없다.

 

*여기서 잠깐*

만약 Fiddler으로 SSL Decrypt옵션을 켰는데 위와 같은 경고창이 뜨지 않는다면? 이는 Fiddler의 인증서를 컴퓨터에 신뢰할 수 있는 루트 인증 기관으로 저장한 것이다.

”Export root certificate to Desktop” 버튼을 누르게 되면 사용자의 컴퓨터에 Fiddler의 인증서를 신뢰할 수 있도록 저장시킨다.

 

앞서 설명했듯이 TLS PKI기반을 하며 신뢰할 수 있는 루트 인증 기관의 인증서는 미리 컴퓨터에 저장해 놓는 방식으로 서버의 인증서의 신뢰 여부를 검증한다. 하지만 만약 정상적인 CA인증서가 아닌 위와 같이 Fiddler의 인증서를 신뢰할 수 있게 하면 Fiddler가 임의로 생성한 MITM용 인증서까지 신뢰할 수 있게 된다. 따라서 브라우저도 Fiddler의 가짜 인증서를 신뢰한다고 표현하는 것이다.

실제 사용 환경에서는 해커가 사용자의 컴퓨터에 가짜 CA인증서를 저장할 수 없다. 따라서 PKI기반의 TLS통신은 안전하, 현재 TLS통신 외에 공공 네트워크에서 안전하게 통신할 수 있는 있는 방법은 세상에 존재하지 않는다.

Comment +0

Test Code:

import sun.security.pkcs11.SunPKCS11;
import sun.security.pkcs11.wrapper.PKCS11;
import sun.security.pkcs11.wrapper.PKCS11Exception;

import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.security.auth.login.FailedLoginException;
import java.io.IOException;
import java.security.Key;
import java.security.KeyStore;
import java.security.UnrecoverableKeyException;

public class TestMain {
    public static void main(String[] args) throws Exception {
        TestMain app = new TestMain();
        app.run();
    }

    private boolean checkFailedLoginException(Throwable e){
        if(e instanceof FailedLoginException) {
            return true;
        }
        if(e.getCause() != null) {
            return checkFailedLoginException(e.getCause());
        }
        return false;
    }

    String dumpbin(byte[] input) {
        StringBuilder sb = new StringBuilder();
        for(byte a : input) {
            sb.append(String.format("%02x ", a & 0xff));
        }
        return sb.toString();
    }

    void run() throws Exception {
        SunPKCS11 p11Provider = new SunPKCS11("G:\\java-etoken-0.cfg");
        KeyStore keyStore = KeyStore.getInstance("PKCS11", p11Provider);
        try {
            keyStore.load(null, "P@ssw0rd".toCharArray());
        }catch (IOException loadException){
            if(checkFailedLoginException(loadException)) {
                System.err.println("LOGIN FAILED");
                return ;
            }else{
                throw loadException;
            }
        }

        Key key = keyStore.getKey("test-aes-1", null);
        System.out.println("key => " + key.getAlgorithm() + " / " + key.getFormat() + " / " + key);

        for(int i=0; i<4; i++) {
            long begin = System.nanoTime();
            Cipher cipher = Cipher.getInstance("AES/CBC/NoPadding", p11Provider);
            cipher.init(Cipher.ENCRYPT_MODE, key);
            System.out.println("IV => " + dumpbin(cipher.getIV()));
            byte[] out = cipher.doFinal("0123456789abcdef0123456789abcdef".getBytes());
            System.out.println("IV => " + dumpbin(cipher.getIV()));
            long end = System.nanoTime();
            long diff = end - begin;
            System.out.println("DIFF = " + (((double) diff) / 1000000));
            System.out.println("dumpbin => " + out.length + " / " + dumpbin(out));
        }
    }
}

결과

key => AES / null / SunPKCS11-eToken AES secret key, 0 bits (id 236257286, token object, not sensitive, unextractable)
IV => 5f 89 21 65 63 56 05 2f 30 74 16 bd ed c3 53 48 
IV => 5f 89 21 65 63 56 05 2f 30 74 16 bd ed c3 53 48 
DIFF = 4196.6191
dumpbin => 32 / db e4 66 14 9f ff e8 23 8e 82 f4 0b f7 21 8a 70 f3 ef 6d a0 90 14 48 2d 7f 8b 91 9c a7 21 3f 95 
IV => 0e a3 14 ff 4c 80 94 5f 7a f0 dd b4 37 cf bc b5 
IV => 0e a3 14 ff 4c 80 94 5f 7a f0 dd b4 37 cf bc b5 
DIFF = 3.1933
dumpbin => 32 / c4 23 3c 93 8d f7 b4 8a 66 fb 8c 82 b5 27 b3 54 b4 df 8f 32 39 dc 5e 3a 93 db a4 55 5e 39 d4 f1 
IV => 40 49 64 32 f9 bd d4 43 65 eb 44 bc 9f 5d b9 c2 
IV => 40 49 64 32 f9 bd d4 43 65 eb 44 bc 9f 5d b9 c2 
DIFF = 2.836
dumpbin => 32 / ac 9c e5 68 da a4 f7 bd 4f d4 40 40 d0 c7 c0 20 90 b6 49 fb 9b 87 ac 80 3a 28 b6 75 38 8e 71 5f 
IV => c9 65 8c f3 06 80 80 5d 86 ff 85 55 44 9c 68 d6 
IV => c9 65 8c f3 06 80 80 5d 86 ff 85 55 44 9c 68 d6 
DIFF = 2.9097
dumpbin => 32 / 60 0d 1f b3 b7 db 85 1e e2 f9 99 3d 0d b2 5b 74 a5 dc 51 ba 6f fd a8 2b 9f 7f 77 75 62 7a 26 cd 

첫번째는 초기화(?) 때문에 4초란 오랜 시간이 걸리고..

동일한 Session에서는 이후 4ms 이하의 시간이 걸리는 듯 한다.

참고로 AES 256bit의 Key이다.

전에 SafeNet 5110으로 Key pair generate 테스트 할 때 시간이 오래 걸렸었는데 초기화 시간이 포함된 시간이었다.

Comment +0

https://www.npmjs.com/package/asn1-stream

 

asn1-stream

ASN1 parser with a stream interface

www.npmjs.com

asn1을 stream으로 파싱하는걸 찾았는데 없네요...

infinite length 파싱은 구현은 대충 해 놓았지만 동작하지 않을겁니다...

ASN1에 대해 잘 아시는 분은 infinite length 을 사용하는 예제 Payload좀 만들어 주세요...ㅠㅠ

아님 구현하셔서 PR주시면 매우감사!

Comment +1

  • 참고로.. 최상위 객체만 next stream으로 출력하기 때문에 최상위 객체속에 여러 객체가 있고 큰 데이터가 있으면 메모리 이슈가 발생할 수 있습니다.
    asn1으로 대용량 데이터 전송 스키마를 만드신다면 최상위 객체에 데이터를 잘라서(chunk) 길게 전달해야 합니다.

ResourceHandlerRegistry의 setOrder(0)을 줬더니 이걸 먼저 타버린다...ㅠㅠ

 

덕분에 몇시간동안 삽질을..

 

 

 

Comment +0

node.js를 runtime그대로 사용하지 않고 libnode를 이용해서 C++ Project내에 embedding하여 사용하고 있습니다.

이에 대해서는 제가 만든 node-app 소스를 이용하여 쉽게 접근할 수 있습니다.

일단 일반적인 상황에서는 테스트를 해 보았고 잘 동작하는거 같습니다만...

몇가지 Issue들이 있으며, 최근 Worker를 활용하면서 몇 가지 큰 이슈 상황이 있습니다.

(필독) 일단 기본적인 embedding에 대해

* 필수적으로 tracing관련하여 Fix된 commit을 적용해야 합니다.

#PR 31217 코멘트를 참고해 주세요. 이 PR을 모티브해서 감사하게도 #PR 31245 을 올려주셨습니다.

* NODE_USE_V8_PLATFORM=1 으로 빌드된 경우 문제되는 상황이 있습니다.

NODE_USE_V8_PLATFORM=1인 경우 libnode 내부적으로 per_process::v8_platform(export되지 않아 외부에서 사용할 수 없는 객체)을 이용하는 부분이 몇군데 있습니다. 따라서 v8_platform으로 초기화하지 않은경우 Crash가 발생하게 됩니다.

* node.js Javascript 코드 종료시 Crash 발생

제가 올린 PR #31260 에 해당 내용을 적어놓았습니다. PR은 통과되지 못하였고, 사실 좋은 방법도 아니며 Test도 통과하지 못합니다.

하지만 임시 방편으로 전 사용중입니다.

DisposePlatform() 함수를 호출하면 per_process::v8_platform.Dispose()을 하는데 v8_platform을 통해 초기화 되었는지 확인하지 않고 무조건 호출하기 때문에 v8_platform을 사용하지 못하고 직접 CreateEnvironment한 경우 Crash가 발생합니다.

threads_worker관련 Issue사항들

Embedding하여 node를 사용하면서 Worker를 사용할 때 필수적인 부분이 있습니다.

구 버전의 node인 경우 위에 v8_platform과 연관된것인데 worker의 isolate를 생성하면서 v8_platform의 Platform을 사용하는 문제가 있습니다.

따라서 6db45bf7def22eedfd95dac95713e850c366b169 커밋 이후 버전으로 빌드된 libnode.dll이 필요합니다. (PR #31217 코멘트 참고)

* Inspect초기화 문제 (Critical)

Issue #31256를 참고해 주세요.

PR #30467을 통해 해결될 수 있는데 아직 머지되지 못하였으며 코멘트들을 보면 참 많은 의견들이 있습니다..

그리고 그 사이에 또 변한 부분들이 여럿 있어서 v13 브랜치에 머지하면 현재는 다른 부분들에서 문제가 발생하기도 합니다.

저두 코드를 고쳐가며 나름 테스트를 해 보고 있습니다..

하지만 아직 Embedding환경에서 Worker사용은 시기상조인거 같습니다.

많은 분들이 관심을 가지고 nodejs측에 관심을 표현해 주심 빨리 해결되리라 생각합니다..!

참고로.. 문제가 발생하단 부분은 NodeZeroIsolateTestFixture.IsolatePlatformDelegateTest 테스트 실패인데,

(그나저나 일단 Environment Test에서 commit 1350eea23ad1da56d26bc60213734a264439aaa6 Fix가 필요하고..)

PR #30324 해당 내용 때문입니다.
PR #30467에서 FreeEnvironment할 때 DrainTasks가 추가되었는데, IsolatePlatformDelegate을 통해 Isolate를 Register했을 때 node_platform.cc의 ForNodeIsolate에서 오류가 발생합니다. shared_ptr\<PerIsolatePlatformData\>가 없기 때문에...

commit 8ab6756984c36d8b69732a71a2df5d28b03c3db5제대로된 방법일진 모르겠으나 Test는 통과합니다.

참고로 Embedding과 별개로 문제가 발생하는 경우가 있는데 PR #31215 이런 상황입니다.

그냥 제 예상으로는 worker사용시 v8 compilation cache관련하여 문제가 생기는게 아닌가 그냥 추측만 해 봅니다.

정확하게는 분석해보지 못해서 알지 못하겠구요..

암튼 코드엔 문제가 없지만 v8 engine이 잘못 해석할 수 있는 코드는 조심해야 할 것 같습니다.

저두 코드를 수정하여 해결하였습니다.

Comment +0