Anhad Singh
124b74e816
`Grant::remap` should not directly mark entries as writeable because the
entry could be private and requires Copy-On-Write (COW) handling. This
bug fixes the random panics that occur when running programs that
incorrectly mark private memory regions as writeable. This also
inadvertently caused other systems to crash. This is because The Zeroed
Frame is mapped instead of allocating a new zeroed memory region every
time. Only after the first write is the frame actually allocated. This
means that with this bug one could remap a freshly mmap'ed ANONYMOUS
region with the write flag and rewrite the contents of The Zeroed Frame,
which is a big problem. This means that any program that allocated
memory with the ANONYMOUS flag after this would not receive zeroed
memory.
Example of `make` hitting this bug when the shared `ld.so` patches are
applied:
```
....
[page at 0x48bd000] is mapped to the zeroed frame with PageFlags { present: true, write: false, executable: false, user: true, bits: 0x8000000000000005 }
[page at 0x49b1000] is mapped to the zeroed frame with PageFlags { present: true, write: true, executable: false, user: true, bits: 0x8000000000000007 }
[page at 0x49b2000] is mapped to the zeroed frame with PageFlags { present: true, write: true, executable: false, user: true, bits: 0x8000000000000007 }
[page at 0x49b3000] is mapped to the zeroed frame with PageFlags { present: true, write: true, executable: false, user: true, bits: 0x8000000000000007 }
[page at 0x49b4000] is mapped to the zeroed frame with PageFlags { present: true, write: true, executable: false, user: true, bits: 0x8000000000000007 }
0x43ff000..0x49b5000 :: MapFlags(PROT_WRITE | PROT_READ)
[page at 0x49b5000] is mapped to the zeroed frame with PageFlags { present: true, write: false, executable: false, user: true, bits: 0x8000000000000005 }
[page at 0x49b6000] is mapped to the zeroed frame with PageFlags { present: true, write: false, executable: false, user: true, bits: 0x8000000000000005 }
....
```
and causing the following crash:
```
Page fault: 0000000000001718 P | WR | US
RFLAG: 0000000000010202
CS: 000000000000002b
RIP: 00000000004125fd
RSP: 00007fffffffdd80
SS: 0000000000000023
FSBASE 00000000003f6000
GSBASE 0000000000000000
KGSBASE ffff80007a800000
RAX: 0000000000001718
RCX: 0000000000000000
RDX: ffffffffffffffff
RDI: 000000000043b5a0
RSI: 00000000004537e0
R8: 0000000000000030
R9: 000000000043b5a0
R10: 0000000000000030
R11: 00000000000000ff
RBX: 0000000000000000
RBP: 00007fffffffddb0
R12: 000000000043b5a0
R13: 00000000004537e0
R14: 00000000004537e0
R15: 000000000043b5a0
FP 00007fffffffddb0: PC 000000000042614a
FP 00007fffffffde40: PC 0000000000411ae9
FP 00007fffffffde80: PC 0000000000417187
FP 00007fffffffdee0: PC 0000000000411d39
FP 00007fffffffdf90: PC 000000000041207d
FP 00007fffffffe020: PC 000000000040bc4c
FP 00007fffffffe0c0: PC 000000000040c7c9
FP 00007fffffffe0f0: PC 00000000004276ba
FP 00007fffffffe1a0: PC 0000000000428087
FP 00007fffffffe210: PC 000000000041eb6a
FP 00007fffffffe400: PC 00000000004205c3
FP 00007fffffffe490: PC 00000000004208dd
FP 00007fffffffe4d0: PC 000000000040747e
FP 00007ffffffffd60: PC 000000000092111c
<Invalid next frame pointer 0x0000000000438490; stack walk ended>
FP ffff80001b5bfe80: PC ffffffff80046dad
FFFFFFFF80046BD0+01DD
kernel::arch::x86_shared::interrupt::exception::page::inner
FP ffff80001b5bff50: PC ffffffff8003ffbb
FFFFFFFF8003FF84+0037
kernel::arch::x86_shared::interrupt::exception::page
00007fffffffddb0: GUARD PAGE
kernel::context::signal:INFO -- UNHANDLED EXCEPTION, CPU #1, PID 6548, NAME /usr/bin/make, CONTEXT 0xffffff7f8013fdc0
```
Also the crash info would vary every time you run the program since the
contents of The Zeroed Frame would have been mutated. Sneaky bug :^)
This also fixes the crashes that happen when running node.js (and maybe
other programs): https://gitlab.redox-os.org/redox-os/relibc/-/issues/229
Signed-off-by: Anhad Singh <andypython@protonmail.com>
Kernel
Redox OS Microkernel
Requirements
nasmneeds to be available on the PATH at build time.
Building The Documentation
Use this command:
cargo doc --open --target x86_64-unknown-none
Debugging
QEMU
Running QEMU with the -s flag will set up QEMU to listen on port 1234 for a GDB client to connect to it. To debug the redox kernel run.
make qemu gdb=yes
This will start a virtual machine with and listen on port 1234 for a GDB or LLDB client.
GDB
If you are going to use GDB, run these commands to load debug symbols and connect to your running kernel:
(gdb) symbol-file build/kernel.sym
(gdb) target remote localhost:1234
LLDB
If you are going to use LLDB, run these commands to start debugging:
(lldb) target create -s build/kernel.sym build/kernel
(lldb) gdb-remote localhost:1234
After connecting to your kernel you can set some interesting breakpoints and continue
the process. See your debuggers man page for more information on useful commands to run.
Notes
-
Always use
foo.get(n)instead offoo[n]and try to cover for the possibility ofOption::None. Doing the regular way may work fine for applications, but never in the kernel. No possible panics should ever exist in kernel space, because then the whole OS would just stop working. -
If you receive a kernel panic in QEMU, use
pkill qemu-systemto kill the frozen QEMU process.
How To Contribute
To learn how to contribute to this system component you need to read the following document:
Development
To learn how to do development with this system component inside the Redox build system you need to read the Build System and Coding and Building pages.
How To Build
To build this system component you need to download the Redox build system, you can learn how to do it on the Building Redox page.
This is necessary because they only work with cross-compilation to a Redox virtual machine, but you can do some testing from Linux.
Funding - Unix-style Signals and Process Management
This project is funded through NGI Zero Core, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.
