{"id":31205342,"url":"https://github.com/rustlanges/rle-boot-protocol","last_synced_at":"2026-02-13T23:31:46.121Z","repository":{"id":310559064,"uuid":"1039261467","full_name":"RustLangES/rle-boot-protocol","owner":"RustLangES","description":"Modern boot protocol designed by rust lang es","archived":false,"fork":false,"pushed_at":"2025-08-22T19:49:51.000Z","size":7,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2025-09-20T18:11:26.949Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/RustLangES.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2025-08-16T20:32:19.000Z","updated_at":"2025-08-22T19:49:55.000Z","dependencies_parsed_at":"2025-08-18T22:24:44.458Z","dependency_job_id":"294940f6-dc5c-4c83-bb9e-b23bfad3ac71","html_url":"https://github.com/RustLangES/rle-boot-protocol","commit_stats":null,"previous_names":["rustlanges/rle-boot-protocol"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/RustLangES/rle-boot-protocol","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/RustLangES%2Frle-boot-protocol","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/RustLangES%2Frle-boot-protocol/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/RustLangES%2Frle-boot-protocol/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/RustLangES%2Frle-boot-protocol/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/RustLangES","download_url":"https://codeload.github.com/RustLangES/rle-boot-protocol/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/RustLangES%2Frle-boot-protocol/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29423534,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-13T22:20:51.549Z","status":"ssl_error","status_checked_at":"2026-02-13T22:20:49.838Z","response_time":78,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-09-20T17:59:58.402Z","updated_at":"2026-02-13T23:31:46.101Z","avatar_url":"https://github.com/RustLangES.png","language":null,"readme":"# Rle boot protocol\n\nRLE boot protocol is a standard aimed at providing a strict method for communicating information from the bootloader to the kernel. It is based on standards such as Limine’s, although it adds its own elements, and the ones taken from Limine are modified to adapt to the vision of the boot protocol.\n\nRLE has the philosophy of being simple, flexible, and pedantic. Any implementation of RLE can be added to the repository as long as it complies with the standard. Any type of feature is welcome; this is done with the aim of avoiding fragmentation, although it must first be submitted as an issue. If you want to contribute to RLE, please read CONTRIBUTING.md\n\n# Note\n\nAll structures are packed. Look up how to mark a structure as packed in your programming language. In languages like Rust, mark your structures that interact with the protocol using ``#[repr(C, packed)]``\n\nThis specification for structures uses the following format name: type which can be easily adapted to C as type name. For example, if a part of the specification uses ``num: u32``, it can be adapted to ``uint32_t num``.\n\n# Revisions\n\nThe protocol manages the version in which the kernel is to boot. In this case—similar to Limine—it is handled as follows: `1` (there is no default selection, so the kernel must explicitly know which protocol version it intends to use).\n\nThe `.revision` section must be present and contain the following list:\n```\n[ 0xA3F1C7D4B9826E5F, 0x7D4E9B3A1C6F8D20, BASE_REVISION_NUMBER ]\n```\n\nThis list consists of `u64` (unsigned 64‑bit) integers. The bootloader must read this section, verify that the two magic numbers are correct, and then boot the kernel using the version specified by `BASE_REVISION_NUMBER`.\n\n# Requests/Response\n\nRLE agrees with Limine that requests are an excellent way to obtain data from the bootloader, and for developer convenience we use requests. A simple way to define requests is that they are hooks to tell the bootloader to look for information requested by the kernel. An important detail is that there can only be one request of the same type; if the bootloader finds two requests, it must refuse to boot.\n\nAll requests, including the start and end markers, go in the .requests section.\n\nAll of this is done through structures, which usually follow this base. Some may add more information, which will be documented later.\n\n```\nid: u64 // 64-bit unsigned magic number used by the bootloader to recognize what information to retrieve\nstate: RequestState // note: this is u8\nresponse: u64 // address pointing to the response header\n```\n\nIf the request could not be completed successfully, then the bootloader must leave everything as it was (except for state, which must be modified to indicate the cause).\n\nIf everything goes well, the bootloader must fill the response field with a VALID and readable memory address that contains the header.\n\nRequestState indicates the status of the request. Its purpose is to help the kernel understand why the response is invalid. Its entries are as follows:\n```\nNONE = 0 // this is not used by the bootloader but by the kernel when defining a structure\nOK = 1  // everything went well\nUNSUPPORTED = 2 // the request is not supported by the hardware\nUNKNOWN_ID = 3  // the request's magic number is invalid\n```\nAll enum values are u8 (unsigned 8-bit integers).\n\n# Start/end markers\nRequests will only begin to be read when a start marker is present; everything before the start marker will be ignored. The end marker defines up to where the requests will be read—everything outside these two markers will be disregarded.\n\nAn important clarification is that there can only be one start marker and one end marker. If the bootloader encounters more than one of either marker, it must refuse to boot.\n\nThe correct way to use requests is as follows:\n```\nstart_marker\n// requests\nend_marker\n```\n## Start header\nThe start header shall consist of a sequence of four `u64` (unsigned 64‑bit) integers, in the following order:\n```\n[\n  0xC7A1D3F4B9826E5F\n  0x9E4B7C2A1F6D8B30\n  0x5D3F8A7E2C1B9D44\n  0xA84E1B3C7D9F2036\n]\n```\n\n## End header\nThe end header  shall consist of a sequence of four `u64` (unsigned 64‑bit) integers, in the following order:\n```\n[\n  0xF2B4C8D1A73E9F60\n  0x3D9A7E4B1C58B2E7\n  0x8E1F6C3A9B04D7A2\n  0x7ACD2E9F1348B6C5\n]\n```\n\n# Entry memory layout\n\nThe executable is recommended to be loaded at 0xffffffff80000000. Lower half executables are not allowed, nor are relocations. The kernel must be loaded in the higher half. The bootloader must be responsible for properly configuring the HHDM, and the kernel must be loaded in that region. By convention, the HHDM will be loaded at 0xFFFF800000000000 (on x86_64 architectures). NOTE to the reader: it should be discussed how to handle this for x86.\n\n# Memory regions\n\nThis section defines how memory regions are segmented within the boot protocol. The bootloader does not guarantee a specific order; however, it does ensure that each type accurately represents its intended purpose. For instance, the bootloader must guarantee to the executable that any entry marked as USABLE is indeed free and does not contain critical information.\n\nA memory entry is marked as:\n\n```\nRESERVED = 0  // reserved by the firmware, not usable\nBAD_MEMORY = 1  // memory that cannot be used due to physical damage, not usable\nRESPONSES = 2 // the region where the bootloader stores all responses; may be used once the response data is no longer needed\nEXECUTABLES = 3 // contains all kernel-related data, not usable\nMODULES = 4 // contains kernel modules; this region should be omitted if no modules were passed, and may be used after all modules have been read\nUSABLE = 5 // free and usable memory, contains no initial data\nFRAMEBUFFER = 6 // this memory is mapped to the framebuffer, not usable\nACPI_RECLAIMABLE = 7 // memory used by ACPI; may be reclaimed once ACPI tables are no longer in use\nACPI_NVS = 8 // this section is permanently used by ACPI, cannot be used\n```\n\n\n# Machine state at entry\n\nAdditionally, the bootloader must load a GDT; the IDT is not the responsibility of the bootloader and MUST NOT be loaded by it. The executable must ensure that a valid IDT is loaded.\n\nThe GDT configuration is the same as in limine:\n\nNull descriptor 16-bit code descriptor. Base = 0, limit = 0xffff. Readable. 16-bit data descriptor. Base = 0, limit = 0xffff. Writable. 32-bit code descriptor. Base = 0, limit = 0xffffffff. Readable. 32-bit data descriptor. Base = 0, limit = 0xffffffff. Writable. 64-bit code descriptor. Base and limit irrelevant. Readable. 64-bit data descriptor. Base and limit irrelevant. Writable.\n\nIF flag, VM flag, and direction flag are cleared on entry; other flags are undefined.\n\nPG is enabled (cr0), PE is enabled (cr0), PAE is enabled (cr4), WP is enabled (cr0), LME is enabled (EFER), NX is enabled (EFER) if available. If 5-level paging is requested and available, then 5-level paging is enabled (LA57 bit in cr4).\n\nThe A20 gate is opened.\n\nLegacy PIC (if available) and IO APIC IRQs (only those with delivery mode fixed (0b000) or lowest priority (0b001)) are all masked.\n\nIn EFI systems, boot services must be exited before booting.\n\nrsp points to the stack; the bootloader must ensure to the kernel that rsp is a valid address. The default size is 64 KiB, but the kernel may specify its own stack size via a request.\n\n## TODO: requests list\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frustlanges%2Frle-boot-protocol","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frustlanges%2Frle-boot-protocol","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frustlanges%2Frle-boot-protocol/lists"}