redox-os issueshttps://gitlab.redox-os.org/groups/redox-os/-/issues2023-12-07T15:29:58Zhttps://gitlab.redox-os.org/redox-os/syscall/-/issues/34Update `bitflags` to v22023-12-07T15:29:58ZdaxpeddaUpdate `bitflags` to v2As in the title.
See https://github.com/bitflags/bitflags/releases/tag/2.0.0.
This is a breaking change as it modifies the exposed API.As in the title.
See https://github.com/bitflags/bitflags/releases/tag/2.0.0.
This is a breaking change as it modifies the exposed API.https://gitlab.redox-os.org/redox-os/kernel/-/issues/135Replace physalloc/physfree with a "physically contiguous" mmap or madvise flag2023-12-16T18:01:11ZJacob Lorentzon4ldo2@protonmail.comReplace physalloc/physfree with a "physically contiguous" mmap or madvise flagPhysalloc and physfree offer no checking of ownership, and while there could be "physical grants" to track raw physical allocations from drivers, it would be much cleaner to integrate it with the existing mmap code.Physalloc and physfree offer no checking of ownership, and while there could be "physical grants" to track raw physical allocations from drivers, it would be much cleaner to integrate it with the existing mmap code.https://gitlab.redox-os.org/redox-os/redox/-/issues/1396Raspi3b+ support2023-10-27T13:41:34ZIvan TanRaspi3b+ supportThis issue cover what is necessary for running Redox OS in raspi3b+(ARM64 device)
* 1. Build u-boot to run `bootloader.efi` with the user-specific Device Tree Blob(DTB) file.
* 2. Pass the dtb file to Redox's kernel.
* 3. Redox's kernel ...This issue cover what is necessary for running Redox OS in raspi3b+(ARM64 device)
* 1. Build u-boot to run `bootloader.efi` with the user-specific Device Tree Blob(DTB) file.
* 2. Pass the dtb file to Redox's kernel.
* 3. Redox's kernel parses dtb file.
* 4. Redox installer support adding files to specific partition, for example, writing the dtb file `/DTB/BROADCOM/bcm2837-rpi-3-b.dtb` to EFI partition.
* 5. Commands for running and debugging Redox OS in qemu.
* 6. Steps for running Redox OS in read hardware(raspi3b+).
# uboot
demo: https://gitlab.redox-os.org/Ivan/u-boot/-/tree/redox/v2022.07?ref_type=heads
# bootloader
demo: https://gitlab.redox-os.org/Ivan/bootloader/-/tree/ivan/raspi3b?ref_type=heads
# kernel
demo: https://gitlab.redox-os.org/Ivan/kernel/-/tree/ivan/raspi3b?ref_type=heads
# installer
demo: https://gitlab.redox-os.org/Ivan/installer/-/tree/ivan/raspi3b?ref_type=heads
https://gitlab.redox-os.org/Ivan/redox_firmware.git
Installation(run as root):
```
#!/bin/sh
#
mount -o loop,offset=$((2048*512)) build/aarch64/server/harddrive.img /mnt/efi_boot
mkdir -p /mnt/efi_boot/dtb/broadcom/
dtc -I dts -O dtb ~/code/redox_project/redox_firmware/platform/raspberry_pi/rpi3/bcm2837-rpi-3-b-plus.dts > bcm2837-rpi-3-b-plus.dtb
cp bcm2837-rpi-3-b-plus.dtb /mnt/efi_boot/dtb/broadcom/bcm2837-rpi-3-b.dtb
umount /mnt/efi_boot
exit
```
# cookbook
demo: https://gitlab.redox-os.org/Ivan/cookbook/-/tree/ivan/raspi3b?ref_type=heads
# qemu
QEMU emulator version 7.2.3 (v7.2.3) or upper.
# command
run:
```
SDL_VIDEO_X11_DGAMOUSE=0 qemu-system-aarch64 -M raspi3b -smp 4,cores=1 \
-serial stdio -display none\
-kernel build/aarch64/server/u-boot.bin \
-sd build/aarch64/server/harddrive.img
```
run with debug:
```
SDL_VIDEO_X11_DGAMOUSE=0 qemu-system-aarch64 -M raspi3b -smp 4,cores=1 \
-serial stdio -display none\
-kernel build/aarch64/server/u-boot.bin \
-sd build/aarch64/server/harddrive.img \
-chardev socket,path=/tmp/gdb-socket,server=on,wait=off,id=gdb0 -gdb chardev:gdb0 -S
```
gdb:
```
./prefix/aarch64-unknown-redox/relibc-install/bin/aarch64-unknown-redox-gdb --eval-command="target remote /tmp/gdb-socket"
```
# Real hardware support
TBDhttps://gitlab.redox-os.org/redox-os/drivers/-/issues/37vesad: Implement Debug for DisplayScheme2023-08-07T06:54:20ZRon Williamsvesad: Implement Debug for DisplaySchemeWhen debugging a problem with `vesad`, I hacked a version of `Debug` for `DisplayScheme` and found it extremely helpful. It would be good to implement this permanently. Be careful not to include the screen buffer.When debugging a problem with `vesad`, I hacked a version of `Debug` for `DisplayScheme` and found it extremely helpful. It would be good to implement this permanently. Be careful not to include the screen buffer.https://gitlab.redox-os.org/redox-os/drivers/-/issues/36vesad: Error in width/height calculation when switching from TextScreen to Gr...2023-08-07T07:08:55ZRon Williamsvesad: Error in width/height calculation when switching from TextScreen to GraphicsScreenIn `vesad/src/scheme.rs`, `SchemeMut for DisplayScheme`, `fn write`, if the command is `Activate` and the mode is `Graphic`, a new `GraphicScreen` is created. However, the `width()` and `height()` are taken from the previous Screen type,...In `vesad/src/scheme.rs`, `SchemeMut for DisplayScheme`, `fn write`, if the command is `Activate` and the mode is `Graphic`, a new `GraphicScreen` is created. However, the `width()` and `height()` are taken from the previous Screen type, which are calculated in pixels for `GraphicsScreen` and in characters for `TextScreen`. So if the previous screen type was `TextScreen`, the width and height are now a fraction of the correct values.
Note that the original `TextScreen` is created with `width` and `height` fields calculated in pixels. It's not clear to me if those fields should always be in pixels and the `width()` and `height()` functions should convert to character sizes. Either way, it is not consistent and should be corrected and documented.
Since the `Screen` struct is `Box<dyn Screen>`, the information is lost about whether the `Screen` is a `TextScreen` or a `GraphicsScreen`, so either the calculations need to be in pixels always, or there needs to be an addition to the `Screen` trait to provide `width_in_pixels()` and `height_in_pixels()`.https://gitlab.redox-os.org/redox-os/orbital/-/issues/70Wrong screen size when running on real hardware2023-08-07T07:09:24ZRon WilliamsWrong screen size when running on real hardwareWhen running natively on a low-end HP laptop, I select the screen size, the system boots somewhat normally, but the Orbital display is a small rectangle in the upper left of the screen, roughly 200px wide by 50px high.When running natively on a low-end HP laptop, I select the screen size, the system boots somewhat normally, but the Orbital display is a small rectangle in the upper left of the screen, roughly 200px wide by 50px high.https://gitlab.redox-os.org/redox-os/kernel/-/issues/134Move address space virtual address range allocation to userspace2023-10-31T14:56:21ZJacob Lorentzon4ldo2@protonmail.comMove address space virtual address range allocation to userspaceThere's currently a lot of code in the kernel dealing solely with managing user address space virtual address allocation. A more minimal kernel would only store the grants and their ranges, which would (1) allow userspace to implement gu...There's currently a lot of code in the kernel dealing solely with managing user address space virtual address allocation. A more minimal kernel would only store the grants and their ranges, which would (1) allow userspace to implement guard pages, (2) remove the need for `mmap_min`, and (3) simplify mmap and similar operations, so that they always behave as `MAP_FIXED_NOREPLACE`.https://gitlab.redox-os.org/redox-os/relibc/-/issues/181Not all memory is reclaimed when pthreads are destroyed2023-08-02T12:47:40ZJacob Lorentzon4ldo2@protonmail.comNot all memory is reclaimed when pthreads are destroyedMost notably, the stack is not freed in pthread_join or the implicit possibly-later-called pthread_detach destructor. The TCB doesn't appear to be either.
[This branch](https://gitlab.redox-os.org/4lDO2/relibc/-/commits/fix_memleak) fix...Most notably, the stack is not freed in pthread_join or the implicit possibly-later-called pthread_detach destructor. The TCB doesn't appear to be either.
[This branch](https://gitlab.redox-os.org/4lDO2/relibc/-/commits/fix_memleak) fixes part of it, but it seems like there are leaks elsewhere too.https://gitlab.redox-os.org/redox-os/relibc/-/issues/180Calling init multiple times cause leak of PTHREAD_SELF.packet_data_ptr leaks ...2023-10-07T09:14:38ZShuran SunCalling init multiple times cause leak of PTHREAD_SELF.packet_data_ptr leaks if returning errorsin https://gitlab.redox-os.org/redox-os/relibc/-/blob/master/src/pthread/mod.rs#:~:text=26-,pub%20unsafe%20fn%20init()%20%7B,%7D,-44
```Rust
/// Called only by the main thread, as part of relibc_start.
pub unsafe fn init() {
let obj ...in https://gitlab.redox-os.org/redox-os/relibc/-/blob/master/src/pthread/mod.rs#:~:text=26-,pub%20unsafe%20fn%20init()%20%7B,%7D,-44
```Rust
/// Called only by the main thread, as part of relibc_start.
pub unsafe fn init() {
let obj = Box::into_raw(Box::new(Pthread {
waitval: Waitval::new(),
has_enabled_cancelation: AtomicBool::new(false),
has_queued_cancelation: AtomicBool::new(false),
flags: PthreadFlags::empty().bits().into(),
//index: FIRST_THREAD_IDX,
// TODO
stack_base: core::ptr::null_mut(),
stack_size: 0,
os_tid: UnsafeCell::new(Sys::current_os_tid()),
}));
PTHREAD_SELF.set(obj);
}
```
`PTHREAD_SELF` is a static mutable variable and can be overwritten when mistakenly calling `init` multiple times, causing memory leak.
It may be better to add guard inside the `init` function.
https://gitlab.redox-os.org/redox-os/relibc/-/blob/master/src/header/netdb/lookup.rs#L71
https://gitlab.redox-os.org/redox-os/relibc/-/blob/master/src/header/netdb/lookup.rs#L182
`packet_data_ptr` points to object on the heap through `Box::into_raw(packet_data_box)` . The heap memory is leaked when the unsafe block in line 81 and line 195 returns an error.https://gitlab.redox-os.org/redox-os/relibc/-/issues/179Calling init multiple times can cause2023-08-02T17:25:07ZShuran SunCalling init multiple times can causehttps://gitlab.redox-os.org/redox-os/redox/-/issues/1395(Feature request) Recipe categories on the Cookbook configuration2023-11-05T21:30:57ZRibbon(Feature request) Recipe categories on the Cookbook configurationAfter the implementation of the recipe categories we can add a way to build any specified folder inside the Cookbook configuration (`config/your-cpu-arch/your-config.toml`.
We could use the recipe syntax to specify the folder, for examp...After the implementation of the recipe categories we can add a way to build any specified folder inside the Cookbook configuration (`config/your-cpu-arch/your-config.toml`.
We could use the recipe syntax to specify the folder, for example: `folder-name = {}` (if it's technically possible).
The build system will build all recipes inside the specified folder, it's more easy to maintain and less error-prone, as we don't need to insert each new recipe.https://gitlab.redox-os.org/redox-os/redoxfs/-/issues/42Tooling2023-07-18T18:12:01ZRibbonToolingThis issue will cover the necessary tools for RedoxFS.
- [ ] Volume management
- [ ] Partition management
- [ ] Encryption management
- [ ] Compression management
- [ ] Enable/disable volumes
- [ ] Mount/unmount devicesThis issue will cover the necessary tools for RedoxFS.
- [ ] Volume management
- [ ] Partition management
- [ ] Encryption management
- [ ] Compression management
- [ ] Enable/disable volumes
- [ ] Mount/unmount deviceshttps://gitlab.redox-os.org/redox-os/kernel/-/issues/133Orbital exits with "invalid argument"2023-08-04T06:13:34ZRon WilliamsOrbital exits with "invalid argument"On an HP laptop where Orbital previously worked, during boot, Orbital reports `orbital::core::display:48 failed to map display: invalid argument`, and Orbital exits. This appears to be an error code from `syscall::fmap`.
Display size wa...On an HP laptop where Orbital previously worked, during boot, Orbital reports `orbital::core::display:48 failed to map display: invalid argument`, and Orbital exits. This appears to be an error code from `syscall::fmap`.
Display size was `1366x768`. `1024x768` appears to work.
Edit: This is reproducible on QEMU, choose resolution 1600x900 and Orbital will exit with the same error.https://gitlab.redox-os.org/redox-os/drivers/-/issues/35Reduce code duplication2023-07-18T09:04:46ZJacob Lorentzon4ldo2@protonmail.comReduce code duplicationLots of drivers unnecessarily contain lots of duplicate code, particularly boilerplate code for scheme handling and other process management, and also the MSI/MSI-X code. Additionally, many drivers provide their own wrappers for physmap/...Lots of drivers unnecessarily contain lots of duplicate code, particularly boilerplate code for scheme handling and other process management, and also the MSI/MSI-X code. Additionally, many drivers provide their own wrappers for physmap/physunmap.https://gitlab.redox-os.org/redox-os/orbital/-/issues/69Orbital exits with "invalid argument"2023-07-18T17:25:56ZRon WilliamsOrbital exits with "invalid argument"On an HP laptop where Orbital previously worked, during boot, Orbital reports `orbital::core::display:48 failed to map display: invalid argument`, and Orbital exits. This appears to be an error code from `syscall::fmap`.
Display size wa...On an HP laptop where Orbital previously worked, during boot, Orbital reports `orbital::core::display:48 failed to map display: invalid argument`, and Orbital exits. This appears to be an error code from `syscall::fmap`.
Display size was `1366x768`. `1024x768` appears to work.
Edit: This is reproducible on QEMU, choose resolution 1600x900 and Orbital will exit with the same error.https://gitlab.redox-os.org/redox-os/redox/-/issues/1394CI testing for packages2023-10-27T13:44:24ZRibbonCI testing for packagesUsing CI tests for packages we can have a stable rolling release system, Void Linux does this, being one of the most stable rolling release Linux distributions of the world.
- [Void Linux continuous integration system](https://build.voi...Using CI tests for packages we can have a stable rolling release system, Void Linux does this, being one of the most stable rolling release Linux distributions of the world.
- [Void Linux continuous integration system](https://build.voidlinux.org/)https://gitlab.redox-os.org/redox-os/relibc/-/issues/178Rustify2024-01-12T17:50:49ZRibbonRustifyThis issue covers the relibc parts that benefit from using a Rustier implementation, in order to be less prone to memory unsafety and to some extent logic bugs.
- [ ] [Rusty error handling](https://gitlab.redox-os.org/redox-os/relibc/-/...This issue covers the relibc parts that benefit from using a Rustier implementation, in order to be less prone to memory unsafety and to some extent logic bugs.
- [ ] [Rusty error handling](https://gitlab.redox-os.org/redox-os/relibc/-/issues/176)
- [ ] [Rust's libm port](https://gitlab.redox-os.org/redox-os/relibc/-/issues/154)
- [x] dlmallochttps://gitlab.redox-os.org/redox-os/redox/-/issues/1393Exploit mitigations2023-10-27T11:07:14ZRibbonExploit mitigationsThis issue will cover the mandatory and optional exploit mitigations for Redox.
As Redox is written in Rust there's memory-safety though the compiler, thus it might make sense to disable most exploit mitigations, at least by default.
B...This issue will cover the mandatory and optional exploit mitigations for Redox.
As Redox is written in Rust there's memory-safety though the compiler, thus it might make sense to disable most exploit mitigations, at least by default.
But Redox is not fully safe Rust because many crates rely on less thoroughly checked unsafe, such as when heavily using FFI. Therefore, it might make more sense to enable mitigations for such programs, as well as for C/C++ programs, even though unsafe Rust is generally still safer than C/C++.
Exploit mitigations specific to C/C++ memory errors are unnecessary for safe Rust code.
### Criteria
The exploit mitigations on this issue must follow some criteria.
1. The mitigation is needed for microkernel-based systems?
2. If the mitigation is cheap (low performance penault) and the security benefit is considerable, it can be enabled by default.
3. Classify if it's a compiler, manual system-wide/some programs or x86-specific mitigation.
### Mitigations
This list will filter the exploit mitigations.
- Address Space Layout Randomization - userspace
- ~~Kernel Address Space Layout Randomization~~ probably overkill for a microkernel; seL4 for example uses `-static -fno-pie -fno-pic`
- Position-Independent Executables - compiler-based
- RELRO
- BIND_NOW
- SEGVGUARD (ASLR brute force protection)
- W^X (memory mappings and switching pages)
- SROP
- Trusted Path Execution
- SafeStack
- Non-Cross-DSO Control-Flow Integrity
- Retpoline - Spectre mitigation for monolithic kernels?
### Implementations
This list will track the exploit mitigations implementation.
- [x] SMAP - x86-specific, manual system-wide
- [x] SMEP - x86-specific, manual system-wide
- [x] Zero-initialized userspace stack - manual system-wide
- [ ] Read-only pages where necessary - manual?
- [ ] IP ID randomization - netstack or smoltcp? manual.
- [ ] Temporary IPv6 addresses - netstack or smoltcp? manual.https://gitlab.redox-os.org/redox-os/kernel/-/issues/131Support 32-bit userspace when using 64-bit kernels2023-07-08T09:22:45ZJacob Lorentzon4ldo2@protonmail.comSupport 32-bit userspace when using 64-bit kernelshttps://gitlab.redox-os.org/redox-os/kernel/-/issues/130 needs to be fixed, and there probably needs to be two permanent GDT entries, for FS and GS.
It might be possible to allow enabling/disabling compatibility mode, at compile time.https://gitlab.redox-os.org/redox-os/kernel/-/issues/130 needs to be fixed, and there probably needs to be two permanent GDT entries, for FS and GS.
It might be possible to allow enabling/disabling compatibility mode, at compile time.https://gitlab.redox-os.org/redox-os/kernel/-/issues/130x86 segment registers are not saved/restored2023-08-08T09:50:44ZJacob Lorentzon4ldo2@protonmail.comx86 segment registers are not saved/restoredOn x86, segment registers are currently not saved and restored when context switching. Since userspace is capable of loading available selector values into segment registers,
- CS is immutable, everything but GDT_USER_CODE #GPs
- SS (wi...On x86, segment registers are currently not saved and restored when context switching. Since userspace is capable of loading available selector values into segment registers,
- CS is immutable, everything but GDT_USER_CODE #GPs
- SS (will be) immutable, can only be set to GDT_USER_DATA
- DS, ES, FS, and GS, can be either NULL or GDT_USER_DATA,
at most four bits of data can be leaked between contexts when switching.