Initial import

This commit is contained in:
Jozef Nagy 2025-01-20 21:52:47 +01:00
commit 94aad4b8e1
Signed by untrusted user who does not match committer: crz
GPG key ID: 459A4811CEAC7068
77 changed files with 4414 additions and 0 deletions

45
docs/CODE_OF_CONDUCT.md Normal file
View file

@ -0,0 +1,45 @@
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project email address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project maintainer using any of the [private contact addresses](https://github.com/aurixos/os#support). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 1.4, available at <https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>
For answers to common questions about this code of conduct, see <https://www.contributor-covenant.org/faq>

46
docs/CONTRIBUTING.md Normal file
View file

@ -0,0 +1,46 @@
# Contributing
When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.
Please note we have a [code of conduct](CODE_OF_CONDUCT.md), please follow it in all your interactions with the project.
## Development environment setup
To set up a development environment, follow these steps:
1. Clone the repo
```sh
git clone https://github.com/aurixos/os
```
2. Install all required packages
```sh
brew bundle
```
If you don't have Homebrew installed, or don't want to download all optional packages, look at the [Brewfile](../Brewfile) and install all packages manually.
## Issues and feature requests
You've found a bug in the source code, a mistake in the documentation or maybe you'd like a new feature? You can help us by [submitting an issue on GitHub](https://github.com/aurixos/os/issues). Before you create an issue, make sure to search the issue archive -- your issue may have already been addressed!
Please try to create bug reports that are:
- _Reproducible._ Include steps to reproduce the problem.
- _Specific._ Include as much detail as possible: which version, what environment, etc.
- _Unique._ Do not duplicate existing opened issues.
- _Scoped to a Single Bug._ One bug per report.
**Even better: Submit a pull request with a fix or new feature!**
### How to submit a Pull Request
1. Search our repository for open or closed
[Pull Requests](https://github.com/aurixos/os/pulls)
that relate to your submission. You don't want to duplicate effort.
2. Fork the project
3. Create your feature branch (`git checkout -b feat/amazing_feature`)
4. Commit your changes (`git commit -m 'feat: add amazing_feature'`) AurixOS uses [conventional commits](https://www.conventionalcommits.org), so please follow the specification in your commit messages.
5. Push to the branch (`git push origin feat/amazing_feature`)
6. [Open a Pull Request](https://github.com/aurixos/os/compare?expand=1)

16
docs/SECURITY.md Normal file
View file

@ -0,0 +1,16 @@
# Security Policy
## Reporting a Vulnerability
If there are any vulnerabilities in **AurixOS**, don't hesitate to _report them_.
1. Contact [schkwve@gmail.com](mailto:schkwve@gmail.com).
2. Describe the vulnerability.
If you have a fix, that is most welcome -- please attach or summarize it in your message!
3. We will evaluate the vulnerability and, if necessary, release a fix or mitigating steps to address it. We will contact you to let you know the outcome, and will credit you in the report.
Please **do not disclose the vulnerability publicly** until a fix is released!
4. Once we have either a) published a fix, or b) declined to address the vulnerability for whatever reason, you are free to publicly disclose it.

117
docs/boot/BOOTPROTOCOL.md Normal file
View file

@ -0,0 +1,117 @@
# Aurix Boot Protocol (revision 0.2)
The Aurix Boot Protocol presents a simple and minimal protocol for booting the AurixOS kernel.
> [!NOTE]
> This document is still a work in progress and may contain incomplete information.
## Machine state
- All general purpose registers are zeroed out
- Interrupts are disabled
- Framebuffer is set to the best available video mode (graphics mode if available)
### Architecture-specific
#### x86_64
- Write Protection bit in CR0 is disabled
- GDT is set up as follows:
| Name | Base | Limit | Flags |
| :--------------------- | :----: | :----------: | :--------: |
| NULL Descriptor | `0x00` | `0x0000` | `0x00` |
| 32-bit Code Descriptor | `0x00` | `0xFFFFFFFF` | Read only |
| 32-bit Data Descriptor | `0x00` | `0xFFFFFFFF` | Read/Write |
| 64-bit Code Descriptor | `0x00` | `0x0000` | Read only |
| 64-bit Data Descriptor | `0x00` | `0x0000` | Read/Write |
## Paging
- ~~If available, 5-level paging is set up (see [Kernel Parameters](#kernel-parameters))~~ 5-level paging is not yet supported in AxBoot
- The memory map is identity mapped
- Kernel is mapped to the higher half if desired
## Kernel parameters
The bootloader passes `abp_boot_info` structure as a parameter to the kernel.
A non-zero value in `lvl5_paging` indicates that 5-level paging has been set up and is available.
```c
struct abp_boot_info {
// General
char *bootloader_name;
char *bootloader_version;
char *protocol_version;
// ACPI and SMBIOS
struct acpi_info acpi;
struct smbios_info smbios;
// Memory
struct memory_map *memmap;
int lvl5_paging;
// Framebuffer
struct framebuffer_info framebuffer;
};
```
## ACPI and SMBIOS
These structures contain pointers to the Root System Description Pointer (ACPI) and System Management BIOS Entry Point (SMBIOS).
If `is_valid` is set to a non-zero value, the pointer is guaranteed to be valid.
Otherwise, the pointer is set to NULL and should not be used.
```c
struct acpi_info {
uint8_t is_valid;
void *rsdp;
};
```
```c
struct smbios_info {
uint8_t is_valid;
void *entry_point;
};
```
## Memory map
The memory map is a singly linked list containing the physical address of the entry, its length and type, as well as a pointer to the next entry.
Entries are guaranteed to not overlap with each other, and sorted by base address from low to high.
```c
#define ABP_MEMORY_RESERVED 0xf0
#define ABP_MEMORY_USABLE 0xf1
#define ABP_MEMORY_BOOTLOADER_RECLAIMABLE 0xf2
#define ABP_MEMORY_MMIO 0xf3
#define ABP_MEMORY_ACPI_NVS 0xf4
#define ABP_MEMORY_ACPI_RECLAIMABLE 0xf5
#define ABP_MEMORY_KERNEL 0xf7
#define ABP_MEMORY_NOT_USABLE 0xff
struct memory_map {
uint64_t base;
uint64_t length;
uint64_t type;
struct memory_map *next;
};
```
## Framebuffer
```c
struct framebuffer_info {
void *addr;
uint32_t width;
uint32_t height;
uint16_t bpp;
};
```

51
docs/boot/CONFIG.md Normal file
View file

@ -0,0 +1,51 @@
# Soapine configuration
To work and do what you told it to do, Soapine uses a configuration file.
## Location
Soapine will search for the configuration in:
* `(boot partition)\soapine.cfg`
* `(boot partition)\soapine\soapine.cfg`
* `(boot partition)\EFI\BOOT\soapine.cfg`
* `(boot partition)\EFI\soapine.cfg`
If Soapine finds the config file, he parses it and jump to his usual menu. Else, Soapine will display a stop screen saying that you need to fix your configuration
## Accepted value types
* String literal (`"Hello, World!"`)
* Decimal (`2`)
* Hexadecimal (`0x2`)
* Hexadecimal color (`#FFFFFF`)
* Boolean (`true/false`)
## Declarations
Declarations are values that components of Soapine will search for:
If you declare `VERBOSE` with a value of true, Soapine will itself put in verbose mode.
You can do a declaration by writing the name + an equal sign + the value (using the accepted value types), that will make `NAME=VALUE`.
If an unused declaration is provided (for example `FORCE_SOAPINE_TO_LIKE_ME=true`), Soapine will simply ignore it, but it will still be present.
Here are some example declarations:
* `MENU_BRANDING="Raphaël's Custom Soapine!!"` (string literal)
* `MENU_HEADERBAR_BG=#FFFFFF` (Hexadecimal color)
* `MENU_HEADERBAR_MARGIN=1` (decimal)
* `VERBOSE=true` (boolean)
* `LOAD_ADDRESS=0x1000` (hexadecimal)
## Menu entries
Menu entries allow you to show an operating system (that can be loaded with the supported protocols!) on the menu.
They are declared like that:
```c
menu_entry "Project Jupiter" {
};
```
*(yes i decided to give a C-like syntax to it)*
You can put a small number of declarations inside the menu entries. (PROTOCOL, IMAGE_PATH, CMDLINE, RESOLUTION) (Providing the `PROTOCOL` and `IMAGE_PATH` declarations is required for Soapine to boot your OS!)
## Supported declarations
None for now (we just got the config parser working!)
At least, you can still define entries!

10
docs/boot/PHILOSOPHY.md Normal file
View file

@ -0,0 +1,10 @@
# Soapine's philosophy
Soapine is meant to be lightweight, while being useful to everyone:
* Ship the bootloader with multiple features (even the weirdest features)
* Ability to extend the bootloader with ELF extensions: If you wanna write an extension to support PE loading, ***DO IT***.
Soapine is also meant to be customizable:
* You can modify each bit of the bootloader: If you wanna center the headerbar text, you ***CAN***
* You can change the default values in Soapine's source code.

BIN
docs/images/logo.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 60 KiB