.NET Android 36.1.69 / Mono 10.0.12: clarification and fix for non-16-KB-aligned GNU_RELRO ends
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 8/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- android, csharp
- Ambito
- build-system, mobile
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- C#
- Stelle
- 2.1k
- Fork
- 581
- Merge medio
- 1g 21h
- PR unite (30g)
- 241
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di dotnet/android
-
Area: App+Library Build
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Area: Mono.Android
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
dotnet/android#9192 · 4 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Area: Mono.Android needs-triage
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
I maintainer di solito rispondono entro 1 giorno
-
Area: App Runtime needs-triage
Difficoltà 4/5 3-5 giorni Idoneità per principianti 22/100
I maintainer di solito rispondono entro 1 giorno
-
flaky-ci flaky-tests needs-triage
Difficoltà 5/5 Più di una settimana Idoneità per principianti 8/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di dotnet/android
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
dette technique priorité: basse zone: service
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
damiensabau/nexus-lobby#25 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
sebastienros/jint#4282 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 76/100
pyrevitlabs/pyRevit#3792 ·
I maintainer di solito rispondono entro 1 giorno
-
clawsweeper:needs-product-decision clawsweeper:needs-security-review clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:security impact:ux-friction issue-rating: 🦞 diamond lobster P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
openclaw/openclaw-windows-node#1763 · 1 commento · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno