Omne systema operativum incipit antequam vere ipsum sit. CPU in ambitu a platforma definito surgit, firmware satis ferramenti initializat ut primum exsecutabile oneretur, et illud exsecutabile machinam ad nucleum praeparat. Tantum postquam haec catena opus suum fecit systema operativum suas regulas exsequi incipere potest.

Facile est hunc primum iter quasi rem mechanicam tantum tractare, sed processus boot pars est exemplaris securitatis. In EriX, boot primus locus est ubi bytes non fideles in exsecutionem fide dignam mutantur, atque etiam primus locus est ubi auctoritas machinae in structuram explicitam vertitur: imagines verificatae, tabulae memoriae, descriptoribus modulorum, inscriptiones introitus, metadata framebuffer, indices ACPI, et tandem obiecta nuclei.

Si hoc iter neglegenter fit, systema facultatum a mendacio incipit. Hic articulus iter initii EriX a firmware ad nucleum percurrit: quid UEFI praebeat, quid bootloader facere debeat, quid handoff contineat, et cur nucleus ut exsecutabile partis superioris intretur.

Boot cum auctoritate firmware incipit⌗

In scopis hodiernis EriX, iter initii cum UEFI in x86_64 incipit. UEFI firmware est, et ante systema operativum currit. Praebet officia boot quibus applicatio EFI fasciculos legere, memoriam allocare, tabulam memoriae platformae inspicere, tabulas configurationis sicut ACPI invenire, exitum graphicum per GOP interrogare, et officia boot relinquere potest antequam nucleus imperium accipiat.

Bootloader EriX ut applicatio UEFI aedificatur, itaque firmware bootloader primum onerat et punctum introitus UEFI eius vocat. In implementatione, hoc punctum introitus est efi_main, conventione vocationis UEFI x86_64 utens. Hoc tempore EriX machinam nondum regit; intra ambitum a firmware datum currit.

Bootloader UEFI rogare potest ut fasciculum legat, memoriam allocet, tabulas firmware inspiciat, et tabulas paginarum paret, sed omnis illa auctoritas temporaria est. Officia boot UEFI non sunt systema operativum. Sunt quasi scaffolding quod bootloader caute uti debet, in facta explicita contrahere, et deinde relinquere.

Bootloader codex fidus est⌗

Bootloader currit antequam nucleus aliquid cogere possit, quod eum in basi computationis fiduciae ponit. Si bootloader bytes iniustos onerat, ad inscriptionem iniustam salit, imaginem corruptam accipit, memoriam male notat, aut auctoritatem fingit quae ex input verificato non venit, nucleus a fundamento compromisso incipit. Ut hoc periculum auditabile maneat, EriX officium bootloader angustum et explicitum servat:

  • boot.img invenire et onerare
  • imaginem ante fidem validare
  • dynamic boot store validare
  • nucleum dynamicum et obiecta prima requisita relocare
  • structuram handoff deterministicam aedificare
  • tabulas paginarum et acervum bootstrap parare
  • officia boot UEFI relinquere
  • ad nucleum semel salire

Hoc consulto non est ambitus boot generalis. In ambitu hodierno nulla est politica menu initii, nullum iter restitutionis remotum, nec conatus est procedere post input malformatum quod boot criticum est. Regula est verificare antequam exsequi: si imago boot parsari, verificari, onerari, mappare, aut cohaerenter describi non potest, conatus initii deficit antequam nucleus imperium accipiat.

boot.img onerare⌗

Iter UEFI hodiernum hunc fasciculum in volumine boot quaerit. Via fixa est pro profilo hodierno, quod tractationem medii primi angustam servat et vitat ne boot in problema inventionis politicae mutetur:

\ERIX\BOOT.IMG

Bootloader volumen boot per protocolla fasciculorum UEFI aperit, fasciculum in memoriam ab UEFI allocatam legit, et primam probationem levem magiae continentis ERIXBOOT facit ante parsing profundiorem. Postea lib-bootimg rem accipit: bootloader imaginem ut BootImage parsatur, signaturam et hashes verificat, architecturam manifesti probat, et tantum deinde payloads extrahere incipit.

Haec separatio refert quia medium boot fide dignum non est. Fasciculus deesse, truncatus esse, malformatus esse, aut corruptus esse potest, et bootloader descriptor sectionis verum tractare non licet solum quia e disco venit. In EriX, parser et verificator boot.img pars sunt itineris boot fiduciae, et structuram malam, limites malos, hashes malos, versiones non sustentatas, et data architecturae incompatibilia reicere debent antequam ullus byte oneratus exsecutabilis fiat.

Articuli sequentes altius in formam boot.img et verificationem imaginum ibunt. In hoc articulo, ordo maximus est:

  1. bytes legere
  2. structuram parsare
  3. integritatem verificare
  4. convenientiam scopi probare
  5. artefacta boot dynamica validare et relocare
  6. metadata handoff aedificare

Exsecutio post validationem venit, non ante. Hic ordo discrimen est inter imaginem boot ut input tractare et eam ut auctoritatem tractare.

Nucleum onerare⌗

Postquam boot.img accepta est, bootloader nucleo indiget, et in itinere boot EriX nucleus ex dynamic boot store signato oneratur. Bootloader nucleum dynamicum ut obiectum ELF64 ET_DYN validat, metadata dynamic-link EriX probat, nomina dependentiarum et hashes obiectorum contra metadata signata verificat, obiecta communia requisita onerat, relocationes probatas applicat, restrictiones W^X imponit, et catalogum boot dynamicum pro nucleo parat.

Hoc multum sonat quia multum est, sed forma securitatis directa et recensibilis manet:

  • data ex imagine boot verificata veniunt
  • parsing formae exsecutabilis explicitum est
  • intervalla segmentorum probantur
  • effectus relocationum cohibentur
  • metadata dynamica absentia vel incohaerentia ante introitum nuclei deficiunt

Bootloader est ut nucleum dynamicum validet et relocet, deinde graphum obiectorum primorum verificatum nucleo describat. Non fit generalis dynamic linker systematis currentis; ille munus postea pertinet, postquam nucleus et exemplar officiorum in spatio usoris existunt.

Metadata boot servare⌗

Nucleus dynamicus non solum in imagine boot est. Bootloader etiam metadata boot non exsecutabilia servat quae a nucleo et systemate primo in spatio usoris requiruntur, dum officia exsecutabilia ad graphum obiectorum dynamicum pertinent. Illa artefacta exsecutabilia a catalogo dynamico ut obiecta, segmenta, et lineae dependentiae describuntur, ex store signato et manifesto signato deducta.

Aliae sectiones requisitae sunt blobs non exsecutabiles. Exempla sunt configuratio boot, stores metadata dynamic-link, et data fontis consolae. Haec in memoriam mappatam copiatur et ut moduli tantum legendi sine puncto introitus describuntur, quia blob non fit exsecutabilis solum quia in imagine boot apparet.

Haec distinctio ad consilium facultatum pertinet. Payload configurationis boot a systemate primo legi debet, sed ut codex tractari non debet. Blob fontis ad continuationem framebuffer necessarius esse potest, sed auctoritate exsecutionis non indiget. EriX hanc distinctionem in handoff servat:

  • descriptoribus obiectorum dynamicorum pro artefactis exsecutabilibus
  • descriptoribus segmentorum dynamicorum pro intervallis exsecutabilibus et data mappatis
  • descriptoribus dependentiarum dynamicarum pro relationibus obiectorum primorum
  • SECTION_TYPE_BOOT_CONFIG pro data politicae boot
  • descriptoribus modulorum pro blobs boot non exsecutabilibus

Handoff hanc differentiam fert ut nucleus et rootd coniectare non debeant utrum pars datae boot sit auctoritas exsecutabilis, configuratio tantum legenda, an metadata ordinaria.

Handoff pactum est⌗

Bootloader API nuclei non vocat, quia nucleus currens nondum est. Pro eo, bootloader blob handoff aedificat: pactum binarium versionatum a lib-handoff definitum. In profilo hodierno a bootloader ad nucleum, incipit magia ERIXHK01, campis versionis maioris et minoris, magnitudine tota, identificatoribus architecturae et platformae, deinde offsets et numeris tabularum quae sequuntur.

Handoff varias classes datorum continere potest quibus nucleus indiget antequam suam visionem runtime machinae aedificare possit:

  • ingressus tabulae memoriae normalizati
  • descriptoria modulorum oneratorum
  • index ACPI RSDP
  • build ID et hash imaginis verificata
  • metadata continuationis framebuffer
  • descriptoria obiectorum dynamicorum
  • descriptoria segmentorum dynamicorum
  • lineae dependentiae dynamicae

Haec est prima translatio structa auctoritatis. Firmware bootloader facta cruda et officia temporaria dedit, et imago boot verificata metadata payload signata dedit. Bootloader haec componit in descriptionem deterministicam quid oneraverit, ubi posuerit, et cui nucleus confidere possit.

Handoff non est indicium nec metadata “best effort”. Est input ex quo nucleus suam visionem machinae aedificare incipit, ideoque numeros, magnitudines ingressuum, offsets, hashes, genera, intervalla, et campos versionis portat. Nucleo necesse est posse id reicere.

Tabulae memoriae normalizari debent⌗

Tabulae memoriae firmware non sponte ad politicam nuclei formantur. UEFI regiones cum generibus memoriae firmware refert, dum bootloader etiam memoriam novit quam pro nucleo dynamico, mappationibus obiectorum primorum, blobs boot requisitis, acervo bootstrap, paginis handoff, mappationibus framebuffer, et imagine boot originali allocavit. Hae visiones coniungendae sunt antequam nucleus de memoria disponibili ratiocinari possit.

In EriX, bootloader tabulam memoriae UEFI capit, regiones explicite a boot possessas addit, et exitum in intervalla non superposita normalizat cum generibus memoriae EriX sicut:

  • RAM utilis
  • memoria reservata
  • memoria ACPI reclaimable
  • memoria ACPI NVS
  • memoria MMIO/dispositivi
  • memoria a bootloader possessa
  • memoria ab imagine boot possessa

Regiones explicite a boot possessae super classificationes generales firmware praevalent. Hoc refert quia nucleus memoriam quae imaginem boot, blob handoff, mappationes obiectorum dynamicorum, blobs boot requisita, aut acervum bootstrap continet non debet casu ut RAM liberam ordinariam tractare. Memoria in EriX auctoritas est, itaque etiam tam mature systema curat quis quos bytes iterum uti possit.

UEFI relinquere⌗

Officia boot UEFI utilia sunt, sed temporaria. Antequam ad nucleum saliat, bootloader ExitBootServices vocat, quod re vera transitus unius directionis est. Post exitum prosperum, bootloader indices ad officia boot invalidos tractare debet; non potest pergere firmware rogare ut memoriam allocet aut fasciculos legat postquam systema operativum imperium accipit.

Hic transitus delicatus est quia UEFI requirit ut bootloader exeat clavi tabulae memoriae currente utens. Si tabula inter capturam et exitum mutatur, vocatio deficere potest et loader cum tabula nova iterum temptare debet. Adaptor UEFI EriX hunc circuitum retry in strato platformae administrat.

Punctum consilii maximum est quod nucleus intratur postquam bootloader officia firmware uti finivit. Nucleus dependentiam firmware semapertam hereditare non debet; data explicita hereditare debet.

Primas tabulas paginarum aedificare⌗

Nucleus intratur paginatione iam activa. Pro profilo UEFI x86_64 hodierno, bootloader minimas tabulas paginarum cum duobus generibus mappationum aedificat: regionem memoriae humilis identice mappatam pro bring-up primo, et mappationes specificas partis superioris pro obiectis quibus nucleus statim utetur.

Implementatio hodierna primum 1 GiB paginis 2 MiB identice mappat et fenestras MMIO APIC quoque identice mappat. Deinde intervalla virtualia partis superioris pro nucleo, obiectis dynamicis oneratis, blobs boot requisitis, blob handoff, framebuffer, et acervo bootstrap mappat. Hoc satis est ut nucleus in spatio inscriptionum quod exspectat incipiat.

Tabulae paginarum non sunt systema finale memoriae virtualis. Pons sunt quo nucleus exsequi, handoff validare, statum CPU primum instituere, et verum ambitum nuclei atque spatii usoris aedificare incipere potest. Pons tamen rectus esse debet: si pagina introitus nuclei non mappata est, machina statim fault facit; si blob handoff in inscriptione virtuali falsa mappatur, nucleus inepta legit; si acervus deest, introitus deficit antequam codex Rust multum facere possit.

Cur nucleus partis superioris?⌗

EriX nucleum in parte superiore spatii inscriptionum virtualis intrat. Hoc significat nucleum in inscriptionibus virtualibus altis currere, non solum in intervallo humili identice mappato alligari et exsequi. Hoc consilium nuclei commune est quia nucleo regionem inscriptionum virtualium stabilem dat, independentem ab eo ubi memoria physica allocata est.

Layout partis superioris etiam spatium virtuale nuclei a regionibus ordinariis spatii usoris separat et sinit nucleum suas mappationes praesentes servare per mutationes posteriores spatii inscriptionum, dum mappationes spatii usoris per munus variari possunt. Layout inscriptionum totum exemplar securitatis solum non cogit, sed limitem sustinet memoriam nuclei a memoria processus ordinaria distinguendo.

In EriX, bootloader responsabilis est ut introitus primus partis superioris possibilis fiat. Nucleum secundum inscriptiones virtuales ELF onerat, illas inscriptiones virtuales ad paginas physicas allocatas mappat, acervum bootstrap in parte superiore creat, blob handoff ad inscriptionem partis superioris notam mappat, cr3 onerat, et ad punctum introitus nuclei salit.

In saltu, pactum x86_64 hodiernum consulto parvum et explicitum est. Bootloader tantum statum praebet quo nucleus indiget ut handoff validare et suum statum CPU primum instituere incipiat:

  • ABI SysV
  • rdi indicem handoff continet
  • rsp ad acervum bootstrap cum alignment exspectato demonstrat
  • paginatio activa est
  • imperium non redit

Haec ABI consilio parva est. Quo minus status implicitus introitui nuclei necessarius est, eo facilius terminus auditur.

In nucleum intrare⌗

In parte nuclei, introitus incipit antequam totum runtime nuclei existat. Nucleus dynamicus erix_dynlink_entry exponit, quod in iter nuclei primum cum indice handoff intrat, et primum opus defensivum est potius quam politica grave.

Nucleus interruptiones disable facit, exitum serialem primum initializat, probat indicem handoff non nullum esse, magnitudinem handoff ex capite legit, magnitudinem maximam handoff imponit, et deinde totum blob per lib-handoff validat. Post validationem structuralem, nucleus suas probationes politicae applicat:

  • architectura x86_64 esse debet
  • platforma UEFI esse debet
  • build ID vacuum esse non debet
  • tabulae catalogi dynamici interne cohaerere debent
  • nomina obiectorum dynamicorum, hashes, segmenta, dependentiae, et intervalla store ante usum validari debent

Bootloader handoff iam aedificavit, sed nucleus tamen id validat. Componentes fideles pacta praeterire non possunt solum quia alius component fidus data produxit. Ratio handoff versionati est ut utraque pars exacte consentire possit quid translatum sit.

Tantum postea nucleus altius in initializationem primam movetur: institutionem GDT, institutionem IDT, constitutionem itineris syscall, initializationem consolae primae optionalem, et tandem orchestrationem bootstrap pro primo munere root. Nucleus paulatim nucleus fit, et primum quod facit est terram sub pedibus inspicere.

Boot translatio auctoritatis est⌗

Tentatio est boot describere ut “nucleum onera et sali”. Technice verum est, sed punctum consilii systematis operativi praeterit. In EriX, boot translatio auctoritatis est: auctoritas firmware fit facta boot explicita, bytes imaginis boot fiunt sectiones verificatae, fasciculi ELF fiunt intervalla exsecutabilia mappata, blobs fiunt descriptoria modulorum non exsecutabilium, tabulae memoriae firmware fiunt regiones memoriae normalizatae, metadata dynamic-link fit graphus obiectorum terminatus, et status framebuffer fit metadata continuationis.

Omne hoc fit blob handoff, et nucleus id blob accipit ac decernit an acceptabile sit. Tantum deinde machinae opes in obiecta nuclei, facultates, spatia inscriptionum, endpoints, et primum munus spatii usoris vertere incipere potest. Ideo processus boot ad disputationem de systematibus operativis facultatum pertinet: exemplar facultatum non post boot quasi additamentum incipit; pendet ex eo ne boot auctoritatem ambientem clam inferat.

Bootloader non simpliciter dicere debet se quaedam oneravisse. Dicere debet exacte quid oneraverit, ubi sit, quid sit, quomodo verificatum sit, et quae facta platformae observaverit. Hoc discrimen est inter saltum et handoff.

Quae EriX extra bootloader servat⌗

Bootloader potens est quia mature currit, et ideo parvus manere debet. EriX non vult bootloader politicam runtime decernere: non debet decernere quod officium politicam memoriae possideat, quomodo processus supervisi sint, quomodo drivers administrentur, aut quomodo systemata fasciculorum componantur.

Istae decisiones ad nucleum et officia systematis in spatio usoris pertinent. Officium bootloader angustius est: artefactum boot validare, minimum ambitum exsecutionis parare, describere quid fecerit, et imperium transferre.

Haec linea ad magnitudinem TCB pertinet. Bootloader cum pluribus functionalitatibus non automatice melior est, quia omnis functionalitas in boot primo est codex qui currit antequam nucleus eum segregare possit. Omnis parser, iter fallback, modus interactives, et exceptio politicae quantitatem morum fidelium auget quae recta esse debent antequam systema incipiat.

Prospiciendum⌗

Hic articulus boot.img praecipue ut continens verificatum tractavit. Proximus gradus est hoc continens aperire et consilium eius directe inspicere.

Proximus articulus formam boot.img EriX explicabit: cur systema imagine unificata utatur, quomodo sectiones disponantur, quae metadata portentur, et quomodo forma artefacta boot reproducibilia et deterministica sustineat.