STACK
Posts
12 posts[Kernel][Stability] tcp_v4_rcv -> __stack_chk_fail
커널 패닉 시 아래 콜 스택이 남아 있습니다.[39136682.663247] [ ] dump_stack+0x19/0x1b[39136682.663626] [ ] panic+0xd8/0x1e7[39136682.663988] [ ] ? tcp_v4_rcv+0x635/0x9f0[39136682.664361] [ ] __stack_chk_fail+0x1b/0x20[39136682.664743] [ ] tcp_v4_rcv+0x635/0x9f0[39136682.665131] [<
[Kernel][Stability] 스택 오염(Stack Corruption) 디버깅
아래 글에서 stack canary에 대한 내용을 다뤘습니다. 스택을 깨는 지 점검하는 루틴인데요.http://rousalome.egloos.com/9965540#216009 이번에는 다른 디버깅 패치를 작성해서 어떤 루틴이 스택 오염을 시켰는지 점검해보겠습니다. 우선 스택이 깨지는 순서를 살펴보겠습니다. 1. 아래 함수가 처음 실행될 때 순서로 스택을 푸쉬합니다.current_sp-0x1c--- R14 // 0xC06FAE8C 실행 시 스택 주소(스택 푸쉬 후)current_sp-0x18--- R3current_sp-0x14--- R4 current_sp-0x10--- R11current_sp-0xc---- R12current_sp-0x8---- LRcurrent_sp-0x4---- PC
ARM64- Stack Push Userspace -> Kernel Space 코드리뷰
유저 공간에서 실행된 레지스터가 커널 Bottom Stack에 Push 되는 디버깅 정보를 예전 페이지에 업데이트했잖아요.아래와 같은 메모리 덤프를 확인했었죠.(출처:http://rousalome.egloos.com/9966225)NUD:FFFFFFE4DE6A7EB8| 3C 6B 77 2B 46 76 A8 C2 0xC2A876462B776B3CNUD:FFFFFFE4DE6A7EC0| 45 00 00 00 00 00 00 00 0x45 // x0 NUD:FFFFFFE4DE6A7EC8| 80 37 81 AF 7B 00 00 00 0x7BAF813780 // x1NUD:FFFFFFE4DE6A7ED0| 16 00 00 00 00 00 00 00 0x16 // x2NUD:FFFFFF
IRQ Stack(ARM64) - Debugging(디버깅)
아래 블로그에서 IRQ Stack(ARM64)에 대해 소개를 했는데요. 이번에는 직접 코어 덤프에서 IRQ Stack 덤프를 살펴볼께요. IRQ Stack Feature를 지원하는 프로세스의 콜스택을 Trace32로 잡아서 확인해 보았어요. 참고로, 아래는 CPU0에서 idle process가 돌아가 갑자기 IRQ가 Trigger되었을 시의 동작이에요. -000|gic_handle_irq(?) -001|el1_irq(asm) -->|exception -002|lpm_cpuidle_enter(dev = 0x0, ?, idx = 0) -003|cpuidle_enter_state(dev = 0xFFFFFFE57E2A33D8, drv = 0xFFFFFFE4F2E14C00, index = 0) -004|c
