redox-os issueshttps://gitlab.redox-os.org/groups/redox-os/-/issues2023-10-29T20:44:40Zhttps://gitlab.redox-os.org/redox-os/kernel/-/issues/129Support syscall62023-10-29T20:44:40ZJacob Lorentzon4ldo2@protonmail.comSupport syscall6Redox currently supports syscall0..=syscall5, i.e. rax+rdi+rsi+rdx+r10+r8, but some future syscalls like preadv2/pwritev2 (and futex?) on 32-bit architectures would need e.g. SYS_PWRITEV2+fd+addr+len+off_lo+off_hi+flags, i.e. 7 args.
Th...Redox currently supports syscall0..=syscall5, i.e. rax+rdi+rsi+rdx+r10+r8, but some future syscalls like preadv2/pwritev2 (and futex?) on 32-bit architectures would need e.g. SYS_PWRITEV2+fd+addr+len+off_lo+off_hi+flags, i.e. 7 args.
The registers Linux uses for that, are
- x86_64: rax, rdi, rsi, rdx, r10, r8, r9
- x86_32: eax, ebx, ecx, ecx, edi, esi, ebp
- aarch64: x8, x0, x1, x2, x3, x4, x5, x6
Might be worth looking into whether supporting full-width syscall return values, on x86/x86_64, by setting the carry flag, improves performance (the BSDs do this IIRC).https://gitlab.redox-os.org/redox-os/redox/-/issues/1383Linux app VMs2023-07-08T02:30:22ZRibbonLinux app VMsSimilar to the Linux driver VMs [issue](https://gitlab.redox-os.org/redox-os/redox/-/issues/1382), the Linux app VMs will make Linux-only programs run on Redox.
Why? some programs rely on Linux kernel technologies/interfaces to work, li...Similar to the Linux driver VMs [issue](https://gitlab.redox-os.org/redox-os/redox/-/issues/1382), the Linux app VMs will make Linux-only programs run on Redox.
Why? some programs rely on Linux kernel technologies/interfaces to work, like containers and filesystems.
FreeBSD and NetBSD have a Linux compatibility layer to run unmodified Linux binaries using their ported Linux kernel API, it's possible because the BSDs design is similar to Linux, thus a kernel module is developed without massive changes.
Even with that kernel module, some Linux programs don't work, this kind of implementation can't be done on Redox without massive changes, because it's a microkernel with much more simplicity.
Filesystems rely more on the kernel APIs than other programs, all development is focused on these APIs, even if you port a filesystem to other OS, it will be hard/time-consuming to adapt the new changes from other OS if it's a big/complex filesystem.
To mitigate this you can use a FUSE driver or a VM, FUSE is an universal API but lack some filesystems and the drivers can be unmaintained easily.
A VM will bring many filesystems and their improvements over the time with a small configuration effort, at the cost of some overhead (can be optimized).
Like the Linux driver VMs proposal, the Linux app VMs can be simple and made for a specific use-case, we can have a specific daemon VM for Flatpak, other for Docker, other for Snappy, etc.
Each daemon VM will be optimized/built for his specific necessities, that way we reduce memory usage, CPU time, bugs and complexity.
### Daemon proposals
- [ ] flatpakd (a VM for Flatpak applications)
- [ ] snappyd (a VM for Snappy applications)
- [ ] dockerd (a VM for Docker applications)
- [ ] podmand (a VM for Podman applications)
- [ ] genericd (a VM for any application)
### Suggestions
- Flatpak, Snappy, Docker and Podman binaries can be static linked to relibc.
- Remove the GNU/Linux userland libraries/tools from VM images.
- We could have an option to have one VM per app.
Using one VM per app we will have the VM crash isolated on the program, but it will use more memory and CPU.https://gitlab.redox-os.org/redox-os/kernel/-/issues/128Time Protection2023-11-01T14:53:25ZFélix FischerTime ProtectionI've been trying to read this paper for quite a while now, but my understanding of operating systems is not good enough yet. It looked very promising though, specially after the avalanche that were Spectre and Meltdown.
Maybe this conce...I've been trying to read this paper for quite a while now, but my understanding of operating systems is not good enough yet. It looked very promising though, specially after the avalanche that were Spectre and Meltdown.
Maybe this concept could be introduced to Redox, as a complement to Memory Protection? If anyone can do it, it's probably you guys. You have Rust on your side.
http://echronos.systems/publications/csiro_full_text//Ge_YCH_19.pdf
Thank you for your time, and stay safe 🌷https://gitlab.redox-os.org/redox-os/kernel/-/issues/127Proper fmap support2023-08-30T20:10:13ZjD91mZM2Proper fmap supportI'd like input on something. As you might have noticed, the fmap support I added to redoxfs (https://gitlab.redox-os.org/redox-os/redoxfs/merge_requests/35 and https://gitlab.redox-os.org/redox-os/redoxfs/merge_requests/36) is horrible. ...I'd like input on something. As you might have noticed, the fmap support I added to redoxfs (https://gitlab.redox-os.org/redox-os/redoxfs/merge_requests/35 and https://gitlab.redox-os.org/redox-os/redoxfs/merge_requests/36) is horrible. It loads in the entire chunk of the file you ask for, and then write the entire chunk on sync.
Unfortunately I only learned how linux does it after I actually got this implemented. What I optimally should do is this:
- Read PAGE_SIZE bytes of the file
- On page fault because it tries to access bytes that have not been loaded, read another page
- Write to the file on sync like normal.
But of course the pointer that the user has can't ever move. Not sure if this means that nothing can ever be reallocated or if it means that some virtual mapping thing needs to be updated to point to the new location.
Linux solves this by finding a chunk in memory that can fit the entire file. Would this be a reasonable approach? How would this even be done, with a new syscall?
Another issue is that the bytes that aren't yet loaded can't be allocated because that wouldn't generate a page fault, but they also cannot be used by another program.https://gitlab.redox-os.org/redox-os/redox/-/issues/1382Linux driver VM optimizations2023-07-12T05:10:33ZRibbonLinux driver VM optimizationsThis issue will cover the optimizations that can be done to the Linux driver VMs.
Linux driver VMs are VMs created to offer driver support for Redox, see how it works:
- The Linux VM access the device though PCI passthrough (the host s...This issue will cover the optimizations that can be done to the Linux driver VMs.
Linux driver VMs are VMs created to offer driver support for Redox, see how it works:
- The Linux VM access the device though PCI passthrough (the host system doesn't need a driver, similar to Qubes OS).
- A Redox bridge program will run on Linux userspace, this bridge will communicate with some Redox host scheme based on the driver type (audio: for sound cards, video: for GPUs).
- The Linux VM will communicate with the bridge and the Redox host will control the device without native drivers.
This is a guest-to-host communication using VirtIO interfaces, because of the virtualization some overhead will exist.
Most operating systems speed up their VMs with a type-2 hypervisor running on the kernel (KVM and Hyper-V, for example), we will use Revirt-U to do that, but more optimizations can be done to reduce CPU cycles and memory usage.
- [ ] Build a separated bridge for each device type or Linux device system.
- `drmd` - GPUs.
- `netd` - network devices (Ethernet).
- `fsd` - filesystems.
- `wifid` - Wi-Fi adapters.
- `audiod` - sound devices.
- `inputd` - mouse/keyboards/gamepads/joysticks.
- `sensord` - sensor drivers.
The userspace part can be minimal or even empty, depending on whether a kernel module is needed/beneficial for communication with the bridged device. Userspace can be empty besides init, which might not have to do anything useful either depending on much how much of the bridging is done by a kernel module.
- [ ] Use a real-time scheduler.
Linux CFS have a multitasking design in mind, as our Linux driver VMs only run the Redox bridge, as well as a few background kthreads, so we can use a monotasking low-latency scheduler to have maximum performance.https://gitlab.redox-os.org/redox-os/syscall/-/issues/33Strict pointer provenance2023-06-27T08:50:59ZniluxvStrict pointer provenanceMuch of the current API violates [strict provenance](https://github.com/rust-lang/rust/issues/95228), for example `syscall::call::fmap` returning a `usize` instead of a pointer. Changing this would obviously be a breaking change, but goo...Much of the current API violates [strict provenance](https://github.com/rust-lang/rust/issues/95228), for example `syscall::call::fmap` returning a `usize` instead of a pointer. Changing this would obviously be a breaking change, but good to keep in mind for the next semver-breaking version bump (i.e. `0.4.0`).https://gitlab.redox-os.org/redox-os/redoxer/-/issues/9rsync is required2023-06-19T03:38:47Zthe ssdrsync is requiredCheck if rsync is installedCheck if rsync is installedhttps://gitlab.redox-os.org/redox-os/rmm/-/issues/3Guarantee L1TF immunity2023-06-14T10:14:43ZJacob Lorentzon4ldo2@protonmail.comGuarantee L1TF immunityL1TF is unconditionally handled on Linux by inverting address bits if PRESENT is cleared. On FreeBSD, it is handled by always reserving page zero, and ensuring the address bits are zeroed for non-PRESENT pages.
RMM probably does this al...L1TF is unconditionally handled on Linux by inverting address bits if PRESENT is cleared. On FreeBSD, it is handled by always reserving page zero, and ensuring the address bits are zeroed for non-PRESENT pages.
RMM probably does this already, but that needs to be properly ensured.https://gitlab.redox-os.org/redox-os/rmm/-/issues/2Remove virt_is_valid?2023-06-14T10:11:15ZJacob Lorentzon4ldo2@protonmail.comRemove virt_is_valid?https://gitlab.redox-os.org/redox-os/rmm/-/merge_requests/7#note_27379https://gitlab.redox-os.org/redox-os/rmm/-/merge_requests/7#note_27379https://gitlab.redox-os.org/redox-os/redox/-/issues/1380Forks status2023-07-08T02:30:22ZRibbonForks statusThis issue will track the forks used by Redox, from GitHub to GitLab and the toolchains.
Forks with pending patches to be merged on upstream or waiting relibc improve its portability (they will be merged once the Redox APIs are stable)....This issue will track the forks used by Redox, from GitHub to GitLab and the toolchains.
Forks with pending patches to be merged on upstream or waiting relibc improve its portability (they will be merged once the Redox APIs are stable).
Mark them when it's merged or don't have patches.
- [ ] binutils
- [ ] openssl
- [ ] mesa
- [ ] sdl2
- [ ] atk
- [ ] bash
- [ ] cairo
- [ ] classicube
- [ ] coreutils
- [ ] cpal
- [ ] curl
- [ ] dash
- [ ] diffutils
- [ ] dosbox
- [ ] duktape
- [ ] eduke32
- [ ] extrautils
- [ ] ffmpeg
- [ ] findutils
- [ ] flycast
- [ ] fontconfig
- [ ] freeciv
- [ ] freedoom
- [ ] freepats
- [ ] game-2048
- [ ] gawk
- [ ] gdbserver
- [ ] generaluser-gs
- [ ] gettext
- [ ] gigalomania
- [ ] git
- [ ] glib
- [ ] glium
- [ ] glutin
- [ ] grep
- [ ] make
- [ ] gstreamer
- [ ] hematite
- [ ] iced
- [ ] jansson
- [ ] libc-bench
- [ ] libcosmic
- [ ] libffi
- [ ] libiconv
- [ ] libogg
- [ ] libretro-super
- [ ] libsodium
- [ ] mednafen
- [ ] mgba
- [ ] miniserve
- [ ] netsurf
- [ ] neverball
- [ ] openttd
- [ ] pango
- [ ] patch
- [ ] pathfinder
- [ ] pcre
- [ ] perl
- [ ] pixelcannon
- [ ] pixman
- [ ] prboom
- [ ] python
- [ ] qemu
- [ ] readline
- [ ] retroarch
- [ ] ripgrep
- [ ] rs-nes
- [ ] rust64
- [ ] rustual-boy
- [ ] schismtracker
- [ ] scummvm
- [ ] sdl1.2
- [ ] sdl_gfx
- [ ] sdl_image
- [ ] sdl_mixer
- [ ] sdl_ttf
- [ ] sdl-player
- [ ] sdl2_mixer
- [ ] sed
- [ ] servo
- [ ] sm64ex
- [ ] spacecadetpinball
- [ ] openssh
- [ ] syobonaction
- [ ] timidity
- [ ] uutils
- [ ] vice
- [ ] vim
- [ ] vttest
- [ ] vvvvvv
- [ ] webrender
### Permanent forks
- gcc
- llvm
- rustc
- cargohttps://gitlab.redox-os.org/redox-os/redox/-/issues/1379Golang port2023-06-12T22:21:36ZRibbonGolang portGolang have its own standard library, thus it will need to use the Redox system calls directly (massive).Golang have its own standard library, thus it will need to use the Redox system calls directly (massive).https://gitlab.redox-os.org/redox-os/redox/-/issues/1378Crates porting status2023-07-07T22:19:38ZRibbonCrates porting statusThis issue will cover important crates that are currently inhibiting porting or need upstream Redox support to ease the development workflow.
- [ ] tokio
- [ ] mio
- [ ] ring
- [ ] crossterm (mio dependency) WIP port: https://github.com...This issue will cover important crates that are currently inhibiting porting or need upstream Redox support to ease the development workflow.
- [ ] tokio
- [ ] mio
- [ ] ring
- [ ] crossterm (mio dependency) WIP port: https://github.com/rw-vanc/crossterm.git
- [ ] acpi (remove Handler generic parameter from types)
- [ ] clap
- [ ] iced (upstream support pending)
- [ ] error_chain (and the list of newer and shinier error handling crates)
- [ ] serde
- [ ] serde_derive
- [ ] serde_json
- [ ] yaml
- [ ] log
- [ ] env_logger
- [ ] url
- [ ] tempdir
- [ ] toml
- [ ] libprochttps://gitlab.redox-os.org/redox-os/redox/-/issues/1377Repositories with missing GitLab CI2023-11-07T17:45:59ZRibbonRepositories with missing GitLab CICI testing is an important industry-standard to enforce mature software, it can cover compilation errors, logic problems, typos, broken links, etc.
- [ ] arg-parser
- [ ] audiod
- [ ] binutils
- [ ] bootloader
- [ ] bootloader-coreboot
...CI testing is an important industry-standard to enforce mature software, it can cover compilation errors, logic problems, typos, broken links, etc.
- [ ] arg-parser
- [ ] audiod
- [ ] binutils
- [ ] bootloader
- [ ] bootloader-coreboot
- [ ] bootloader-efi
- [ ] bootstrap
- [ ] cbitset
- [ ] cbloom
- [ ] chashmap
- [ ] compiler-builtins
- [ ] conc
- [ ] contain
- [ ] cookbook
- [ ] coreboot-fs
- [ ] coreboot-table
- [ ] core_io
- [ ] coreutils
- [ ] dmi
- [ ] drivers
- [ ] dynamic-example
- [ ] escalated
- [ ] event
- [ ] exampled
- [ ] extrautils
- [ ] f80
- [ ] findutils
- [ ] games
- [ ] gdb-protocol
- [ ] gdbserver
- [ ] home
- [ ] hwio
- [ ] init
- [ ] installer
- [ ] installer-gui
- [ ] intelflash
- [ ] kernel
- [ ] libextra
- [ ] netstack
- [ ] netutils
- [ ] nulld
- [ ] pkgar
- [ ] pkgutils
- [ ] ramfs
- [ ] randd
- [ ] ransid
- [ ] redox-daemon
- [ ] redoxer
- [ ] redox-fatfs
- [ ] redox-fatfs
- [ ] redox-input
- [ ] zerod
- [ ] redox-ssh
- [ ] rmm
- [ ] sodium
- [ ] strace-redox
- [ ] termios
- [ ] uefi
- [ ] userutilshttps://gitlab.redox-os.org/redox-os/kernel/-/issues/124Implement x86 security mitigations2024-03-16T08:44:54ZJacob Lorentzon4ldo2@protonmail.comImplement x86 security mitigationsHere's the list based on the x86 CPU vulnerabilities that Linux's lscpu prints. IIRC some of these only require updated microcode (but Redox doesn't currently support microcode updates).
- [ ] Spec store bypass (add IA32_SPEC_CTRL to co...Here's the list based on the x86 CPU vulnerabilities that Linux's lscpu prints. IIRC some of these only require updated microcode (but Redox doesn't currently support microcode updates).
- [ ] Spec store bypass (add IA32_SPEC_CTRL to context state)
- [ ] Spectre v1
- [ ] usercopy lfence barriers
- [ ] swapgs lfence barriers
- [ ] race condition induced Spectre (Ghostrace)
- [ ] etc...
- [ ] Spectre v2
- [ ] Retpolines
- [ ] RSB filling on context switches
- [ ] etc...
- [ ] Meltdown (PTI - unfinished)
- [ ] Retbleed - https://lwn.net/Articles/901834/, https://lwn.net/Articles/907054/
- [ ] Mmio stale data
- [ ] Mds
- [x] L1tf (VMM) - does not affect the Redox kernel... yet (no hypervisor support).
- [x] L1tf (OS) - `Frame`s are statically enforced not to be 0x0, and RMM is clearing page entries to zero (though it could be enforced better: https://gitlab.redox-os.org/redox-os/rmm/-/issues/3)
- [ ] Itlb multihit - does not yet affect the Redox kernel... but once hypervisor support is added, ensure that large/huge pages are not executable on vulnerable CPU models.
- [ ] Srbds - requires microcode update (mitigation can be disabled via MSRs)
- [ ] Tsx async abort - requires microcode update, Linux defaults to disabling TSX entirely in that case
- [ ] Gather data sampling ("DOWNFALL") - requires microcode update. TODO: anything else?
- [ ] RAS overflow ("INCEPTION") - requires microcode update too. TODO: anything else?
- [ ] Register File Data Sampling (only affects Intel Atom though)
Some other useful security-enhancing x86 features less related to side channels:
- [x] UMIP (trivial to add support for)
- [x] SMEP (also trivial) - apparently related to RSB filling
- [x] SMAP (will require [usercopy functions](https://gitlab.redox-os.org/redox-os/kernel/-/issues/115), hard)
- [ ] Protection keys
- [ ] Shadow stacks
It would most likely be wise to prioritize vulnerabilities affecting newer CPUs first, most notably Spec Store Bypass and Spectre V1/V2, then continuing with Retbleed, Meltdown, and lastly, the Intel-specific mostly-patched bugs (MDS, L1TF, TSX, MMIO stale data, SRBDS).
Redox also needs to implement microcode loading, which can probably be done from userspace.https://gitlab.redox-os.org/redox-os/syscall/-/issues/32Use a safe transmute crate2023-06-08T10:08:00ZJacob Lorentzon4ldo2@protonmail.comUse a safe transmute crateCurrently, many of the redox_syscall structs are repr(C) although using Deref impls to be convertible to regular slices. This has a few downsides, such as requiring explicit unsafe when casting *slices* of structs, as well as unsafe boil...Currently, many of the redox_syscall structs are repr(C) although using Deref impls to be convertible to regular slices. This has a few downsides, such as requiring explicit unsafe when casting *slices* of structs, as well as unsafe boilerplate. Reading padding bytes from a struct is UB, and `Stat` (on x86_64 at least) does contain implicit padding, making its Deref impl unsound (cf. https://gitlab.redox-os.org/redox-os/syscall/-/issues/29).
Some Redox drivers use `plain`, which would be a great improvement, although requiring manual `unsafe impl Plain for Struct`, and only allowing `slice_from_bytes` (as opposed to `slice_to_bytes`, which is impossible since plain does not forbid padding bytes). A better alternative might be `bytemuck`, which uses a derive-macro to safely implement traits, with the addition of being able to safely convert contiguous enums to/from ints (zerocopy would also work, but might not be ideal due to licensing).https://gitlab.redox-os.org/redox-os/redox/-/issues/1375Server room2024-03-18T00:01:18ZRibbonServer roomThis issue cover what is necessary for the server variant of Redox.
- [ ] Port nginx
- [ ] Port NodeJS
- [ ] Port Deno
- [ ] Port MySQL
- [ ] Port PostgreSQL
- [ ] Port MongoDB
- [ ] Audit the kernel for security issues
- [ ] Security m...This issue cover what is necessary for the server variant of Redox.
- [ ] Port nginx
- [ ] Port NodeJS
- [ ] Port Deno
- [ ] Port MySQL
- [ ] Port PostgreSQL
- [ ] Port MongoDB
- [ ] Audit the kernel for security issues
- [ ] Security mitigations for x86 motherboards (https://gitlab.redox-os.org/redox-os/kernel/-/issues/124)
- [ ] Extension of RedoxFS to multiple disks for RAID-style use cases
- [ ] GPGPU support for AI and other compute acceleration (future)https://gitlab.redox-os.org/redox-os/relibc/-/issues/176Rusty error handling2023-11-12T15:41:15ZJacob Lorentzon4ldo2@protonmail.comRusty error handlingCurrently, relibc primarily does C-like error handling (returning -1 and setting errno). A better alternative would be to use `Result<T, Errno>`, which AFAIK currently only the inner pthread implementation does. If `Errno` is defined as ...Currently, relibc primarily does C-like error handling (returning -1 and setting errno). A better alternative would be to use `Result<T, Errno>`, which AFAIK currently only the inner pthread implementation does. If `Errno` is defined as `NonZeroU32`, then the common "zero for success or -1 with errno" can be represented zero-cost as `Result<(), Errno>`. Only the outer C functions would convert the inner OS-abstracted platform functions into "-1 and errno", or other types of error handling (such as pthread's "0 or error code").
Worth noting both Redox and Linux represent syscall errors as negative error numbers (in Linux's case, between -4096 and -1, and currently in Redox's case, all negative numbers), so this change would most likely not lead to performance degradation.https://gitlab.redox-os.org/redox-os/redox/-/issues/1374aarch64 boot on qemu fails with redoxfs panic2023-06-13T00:40:37ZWill Angenentaarch64 boot on qemu fails with redoxfs panicWhen booting on qemu, redoxfs fails with [redoxfs-crash-log](/uploads/3b53e2fd01431ff0c3a8cc0ab2469675/redoxfs-crash-log).
`ELR_EL1` points at a BRK instruction. `ESR_EL1`, when decoded with something like
```
println!(
"ESR_EL1: {:...When booting on qemu, redoxfs fails with [redoxfs-crash-log](/uploads/3b53e2fd01431ff0c3a8cc0ab2469675/redoxfs-crash-log).
`ELR_EL1` points at a BRK instruction. `ESR_EL1`, when decoded with something like
```
println!(
"ESR_EL1: {:>016X} ISS={:>06X} instr len={:?} class={:>02X}", done in an idiomatic way, hardcode strings?
{ self.esr_el1 },
{ self.esr_el1 & 0xffffff },
{ self.esr_el1 >> 25 & 1 },
{ self.esr_el1 >> 26 & 0x3f }
);
```
in [dump](https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/arch/aarch64/interrupt/handler.rs#L99) reveals
```
ISS=000001 instr len=1 class=3C
```
`0x3c` is BRK instruction execution from AArch64 state.
Manually dissecting the backtrace shows that the addresses correspond to the backtrace printing code, not the code that failed.
Early on, a fork happens, and the parent & child both panic. Looks like the child has this in [`src/bin/mount.rs`](https://gitlab.redox-os.org/redox-os/redoxfs/-/blob/master/src/bin/mount.rs#L373).
```
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: UnexpectedEof, message: "failed to fill whole buffer" }', src/bin/mount.rs:373:39
```
And the parent has
```
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /Users/wangenent/code/redox/mac/rust/library/alloc/src/collections/btree/navigate.rs:588:48
```
Some notes from conversations in the chat
- @4lDO2 mentioned that problems the btree is often caused by memory corruption.
- @microcolonel suggested checking the fork/context switching code. Audit the process creation, fork and context switch code. Come up with tests to stress this part. Tests that do not depend on an initfs or a livedisk etc.
- @rw_van suggested it's probably memory corruption or a race condition
An interesting observation, is that if redoxfs is built with `-O0` in a custom profile, e.g.
```
[profile.will-debug]
inherits = "release"
opt-level = 0
```
then the problem doesn't manifest itself and redox boots fine.https://gitlab.redox-os.org/redox-os/kernel/-/issues/121Formally verify the kernel2023-12-15T14:23:21ZJeremy SollerFormally verify the kernel*Created by: ticki*
+assign @me*Created by: ticki*
+assign @mehttps://gitlab.redox-os.org/redox-os/kernel/-/issues/120Eliminate most heap allocations2023-07-13T16:55:47ZMichael Aaron Murphymmstick@pm.meEliminate most heap allocationsI noticed that there's a lot of usage of collections that dynamically allocate on the heap inside the kernel, such as [this](https://github.com/redox-os/redox/blob/6927a4c5cfef4b97a58ba63b4f9d6d01dd8e9824/kernel/scheme/sys/memory.rs). It...I noticed that there's a lot of usage of collections that dynamically allocate on the heap inside the kernel, such as [this](https://github.com/redox-os/redox/blob/6927a4c5cfef4b97a58ba63b4f9d6d01dd8e9824/kernel/scheme/sys/memory.rs). It would be better to pass around stack-allocated arrays or at least take advantage of [stack-allocated vectors](https://docs.rs/arrayvec/0.3.20/arrayvec/). ~~Kernel code should probably attempt to avoid heap allocations entirely.~~