Skills/mY Technutz 2018.02.22 13:27

와.. 대박... 일이 엄청나게 들어와..

공격적으로 오라클 리눅스를 장사하면 내가 쓰일만한 일이 있긴 하구나 하면서도

일이 이렇게 많아지면 개빡쳐서 아무것도 하기 싫어지는 현자타임같은게 온다는..

무튼, 요즘 핫하게 밀려들어오는 업무량 덕에 코어분석 일도 숭풍숭풍 막 쳐 들어오는..

이번에는 레드햇 커널 즉, Oracle Linux 에서 Cmompatibility 를 위해 제공하는

Redhat Compatible Kernel ( RHCK ) 와 관련된 커널 덤프 분석을 해주시겠다.

더보기

Technical Preview 이기 때문에 해당 부분에 대한 코드는

ASSERTCMP(op->state, ==, FSCACHE_OP_ST_DEAD);

로 수정되는 식으로 상황을 정리하는 코드가 추가된 것 같다.
( 수정된 코드 다운받거나 찾기 귀찮다! 바쁘다. 점심안에 써야한다 글을. )

물론 픽스는 해당 fscache 모듈을 사용하지 않도록 하거나,

( cachefilesd 데몬을 Disable 한다. )

ELSA-2017-0307 또는 ELSA-2017-0817 ( RHSA-2017-0817 대응) 에서 권고하는

kernel-2.6.32-696.el6 이후의 최신 버젼으로 업그레이드 하거나

6.8 GA kernel-2.6.32-642.el6 이하 커널로 다운그레이드 하면 된다고

Redhat 에서 이야기 하는 것 같다.

사실 개인생각으로는 커널 업그레이드를 해봤자 동일할것 같긴 해서

구지 필요하지 않다면 Cachefilesd 를 Off 하는게 더 좋을것 같다고 생각된다.

mount option 에서 fsc 가 생겼는데 이게 없으면 자동으로 fscache 가 활성화 된다고 하는 것 같다.

레드햇 이슈라 명확하게 솔루션 코드가 확인되지 않는 상태라 잘 모르겠으나

분석 방법이랑 워크어라운드 기입되 있음 이미 난 충분히 세계를 위해 기여한거시다...

'Skills > mY Technutz' 카테고리의 다른 글

Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
Kernel Crash dump Analysis - #13  (0) 2017.12.20
커널이 지원하는 기능을 확인하는 습관.  (1) 2017.02.06
Kexec/Kdump 의 제약사항에 대해서  (4) 2016.01.14
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018.02.19 13:18

저번 14 에 이어진 내용이라고 볼 수 있다.

지난시간 왜 시스템 커널 분석에서 fc_stat, fc_lport 에 집중했는지 나오는 부분이다.

더보기

이전 게시글에서와 동일하게 ffff880103e67a00  를 참조하는 부분에서 문제가 발생하였다.

따라서 fc_lport 에 관련되어 메모리를 사용함에 있어, 이미 해제된 메모리를 재참조하거나,

메모리 corruption 조건이 발생되고 있다는 것을 의미한다.

역시 저번 게시글과 같이 해당 코드에 논리적 오류나 Race condition 발생 여부,

Used-after-freed 현상에 대해서 더 살펴봐야 하는 상태이지만,

코드 상 특별히 문제될만한 부분은 발견되지 않았다는 점이 현 문제의 가장 큰 난관이다.

지금은 개발팀에서 in-house 로 동일 환경을 구성 후 재현테스트를 하고 있는 중이다.

이는 장비에 대한 특성 ( 펌웨어 문제 또는 하드웨어 관련 된 정보의 괴리 ),

즉 하드웨어 문제를 배제할 수 없는 의심스러운 부분이 있다는 것을 의미한다.



'Skills > mY Technutz' 카테고리의 다른 글

Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
Kernel Crash dump Analysis - #13  (0) 2017.12.20
커널이 지원하는 기능을 확인하는 습관.  (1) 2017.02.06
Kexec/Kdump 의 제약사항에 대해서  (4) 2016.01.14
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018.02.13 23:40

이젠 뭐, 커널에 대한 덤프 분석이라기 보다는

CRASH tool 의 사용법과, 이슈에 따라서 분석을 진행하는 방법에 대한 Guide 가 되어가는 것 같다.

이전엔 주절주절 말을 많이한것 같았는데, 오늘은 주로 코드나 어셈의 흐름을 위주로 설명해 볼까 한다.

시스템이 갑작스럽게 코어와 함께 리붓되었단다.

더보기

참고로 현재 이슈는 다른 이슈와 연결되어 발생한 이슈로써,

아직 해결되지는 않은 이슈이며, fc_lport 의 값을 찾기 위한 이유에 대해서 밝히지 않고 있었다.

물론 이어지는 덤프분석이 또 있을 것이며, 거기서 이유가 밝혀질 것이다.

여기서 중요한 부분은 위의 로그에서 빨간색으로 표현한 두줄의 스택로그이다.

현재 의심되는 부분은 RBX 로 들어가는 메모리가 Corruption 되거나 used-after-freed 현상인데,

두줄의 로그를 보았을 경우 used-after-freed 가 되지 않을까 싶다.

이번 경우에는 확실히 used-after-freed 현상이 가장 가깝기 때문이다.

즉, 해제된 것을 다시 사용하거나, Double free race condition 등이 발생하고 있다는 것이다.

물론... 소스코드상에서는 아직 오류를 찾을 수 없는 상황이다.

보다 자세하고 큰 그림은 다음 분석을 통해 함께 그려보도록 하겠다.

'Skills > mY Technutz' 카테고리의 다른 글

Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
Kernel Crash dump Analysis - #13  (0) 2017.12.20
커널이 지원하는 기능을 확인하는 습관.  (1) 2017.02.06
Kexec/Kdump 의 제약사항에 대해서  (4) 2016.01.14
posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2018.01.11 16:09

인텔의 6개월이 넘는 기간이라는 Embargo 요구를 더이상 못견딘 구글 및 몇몇 Security 팀에서

지난 1월 3일 언론에 해당 내용을 공개하면서 어마어마한 인텔의 치명적 하드웨어 결함이 전세계에 충격을 안겨줬었다.

뭐 따지고보면 '밑돌 빼서 윗돌 괴기' '용돈가불받기' 식의 추측을 통한 Command instruction 기능을 이용하여

성능을 현저하게올렸던 '성능' 위주의 하드웨어 설계였기 때문에,

이로 인한 보안(안정성) 을 포기해야 할 수 밖에 없었던 양날의 칼과 같은 부분이였으나,

보안패치로 인해 성능이 최대 30퍼센트, 체감 50퍼센트 떨어지는 현상은 고객들에게

이미 잘 따뜻하게 입고있는 외투를 졸지에 뺏긴듯 한 상대적 박탈감을 줄 수 밖에 없었다.

이 문제는 앞으로 한번에 해결하기는 어려운 문제이므로, 어떻게 변화가 일어날지, 극복할지 참 귀추가 주시되는 상황이였는데,

벌써 커널쪽에서 대두되고 있는 여러가지 극복방안 등에 대해서 LWN 에 기사가 올라오기 시작한다.

( 일주일 뒤 공개됨 : https://lwn.net/Articles/742984/ )

더보기

어쨋든 한주간의 LWN 은 아니 한 두주간의 LWN 은 거의 Spectre/Meltdown 에 대한

이야기들을 주제로 많은 글을 쏟아내고 있었고, 다시 오랜만에 맞이하게 된

부득이하게 고민할 수 밖에 없는 성능 향상 부분에 대한 화두가,

리눅스가이들에게 던져져 상당히 재밌는 상황이라고 할 수 있을 것 같다.

posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2017.12.20 11:29

귀차니즘에 안하고 있던 커널 덤프 분석 13번째 케이스 공유.

- Symptom : 특정 시간대를 기점으로 HA 로 구성된 서로 다른 세개의 시스템 세트(총 6대)가 비슷한 형태의 메시지를 보이며 리부팅.

일부 HA 및 RAC 시스템의 경우 5분간격으로 리부팅 되는 등, 심각한 서비스의 영향도를 초래하는 상황.

더보기

실재로 고객은 해당 서버에서 LTO 테잎 라이브러리를 이용해 백업을 받는 작업이 있었고,
이때마다 리부팅이 발생한 것으로 판단된다.

처음에는 Tape Driver 의 문제를 의심했으나,

Null point 에러와 여러대의 다른 Cluster set 에서 동일하게 발생하고 있었기 때문에

버그를 찾아보게 되었고, 픽스를 확인할 수 있었다.

물론 이 버그에 대한 패치는 완벽하게 릴리즈 되지 않았고, QA 중이며, UEK4QU6 에 출시되는 4.1.12-119 버젼에 포함될 것이다.

** 완전 새로운 버그였으면 그냥 새 버그로 오픈하거나 커널메일링에 문의를 할 수 있던 상황인데 아쉽..(?)


posted by mirr

댓글을 달아 주세요