ARM
Posts
173 posts[CPU] 연초부터 악재랄까?
안녕하세요? 연초부터 CPU 회사들은 진땀 빼고 있겠군요? 현재 사용되는 CPU들에서 두 가지 보안적 큰 결함이 발견됐다 하는데... - 하나는 멜트다운 이라 하여, 일종의 커널 영역으로 접근이 가능한 치명적 결함이고, - 다른 하나는 스펙터라 하여 다른 유저의 영역으로의 접근이 가능해지는 전자보다 위험 수위는 조금 낮을지라도 역시 만만찮은 결함이지요... 그리고... 전자의 경우, 현재까지 Intel의 2세대, 혹은 3세대(이게 아직도 명확하지 않네요.) 이후 모든 세대의 i 시리즈, XEON, ARM의 A시리즈 정도가 해당되는 것으로 알려졌고, 일단 시스템의 성능이 상당히 저하되더라도 OS 차원에서 대응이 가능하며, 일부 OS에서는 이미 패치가 진행되는 등 대응
arm32 - Unwind Idx/prolog 소개
TRACE32는 어떻게 각 함수마다 어떤 register를 stack에 push를 하고 지역 변수를 위해서 얼마 만큼의 공간을 확보하는지를 알까요? 모든 함수의 prolog를 체크하여 위 과정을 수행할까요? 그러기에는 과정들이 매우 복잡하므로, Build 과정에서 위의 prolog 정보를 미리 저장해둬요. Linux Kernel의 Symbol Table중에서 __start_unwind_idx에서부터 __stop_unwind_idx 영역이 있는데요.TRACE32명령창에 symbol.browse *unwind_idx 을 입력하면 해당 Symbol Table을 확인할 수 있어요.symbol___________________|type_____________________|address_______________
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
ARM64 - Data Abort Exception(익셉션) Vector 실행
이번 시간에는 Abort 즉 프로그램에 문제가 생겨서 Exception이 생겼을 때 동작 흐름에 대해점검해보고자 해요. ARM에 대한 자료와 세미나를 통해 Exception에 대해서 엄청나게 많이 들었잖아요.뭐, data abort, prefetch abort, undefined abort 등등이죠. 이제 ARM64 아키텍처에서는 이 Abort를 어떻게 처리하고 있는 지 살펴보도록 할께요 우선 아래 코드와 같이 익셉션 벡터가 정의되어 있구요.그런데 abort가 발생할 때는 el1_sync 벡터로 프로그램 카운터가 이동하게 되어 있어요./* * Exception vectors. */ .align 11ENTRY(vectors) ventry el1_sync_invalid // Synchronous E
