Android 11부터 64비트 프로세스의 경우 모든 힙 할당에는 ARM Top-byte Ignore(TBI) 커널 지원이 있는 기기에서 포인터의 최상위 바이트에 설정된 구현 정의 태그가 있습니다. 이 태그를 수정하는 모든 앱은 할당 해제 중에 태그를 확인하면 종료됩니다. 이는 ARM Memory Tagging Extension(MTE)을 지원하는 향후 하드웨어에 필요합니다.
Top-byte ignore
ARM의 Top-byte Ignore 기능은 모든 Armv8 AArch64 하드웨어에서 64비트 코드에 사용할 수 있습니다.
이 기능은 하드웨어가 메모리에 액세스할 때 포인터의 최상위 바이트를 무시한다는 것을 의미합니다.
TBI에는 사용자 공간에서 전달된 태그가 지정된 포인터를 올바르게 처리하는 호환 커널이 필요합니다.
4.14(Pixel 4) 이상의 Android 일반 커널에는 필수 TBI 패치가 포함됩니다.
커널에서 TBI를 지원하는 기기는 프로세스 시작 시간에 동적으로 감지되며 구현 종속 태그는 모든 힙 할당 포인터의 최상위 바이트에 삽입됩니다. 그런 다음 메모리 할당을 해제할 때 태그가 잘리지 않았는지 확인합니다.
Memory Tagging Extension 준비
ARM의 Memory Tagging Extension(MTE)은 메모리 안전 문제를 해결하는 데 도움이 됩니다. MTE는 스택, 힙, 전역에서 각 메모리 할당의 56번째~59번째 주소 비트를 태그하여 작동합니다. 하드웨어와 명령 집합은 메모리 액세스 시마다 올바른 태그가 사용되는지 자동으로 확인합니다.
포인터의 최상위 바이트에 정보를 잘못 저장하는 Android 앱은 MTE 지원 기기에서 작동이 중단됩니다.
태그가 지정된 포인터를 사용하면 MTE 기기를 사용하기 전에 포인터의 최상위 바이트를 잘못 사용하는 것을 더 쉽게 감지하여 거부할 수 있습니다.
개발자 지원
앱이 비정상 종료되고 이 링크가 표시되는 경우 다음 중 하나가 원인일 수 있습니다.
앱이 시스템의 힙 할당자에서 할당하지 않은 포인터를 해제하려고 했습니다.
앱의 어떤 부분이 포인터의 최상위 바이트를 수정했습니다. 포인터의 최상위 바이트는 수정할 수 없고 코드를 변경하여 이 문제를 해결해야 합니다.
잘못 사용되거나 수정되는 최상위 바이트 포인터의 예는 다음과 같습니다.
특정 유형 포인터에는 최상위 16개 주소 비트에 저장된 앱별 메타데이터가 있습니다.
포인터가 double로 전송되었다가 돌아오므로 하위 주소 비트가 손실됩니다.
재귀 깊이를 측정하는 방법으로 다양한 스택 프레임에서 로컬 변수 주소 간의 차이를 계산하는 코드입니다.
일부 앱은 포인터의 최상위 바이트가 설정될 때 잘못 동작하는 라이브러리에 의존할 수 있습니다. 라이브러리의 이러한 기본 문제를 빠르게 해결하기는 쉽지 않은 일일 수 있습니다. 따라서 targetSdkLevel < 30을 사용하는 앱에는 기본적으로 포인터 태그 지정이 사용 설정되지 않습니다. targetSdkLevel >= 30으로 빌드된 앱의 전환기가 수월하도록 이스케이프 해치도 제공합니다.
이렇게 하면 앱의 포인터 태그 지정 기능이 사용 중지됩니다. 기본 코드 상태 문제는 해결되지 않습니다. 이 이스케이프 해치는 향후 Android 버전에서 사라집니다. 이러한 성격의 문제가 MTE와 호환되지 않기 때문입니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Tagged pointers\n\nStarting in Android 11, for 64-bit processes, all heap allocations have\nan implementation defined tag set in the top byte of the pointer on devices with\nkernel support for ARM Top-byte Ignore (TBI). Any app that modifies this\ntag is terminated when the tag is checked during deallocation. This is necessary\nfor future hardware with [ARM Memory Tagging Extension](https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety) (MTE) support.\n\nTop-byte ignore\n---------------\n\nARM's Top-byte Ignore feature is available for 64-bit code in all Armv8 AArch64 hardware.\nThis feature means that the hardware ignores the top byte of a pointer when\naccessing memory.\n\nTBI requires a [compatible\nkernel](https://www.kernel.org/doc/html/latest/arm64/tagged-address-abi.html#id1) that correctly handles tagged pointers passed from userspace.\nAndroid Common Kernels from 4.14 (Pixel 4) and higher feature the required [TBI\npatches](https://android-review.googlesource.com/c/kernel/common/+/1132334/).\n\nDevices with the TBI support in the kernel are dynamically detected at\nprocess start time and an implementation-dependent tag is inserted into the top\nbyte of the pointer for all heap allocations. After this, a check is run to\nensure the tag hasn't been truncated when deallocating the memory.\n\nMemory Tagging Extension readiness\n----------------------------------\n\nARM's Memory Tagging Extension (MTE) helps address memory safety issues. MTE\nworks by **tagging** the 56th-59th address bits of each memory\nallocation on the stack, heap, and globals. The hardware and instruction set\nautomatically checks that the correct tag is used upon every memory access.\n\nAndroid apps that incorrectly store information in the top byte of the\npointer are **guaranteed to break on an MTE-enabled device**.\nTagged pointers make it easier to detect and reject incorrect uses of the top\nbyte of the pointer before MTE devices are available.\n\nDeveloper support\n-----------------\n\n| **Note:** You'll need to test the 64-bit version of your app to be able to reproduce tagged pointer issues.\n\nIf your app crashed and you were prompted with this link, it could mean\none of the following:\n\n1. The app tried to free a pointer that wasn't allocated by the system's heap allocator.\n2. Something in your app modified the top byte of a pointer. The top byte of the pointer can't be modified and your code needs to be changed to fix this issue.\n\nExamples of the top byte pointer being incorrectly used or modified.\n\n- Pointers to a particular type have app specific metadata stored in the top 16 address bits.\n- A pointer cast to double and then back, losing the lower address bits.\n- Code computing the difference between the addresses of local variables from different stack frames as a way to measure recursion depth.\n\nSome apps may depend on libraries that behave incorrectly when the\ntop byte of the pointer is set. We recognize that it might be\nnontrivial to fix these underlying problems in libraries quickly. As such,\napps that use `targetSdkLevel \u003c 30`\nwon't have pointer tagging enabled by default. We also provide an escape\nhatch for apps built with `targetSdkLevel \u003e= 30`\nto ease the transitional period.\n\nThe escape hatch is used by adding the following to your\n`AndroidManifest.xml` file: \n\n```text\n \u003capplication android:allowNativeHeapPointerTagging=\"false\"\u003e\n ...\n \u003c/application\u003e\n```\n\nThis disables the Pointer Tagging feature for your\napp. This does **not** address the\nunderlying code health problem. This escape hatch will disappear in future\nversions of Android, because issues of this nature will be incompatible with\n[MTE](https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-extension.html)."]]
