RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-27 09:57:35 +00:00
Code Issues Activity Actions

Base: Minor cleanup of a few man pages.

Browse source 
- Fix some typos and formatting.

- Add links to Mitigations from unveil / pledge.
This commit is contained in:
Brian Gianforcaro 2021-05-05 02:44:25 -07:00 • committed by Andreas Kling
parent 325e491d34
commit 56fccf1667
3 changed files with 8 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

1
Base/usr/share/man/man2/pledge.md
View file

@ -71,3 +71,4 @@ The `pledge()` system call was first introduced by OpenBSD. The implementation i
## See also
* [`unveil`(2)](unveil.md)
* [`Mitigations`(7)](../man7/Mitigations.md)

7
Base/usr/share/man/man2/unveil.md
View file

@ -32,9 +32,9 @@ include the following characters:
A single `unveil()` call may specify multiple permission characters at once.
Subsequent `unveil()` calls may take away permissions from the ones allowed
earlier for the same file. Note that unveilng a path with any set of
earlier for the same file. Note that unveiling a path with any set of
permissions does not turn off the regular permission checks: access to a file
which the process has unvelied for itself, but has otherwise no appropriate
which the process has unveiled for itself, but has otherwise no appropriate
permissions for, will still be rejected. Unveiling a directory allows the
process to access any files inside the directory.
@ -58,7 +58,7 @@ the error.
* `EFAULT`: `path` and/or `permissions` are not null and not in readable
memory.
* `EPERM`: The veil is locked, or an attempt to add more permissions for an
already unvelied path was rejected.
already unveiled path was rejected.
* `EINVAL`: `path` is not an absolute path, or `permissions` are malformed.
All of the usual path resolution errors may also occur.
@ -90,3 +90,4 @@ unveil(nullptr, nullptr);
* [`pledge`(2)](pledge.md)
* [`chroot`(2)](chroot.md)
* [`Mitigations`(7)](../man7/Mitigations.md)

7
Base/usr/share/man/man7/Mitigations.md
View file

@ -23,7 +23,6 @@ Author: Andreas Kling <awesomekling@gmail.com>
Date: Wed Jan 1 01:56:58 2020 +0100
Kernel: Enable x86 SMEP (Supervisor Mode Execution Protection)
```
### SMAP (Supervisor Mode Access Prevention)
@ -133,7 +132,7 @@ Kernel: KUBSAN! (Kernel Undefined Behavior SANitizer) :^)
### Kernel unmap-after-init
Umap-after-init allows the kerenel to remove functions which contain potentially
Umap-after-init allows the kernel to remove functions which contain potentially
dangerous [ROP gadgets](https://en.wikipedia.org/wiki/Return-oriented_programming)
from kernel memory after we've booted up and they are no longer needed. Notably the
`write_cr4(..)` function used to control processor features like the SMEP/SMAP bits
@ -158,7 +157,7 @@ Kernel: Add .unmap_after_init section for code we don't need after init
in the linker and loader that hardens the data sections of an ELF binary.
When enabled, it segregates function pointers resolved by the dynamic loader
into a separate section of the runtie executable memory, and allows the loader
into a separate section of the runtime executable memory, and allows the loader
to make that memory read-only before passing control to the main executable.
This prevents attackers from overwriting the [Global Offset Table (GOT)](https://en.wikipedia.org/wiki/Global_Offset_Table).
@ -218,8 +217,8 @@ Kernel+LibC: Build with basic -fstack-protector support
```
It was later re-enabled and refined to `-fstack-protector-strong` in the following commits:
```
```
commit fd08c93ef57f71360d74b035214c71d7f7bfc5b8
Author: Brian Gianforcaro <b.gianfo@gmail.com>
Date: Sat Jan 2 04:27:35 2021 -0800