.NET Android 36.1.69 / Mono 10.0.12: clarification and fix for non-16-KB-aligned GNU_RELRO ends
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 8/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Activo
- Stack tecnológico
- android, csharp
- Área
- build-system, mobile
Línea de trabajo
Start with the synthetic LLD repro in the issue: assemble the snippet for aarch64 and x86_64, link with -z max-page-size=16384, and inspect GNU_RELRO with llvm-readelf. The SDK side is in LinkApplicationSharedLibraries.cs and NativeLinker.cs, plus the _CreateApplicationSharedLibraries target and Documentation/project-docs/ApkSharedLibraries.md. Done means maintainers state whether these layouts are supported on 16 KB pages and name a supported setting or fixed SDK for generated libraries.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Android framework version
net10.0-android
Affected platform version
Microsoft.Android.Sdk.Windows 36.1.69; Mono Android runtime 10.0.12; Windows host; net10.0-android Release; min API 23, target API 36; LLD 18.1.6
Description
Finding and expected result
The current Android guidance requires (VirtAddr + MemSiz) % 0x4000 == 0 for GNU_RELRO. Seventeen arm64/x64 libraries supplied or generated by this .NET Android toolchain fail this formula although their LOAD alignment passes. This is a static compatibility finding, not an observed crash report. Please clarify the supported layouts against that guidance and identify a stable toolchain fix or supported project setting if relinking is required.
Environment: Windows host; Microsoft.Android.Sdk.Windows 36.1.69; Mono Android runtime 10.0.12; Release net10.0-android; min API 23, target API 36; AOT and RELRO retained. ZIP alignment passes. Twelve affected libraries match vendor package prebuilts byte for byte; five are SDK-generated. No application binaries, business data, credentials or proprietary source are included.
ELF evidence
| ABI | Library | RELRO VirtAddr | RELRO MemSiz | End | Prebuilt SHA-256 / origin |
|---|---|---|---|---|---|
| arm64-v8a | libassembly-store.so | 0x42D0 | 0xD30 | 0x5000 | Application-generated; binary not attached |
| x86_64 | libassembly-store.so | 0x42D0 | 0xD30 | 0x5000 | Application-generated; binary not attached |
| arm64-v8a | libarc.bin.so | 0x42D0 | 0xD30 | 0x5000 | Application-generated; binary not attached |
| x86_64 | libarc.bin.so | 0x42D0 | 0xD30 | 0x5000 | Application-generated; binary not attached |
| x86_64 | libxamarin-app.so | 0x6C4B0 | 0x5B50 | 0x72000 | Application-generated; binary not attached |
| arm64-v8a | libSystem.Globalization.Native.so | 0x14850 | 0x7B0 | 0x15000 | B917AAE2973E3BC7286655B8DD85F331FC39DD3DB3820D7374D6440EB092EA18 |
| arm64-v8a | libSystem.IO.Compression.Native.so | 0xBC4B0 | 0xB50 | 0xBD000 | EBB9A6B7C216A6461A8F2C212524AE41F44662496AC01DB56A6AA098FF810F71 |
| arm64-v8a | libSystem.Native.so | 0x1C4B0 | 0xB50 | 0x1D000 | 9C39E80C604E34DA94388518E91C64024302FB92E5E45F54B9EE9FC9A638AF76 |
| arm64-v8a | libmono-component-marshal-ilgen.so | 0xC340 | 0xCC0 | 0xD000 | 4D7482352AFD571769F3E70A62F0A89A254D0A5FD1FC9A466CCA4D5D3666C453 |
| arm64-v8a | libmonosgen-2.0.so | 0x2F3970 | 0x6690 | 0x2FA000 | 13C160BF504107E2FED22F74BF88D6FDE281C4334E081BB48FDB26ADD060FBD8 |
| arm64-v8a | libmonodroid.so | 0x105E90 | 0x7170 | 0x10D000 | 60B5A7FBC513A26BE52E1F895B8C3EF05CCE25A81AB86A5F4EF90BE8721FF848 |
| x86_64 | libSystem.Globalization.Native.so | 0x14150 | 0xEB0 | 0x15000 | 134404BDC693FF60E9A363F407E180A81D440A98000FA78CBF798E44A8936130 |
| x86_64 | libSystem.IO.Compression.Native.so | 0xCC940 | 0x6C0 | 0xCD000 | BE42B89EFADFD7409787BA33D8800A408D9B4BD141590FA3281001C137265253 |
| x86_64 | libSystem.Native.so | 0x1BF20 | 0x10E0 | 0x1D000 | 496DE7E983B2A27BA92FA9F9DCCC323504705C66459750B4B23EA72ACE64F81E |
| x86_64 | libmono-component-marshal-ilgen.so | 0xC810 | 0x7F0 | 0xD000 | CF8A9EA55288CAE01418F5046C52FDB580D344E865C17F10D0CF91E7BD95C7B1 |
| x86_64 | libmonosgen-2.0.so | 0x31D4C0 | 0x5B40 | 0x323000 | EEC01A889DC71F5DB5C98A32A4877FF2C1AC5119E654C3B8AA3EEA0BD2D4F6D0 |
| x86_64 | libmonodroid.so | 0x11C920 | 0x66E0 | 0x123000 | 293EB7C8752BF678C6AA317E80F051305BB9C31926D83155A5807393FE7AE784 |
SDK-generated linker configuration checked
The installed 36.1.69 _CreateApplicationSharedLibraries target and the matching tagged upstream LinkApplicationSharedLibraries task were inspected. The task exposes ZipAlignmentPages, not an arbitrary linker-arguments property. Its NativeLinker uses maximum-page-size arguments; no common-page-size argument or public additional-arguments hook appears in this inspected path. App AOT arguments therefore do not configure this separate generated-library task. Please identify a supported setting or fixed SDK, rather than requiring replacement of internal tasks or global SDK edits. This inspection is limited to the named task/path.
Runtime evidence and limits
The exercised application runs on an x64 Android 36 emulator with PAGE_SIZE=16384 and page-size compatibility modes disabled. Authenticated module lists, calendars, Contacts CRUD, logout/MFA login and virtual QR camera preview were exercised without a native crash on those paths. QR decoding, invalid-QR rejection and valid Web-to-Android pairing subsequently passed on 9 October 2026, including authenticated home. This is not exhaustive runtime coverage and not arm64 16 KB evidence; complete photo capture/upload remains unqualified. A read-only padding diagnostic found no overlap with declared writable LOAD bytes in the rounded RELRO tail for these findings; this is not treated as an exemption.
The SDK documents libassembly-store.so and libarc.bin.so as mmap payload containers appended to ELF stubs. Please confirm whether different requirements apply to such containers, while also addressing the executable runtime libraries.
Questions
- Are these exact prebuilt/generated layouts supported on 16 KB Android despite the documented formula?
- If a relink is needed, which stable runtime/SDK release addresses it?
- Which supported project setting controls common page size for SDK-generated native libraries?
- What additional arm64/x64 runtime evidence is needed to resolve this finding?
Primary references
- https://developer.android.com/guide/practices/page-sizes#check-the-relro-security-flag
- https://github.com/dotnet/android/wiki/Android-support-for-devices-with-16k-pages
- https://raw.githubusercontent.com/dotnet/android/36.1.69/Documentation/project-docs/ApkSharedLibraries.md
- https://raw.githubusercontent.com/dotnet/android/36.1.69/src/Xamarin.Android.Build.Tasks/Tasks/LinkApplicationSharedLibraries.cs
- https://raw.githubusercontent.com/dotnet/android/36.1.69/src/Xamarin.Android.Build.Tasks/Utilities/NativeLinker.cs
Steps to Reproduce
- Inspect the GNU_RELRO program headers of the listed arm64-v8a/x86_64 runtime prebuilts shipped with Microsoft.Android.Sdk.Windows 36.1.69 / Mono Android 10.0.12, and of the SDK-generated libraries in a Release net10.0-android output.
- Check LOAD alignment separately, then compute (GNU_RELRO VirtAddr + MemSiz) % 0x4000. The end addresses listed above fail the documented RELRO formula.
- Independently reproduce the linker layout with LLD 18.1.6 and llvm-mc using only the synthetic source below. No proprietary application is needed for this linker example.
.text
.globl repro_function
.type repro_function, %function
repro_function:
ret
.size repro_function, .-repro_function
.section .data.rel.ro, "aw"
.quad repro_function
.data
.globl repro_mutable
.type repro_mutable, %object
repro_mutable:
.quad 0
.size repro_mutable, .-repro_mutable
.section .note.GNU-stack, ""
Assemble separately for aarch64-linux-android and x86_64-linux-android. Link with the corresponding emulation (aarch64linux or elf_x86_64), --shared --no-relax -z relro -z now -z max-page-size=16384. Inspect the program headers with llvm-readelf. LOAD alignment passes but the RELRO end is not 16 KB aligned on both architectures. Repeat adding -z common-page-size=16384: this aligns the RELRO end in both isolated examples.
This independent linker result does not itself rebuild the precompiled runtime libraries or the SDK payload stubs, and no vendor binary or SDK installation was modified.
Did you find any workaround?
No supported application-level workaround has been established for all listed libraries. Adding -z common-page-size=16384 fixes the isolated synthetic linker examples only. We have not patched supplier ELF binaries, replaced SDK tasks, disabled AOT/RELRO or weakened the audit.
Relevant log output
Static ELF findings, not a crash log. The exact RELRO addresses and public prebuilt hashes are included in Description. No application binlog, APK/AAB, private source, account or secret is attached.
- Lenguaje dominante
- C#
- Estrellas
- 2.1k
- Forks
- 579
- Merge medio
- 1 d 14 h
- PR fusionados (30 d)
- 236
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de dotnet/android
-
Area: App+Library Build
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
EditText.getText() isn't boundAbiertoArea: Mono.Android
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
dotnet/android#9192 · 4 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
AndroidTypeMapImplementation trimmable removes types that are used in type castsPosiblemente ocupada @simonrozsival la tomó hace 1 día. AbiertoArea: App Runtime bug trimmable-type-map
dotnet/android#13286 · 1 comentario · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
flaky-ci flaky-tests needs-triage
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
-
Area: App+Library Build needs-triage
Dificultad 4/5 3-5 días Aptitud para principiantes 56/100
Los mantenedores suelen responder en 1 día
Todos los issues de dotnet/android
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Open-Systems-Pharmacology/OSPSuite.Core#3049 ·
Los mantenedores suelen responder en 1 día
-
needs attention public-client untriaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
AzureAD/microsoft-authentication-library-for-dotnet#6242 ·
Los mantenedores suelen responder en 2 días
-
docs: HTML config transform example sets advancedCustomization at a path the UI does not readAbierto
Dificultad 1/5 1-3 horas Aptitud para principiantes 90/100
criticalmanufacturing/cli#882 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Dome-Works/DOME#129 ·
Los mantenedores suelen responder en 1 día
-
bug sev:L
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Systemorph/MeshWeaver#7480 ·
Los mantenedores suelen responder en 1 día