Userland phase 1c: isolated address spaces: private roots, unmap, protect, teardown and switching

Aperta
  • Qualcosa non va?
#3,352 0 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
12/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
operating-systems

Direzione di ricerca

This is a multi-part kernel design task spanning Core/Memory/Pager.cs, IPagerBackend.cs, X64PagerBackend.cs and Arm64PagerBackend.cs, plus CR3/CR4 and PageTable.s. Start by reading Pager.cs and the backend encodings the issue cites (the Global bit near X64PagerBackend.cs:484 and the nG note near Arm64PagerBackend.cs:705). Done means the listed Cosmos.Kernel.Tests.Memory cells pass on both architectures; the issue depends on unmerged phases 1a, 1b and #3351, so it is not a good first issue.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Area: Memory Enhancement Priority: High

Part of #3271. Proposal: section 1 (Platform-Agnostic Paging API) of #3271, its completion criteria. Builds on #3350 and, on ARM64, #3351. Absorbs #3302.

Goal

What section 1 asks for and phase 1a leaves out on purpose ("Nothing here gives a space a private root, switches to one, or tears one down", Pager remarks in #3329): a process owns a root of its own with the kernel half shared into it, user mappings carry user permissions, and the kernel can shrink a space, switch to it and destroy it. #3302 describes the teardown against the AddressSpace of valentinbreiz/nativeaot-patcher#405, which is not on gen3; its work moves here.

Work

  • An isolated space: a fresh root whose kernel half is the kernel's own tables. x64: PML4 entries 256–511 copied when the space is created and never edited per space, so every kernel PDPT is allocated at boot and a later kernel mapping cannot miss a space. ARM64: a private TTBR0 only, with TTBR1 shared (#3351 first)
  • Unmap and Protect (change permissions) on a committed range, and a query for an address's flags, so a space can shrink and mprotect has a primitive to call
  • A user virtual range allocator: the user window per architecture (the canonical lower half on x64, the TTBR0 range set by TCR_EL1.T0SZ on ARM64), page 0 never mapped, guard pages between allocations
  • Destroy: walk the user-half tables, return the frames the space owns and the table pages to PageAllocator, free the root, and never touch the shared kernel half (#3302). Each region records whether its frames are owned (anonymous memory the space allocated) or borrowed (shared or device memory)
  • Switching: an activate call that writes CR3 / TTBR0_EL1 with its barriers, called by the context switch in phase 3. x64: kernel mappings carry Global (the backend in #3329 already encodes bit 8, X64PagerBackend.cs:484) with CR4.PGE set, or every switch flushes the kernel's TLB entries; PCID optional. ARM64 has no global bit (Arm64PagerBackend.cs:705): user entries carry nG and each space an ASID in TTBR0_EL1[63:48], or every switch pays a tlbi vmalle1is
  • TLB shootdown: invlpg is local to the CPU that issues it. One CPU is fine today, but from the first unmap, protect or teardown of a space live on another CPU, a shootdown IPI is a correctness condition (#3336). ARM64's tlbi ...is forms already broadcast

Proves itself with

Cosmos.Kernel.Tests.Memory cells on both architectures:

  • Pager_IsolatedSpace_KernelHalfShared: a kernel heap pointer translates to the same frame in the new space
  • Pager_IsolatedSpace_UserMappingPrivate: a user mapping is invisible from the kernel space and from a second isolated space
  • Pager_Unmap_TranslateFails and Pager_Protect_ClearsWritable
  • Pager_Destroy_ReturnsPages: PageAllocator's free count is the same before the space was created and after it is destroyed
  • Pager_Activate_RoundTrip: switch to a space, read a user-window page mapped only there, switch back

Files

Core/Memory/Pager.cs, IPagerBackend.cs, AddressSpaceDescriptor.cs, AddressSpaceRegion.cs, PageFlags.cs, Core.X64/Memory/X64PagerBackend.cs, Core.ARM64/Memory/Arm64PagerBackend.cs, Native.X64/CPU/ (CR3, CR4), Native.ARM64/CPU/PageTable.s, tests/Kernels/Cosmos.Kernel.Tests.Memory/Kernel.cs.

Lingua principale
C#
Stelle
3.2k
Fork
591
Merge medio
21h 34m
PR unite (30g)
26

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 CosmosOS/Cosmos

Tutte le issue di CosmosOS/Cosmos

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.