Сбой SIGSEGV с кодом 9 (SEGV_MTESERR) или кодом 8 (SEGV_MTEAERR) — это ошибки тегирования памяти. Расширение тегирования памяти (MTE) — это функция Armv9, поддерживаемая в Android 12 и более поздних версиях. MTE — это аппаратная реализация тегированной памяти. Он обеспечивает детальную защиту памяти для обнаружения и устранения ошибок безопасности памяти .
В C/C++ указатель, возвращаемый вызовом malloc(), оператора new() или подобных функций, может использоваться только для доступа к памяти в пределах этого выделения, и только пока выделение активно (не освобождено или не освобождено). удалить-ред.). MTE используется в Android для обнаружения нарушений этого правила, которые в отчетах о сбоях называются проблемами «Переполнение буфера»/«Недополнение буфера» и «Использование после освобождения».
MTE имеет два режима: синхронный (или «синхронный») и асинхронный (или «асинхронный»). Первый работает медленнее, но обеспечивает более точную диагностику. Последний работает быстрее, но может дать лишь приблизительные сведения. Мы рассмотрим оба варианта отдельно, поскольку диагностика немного отличается.
Синхронный режим МТЕ
В синхронном («синхронном») режиме MTE SIGSEGV аварийно завершает работу с кодом 9 (SEGV_MTESERR).
pid: 13935, tid: 13935, name: sanitizer-statu >>> sanitizer-status <<< uid: 0 tagged_addr_ctrl: 000000000007fff3 signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000 backtrace: #00 pc 00000000000010c0 /system/bin/sanitizer-status (test_crash_malloc_uaf()+40) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #01 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #02 pc 00000000000019cc /system/bin/sanitizer-status (main+1032) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000487d8 /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) deallocated by thread 13935: #00 pc 000000000004643c /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::quarantineOrDeallocateChunk(scudo::Options, void*, scudo::Chunk::UnpackedHeader*, unsigned long)+688) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 00000000000421e4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+212) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 00000000000010b8 /system/bin/sanitizer-status (test_crash_malloc_uaf()+32) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) allocated by thread 13935: #00 pc 0000000000042020 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::allocate(unsigned long, scudo::Chunk::Origin, unsigned long, bool)+1300) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 0000000000042394 /apex/com.android.runtime/lib64/bionic/libc.so (scudo_malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 000000000003cc9c /apex/com.android.runtime/lib64/bionic/libc.so (malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #03 pc 00000000000010ac /system/bin/sanitizer-status (test_crash_malloc_uaf()+20) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #04 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
Все отчеты о сбоях MTE содержат обычный дамп регистра и обратную трассировку точки, где была обнаружена проблема. Строка «Причина:» для ошибки, обнаруженной MTE, будет содержать «[MTE]», как в примере выше, а также более подробную информацию. В этом случае конкретным типом обнаруженной ошибки было «Использовать после освобождения», а «0 байт в 32-байтовом выделении по адресу 0x7ae92853a0» сообщают нам размер и адрес выделения, а также смещение в выделении, которое мы пытался получить доступ.
Отчеты о сбоях MTE также включают дополнительные обратные трассировки, а не только те, которые происходят с точки обнаружения.
Ошибки «Использовать после освобождения» добавляют разделы «Освобождено» и «Выделено» в аварийный дамп, показывая трассировки стека в момент освобождения этой памяти (до того, как она была использована!), а также время, когда она была выделена ранее. Они также сообщают вам, какой поток выполнил выделение/освобождение. Все три потока обнаружения, потока распределения и потока освобождения одинаковы в этом простом примере, но в более сложных реальных случаях это не обязательно так, и знание того, что они различаются, может быть важным ключом к поиску параллелизма. - связанная ошибка.
Ошибки «Переполнение буфера» и «Недополнение буфера» предоставляют только дополнительную дорожку стека «выделено», поскольку по определению они еще не были освобождены (или они будут отображаться как «Использовать после освобождения»):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
Обратите внимание на использование здесь слова «право»: это означает, что мы сообщаем вам, на сколько байтов после конца выделения был неправильный доступ; в случае нижнего переполнения будет указано «лево» и будет указано количество байтов до начала выделения.
Несколько потенциальных причин
Иногда отчеты SEGV_MTESERR содержат следующую строку:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Это происходит, когда есть несколько хороших кандидатов на источник ошибки, и мы не можем сказать, какая из них является фактической причиной. Мы печатаем до трех таких кандидатов в приблизительном порядке вероятности и оставляем анализ на усмотрение пользователя.
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x400007b43063db5
backtrace:
[stack...]
Note: multiple potential causes for this crash were detected, listing them in decreasing order of probability.
Cause: [MTE]: Use After Free, 5 bytes into a 10-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]
Cause: [MTE]: Use After Free, 5 bytes into a 6-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]В приведенном выше примере мы обнаружили два недавних выделения по одному и тому же адресу памяти, которые могли быть предполагаемой целью недопустимого доступа к памяти. Это может произойти, когда при выделении повторно используется свободная память — например, если у вас есть такая последовательность, как новый, свободен, новый, свободен, новый, свободен, доступ. Сначала печатается более позднее распределение.
Подробная эвристика определения причины
«Причина» сбоя должна показывать распределение памяти, из которого первоначально был получен указатель доступа. К сожалению, аппаратное обеспечение MTE не имеет возможности преобразовать указатель с несовпадающим тегом в выделение. Чтобы объяснить сбой SEGV_MTESERR, Android анализирует следующие данные:
- Адрес неисправности (включая тег-указатель).
- Список последних выделений кучи со трассировкой стека и тегами памяти.
- Ближайшие текущие (действующие) выделения и их теги памяти.
Любая недавно освобожденная память по адресу ошибки, где тег памяти соответствует тегу адреса ошибки, является потенциальной причиной «Использовать после освобождения».
Любая близлежащая действующая память, где тег памяти соответствует тегу адреса неисправности, является потенциальной причиной «переполнения буфера» (или «переполнения буфера»).
Выделения, расположенные ближе к разлому – во времени или в пространстве – считаются более вероятными, чем те, которые находятся далеко.
Поскольку освобожденная память часто используется повторно, а количество различных значений тегов невелико (менее 16), нередко можно найти несколько вероятных кандидатов, и нет возможности автоматически найти истинную причину. Именно по этой причине иногда в отчетах MTE указывается несколько потенциальных причин.
Разработчику приложения рекомендуется рассмотреть потенциальные причины, начиная с наиболее вероятной. Зачастую на основе трассировки стека легко отфильтровать несвязанные причины.
Асинхронный режим MTE
В асинхронном («асинхронном») режиме MTE SIGSEGV аварийно завершает работу с кодом 8 (SEGV_MTEAERR).
Ошибки SEGV_MTEAERR не возникают сразу, когда программа выполняет неверный доступ к памяти. Проблема обнаруживается вскоре после события, и вместо этого программа завершается. Обычно этой точкой является следующий системный вызов, но это также может быть прерывание таймера — короче говоря, любой переход из пользовательского пространства в ядро.
Ошибки SEGV_MTEAERR не сохраняют адрес памяти (он всегда отображается как «-------»). Обратная трассировка соответствует моменту обнаружения условия (т. е. при следующем системном вызове или другом переключении контекста), а не моменту выполнения недопустимого доступа.
Это означает, что «основная» обратная трассировка при асинхронном сбое MTE обычно не имеет значения . Таким образом, сбои в асинхронном режиме гораздо сложнее отлаживать, чем сбои в режиме синхронизации. Их лучше всего понимать как демонстрацию наличия ошибки памяти в соседнем коде данного потока. Журналы в нижней части файла надгробия могут дать подсказку о том, что на самом деле произошло. В противном случае рекомендуется воспроизвести ошибку в режиме синхронизации и использовать лучшую диагностику, предоставляемую режимом синхронизации!
Расширенные темы
На самом деле маркировка памяти работает путем присвоения случайного 4-битного значения тега (0–15) каждому выделению кучи. Это значение сохраняется в специальной области метаданных, соответствующей выделенной куче памяти. То же значение присваивается старшему байту указателя кучи, возвращаемого такими функциями, как malloc() или оператор new().
Если в процессе включена проверка тегов, ЦП автоматически сравнивает верхний байт указателя с тегом памяти при каждом доступе к памяти. Если теги не совпадают, ЦП сигнализирует об ошибке, которая приводит к сбою.
Из-за ограниченного числа возможных значений тега этот подход является вероятностным. Любая область памяти, к которой нельзя получить доступ с помощью данного указателя (например, за пределами границ или после освобождения («висячий указатель»)), скорее всего, будет иметь другое значение тега и приведет к сбою. Существует вероятность около 7% не обнаружить ни одного случая ошибки. Поскольку значения тегов назначаются случайным образом, существует независимая вероятность обнаружения ошибки в следующий раз, когда она произойдет, примерно в 93%.
Значения тегов можно увидеть в поле адреса ошибки, а также в дампе регистра, как показано ниже. Этот раздел можно использовать для проверки правильности установки тегов, а также для просмотра других близлежащих выделений памяти с тем же значением тега, поскольку они могут быть потенциальными причинами ошибки, помимо тех, которые перечислены в отчете. Мы ожидаем, что это будет в основном полезно для людей, работающих над реализацией самого MTE или других низкоуровневых компонентов системы, а не для разработчиков.
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x0800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000
В отчете о сбое также появляется специальный раздел «Теги памяти», в котором вокруг адреса ошибки отображаются теги памяти. В приведенном ниже примере тег указателя «4» не соответствует тегу памяти «a».
Memory tags around the fault address (0x0400007b43063db5), one tag per 16 bytes: 0x7b43063500: 0 f 0 2 0 f 0 a 0 7 0 8 0 7 0 e 0x7b43063600: 0 9 0 8 0 5 0 e 0 f 0 c 0 f 0 4 0x7b43063700: 0 b 0 c 0 b 0 2 0 1 0 4 0 7 0 8 0x7b43063800: 0 b 0 c 0 3 0 a 0 3 0 6 0 b 0 a 0x7b43063900: 0 3 0 4 0 f 0 c 0 3 0 e 0 0 0 c 0x7b43063a00: 0 3 0 2 0 1 0 8 0 9 0 4 0 3 0 4 0x7b43063b00: 0 5 0 2 0 5 0 a 0 d 0 6 0 d 0 2 0x7b43063c00: 0 3 0 e 0 f 0 a 0 0 0 0 0 0 0 4 =>0x7b43063d00: 0 0 0 a 0 0 0 e 0 d 0 [a] 0 f 0 e 0x7b43063e00: 0 7 0 c 0 9 0 a 0 d 0 2 0 0 0 c 0x7b43063f00: 0 0 0 6 0 b 0 8 0 3 0 0 0 5 0 e 0x7b43064000: 0 d 0 2 0 7 0 a 0 7 0 a 0 d 0 8 0x7b43064100: 0 b 0 2 0 b 0 4 0 1 0 6 0 d 0 4 0x7b43064200: 0 1 0 6 0 f 0 2 0 f 0 6 0 5 0 c 0x7b43064300: 0 1 0 4 0 d 0 6 0 f 0 e 0 1 0 8 0x7b43064400: 0 f 0 4 0 3 0 2 0 1 0 2 0 5 0 6
Разделы захоронения, в которых отображается содержимое памяти вокруг всех значений регистров, также отображают значения их тегов.
memory near x10 ([anon:scudo:primary]): 0000007b4304a000 7e82000000008101 000003e9ce8b53a0 .......~.S...... 0700007b4304a010 0000200000006001 0000000000000000 .`... .......... 0000007b4304a020 7c03000000010101 000003e97c61071e .......|..a|.... 0200007b4304a030 0c00007b4304a270 0000007ddc4fedf8 p..C{.....O.}... 0000007b4304a040 84e6000000008101 000003e906f7a9da ................ 0300007b4304a050 ffffffff00000042 0000000000000000 B............... 0000007b4304a060 8667000000010101 000003e9ea858f9e ......g......... 0400007b4304a070 0000000100000001 0000000200000002 ................ 0000007b4304a080 f5f8000000010101 000003e98a13108b ................ 0300007b4304a090 0000007dd327c420 0600007b4304a2b0 .'.}......C{... 0000007b4304a0a0 88ca000000010101 000003e93e5e5ac5 .........Z^>.... 0a00007b4304a0b0 0000007dcc4bc500 0300007b7304cb10 ..K.}......s{... 0000007b4304a0c0 0f9c000000010101 000003e9e1602280 ........."`..... 0900007b4304a0d0 0000007dd327c780 0700007b7304e2d0 ..'.}......s{... 0000007b4304a0e0 0d1d000000008101 000003e906083603 .........6...... 0a00007b4304a0f0 0000007dd327c3b8 0000000000000000 ..'.}...........