Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

.NET Android 36.1.69 / Mono 10.0.12: clarification and fix for non-16-KB-aligned GNU_RELRO ends

Aperta
#13,051 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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

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

need-attention
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

  1. Are these exact prebuilt/generated layouts supported on 16 KB Android despite the documented formula?
  2. If a relink is needed, which stable runtime/SDK release addresses it?
  3. Which supported project setting controls common page size for SDK-generated native libraries?
  4. What additional arm64/x64 runtime evidence is needed to resolve this finding?

Primary references

Steps to Reproduce
  1. 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.
  2. Check LOAD alignment separately, then compute (GNU_RELRO VirtAddr + MemSiz) % 0x4000. The end addresses listed above fail the documented RELRO formula.
  3. 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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/android

Tutte le issue di dotnet/android

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.