mirror of
https://github.com/RGBCube/serenity
synced 2025-07-27 09:57:35 +00:00
Base: Minor cleanup of a few man pages.
- Fix some typos and formatting. - Add links to Mitigations from unveil / pledge.
This commit is contained in:
parent
325e491d34
commit
56fccf1667
3 changed files with 8 additions and 7 deletions
|
@ -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)
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue