librewolf
/
lkrg
mirror of https://github.com/openwall/lkrg.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Documentation update for 0.8.1

This commit is contained in:
Solar Designer 2020-07-08 16:58:54 +02:00
parent cfe3bf406e
commit 4e1dfeb2d1
4 changed files with 42 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
CHANGES
View File

@ -1,3 +1,13 @@
The following major changes have been made between LKRG 0.8 and 0.8.1:
*) Drop init_module() and delete_module() syscall hooks, which were no longer
justified now that we hook capable() yet contained a nasty bug (first
reported by Jason A. Donenfeld) allowing a user to trigger an Oops (read via
a near-NULL pointer) on 64-bit Linux 4.17+
*) Update CONCEPTS to note the risk of running with untested kernel versions
*) Update PERFORMANCE to refer to Phoronix article and raw results on 0.8
The following major changes have been made between LKRG 0.7 and 0.8:
*) Add support for kernels 5.3+ (JUMP_LABEL batch mode), 5.5+ and 5.6+ (other
@ -129,7 +139,7 @@ The following changes have been made between LKRG 0.4 and 0.5:
The following changes have been made between LKRG 0.3 and 0.4:
*) [ED] Fix a potential kretprobe glitch that could happen in a very rare
corner case on heavily loaded SMP machines (resulting in a false positive)
corner case on heavily loaded SMP machines (resulting in a false positive)
*) [ED] Change some of the printed messages for log_level=4
*) [ED] Add support for 4.17+ kernels. This is a pretty big change addressing:
a) New logic of how syscall stubs are created; CONFIG_X32_X86 and

22
CONCEPTS
View File

@ -13,17 +13,21 @@ less reliable exploits.
LKRG also provides security through diversity, much like running an uncommon OS
kernel would, yet without the usability drawbacks of actually running an
uncommon OS. As free LKRG becomes somewhat popular and maybe a target of some
exploits, we might introduce paid LKRG Pro as a means to fund the project and
provide further diversity (with Pro's smaller userbase being beneficial), extra
and specialized functionality, and maybe distro-specific binary builds.
uncommon OS. As free LKRG becomes somewhat popular and possibly starts being
deliberately bypassed by some exploits, we might introduce paid LKRG Pro as a
means to fund the project and provide further diversity (with Pro's smaller
userbase being beneficial), extra and specialized functionality, and maybe
distro-specific binary builds.
Like any software, LKRG may contain bugs and some of those might even be new
security vulnerabilities. You need to weigh the benefits vs. risks of using
LKRG, considering that LKRG is most useful on systems that realistically,
despite of this being a best practice for security, won't be promptly rebooted
into new kernels (nor live-patched) whenever a new kernel vulnerability is
discovered.
security vulnerabilities. Moreover, usage of any out-of-tree kernel module
involves risk of incompatibilities with the specific kernel version/build, and
LKRG is no exception. We test LKRG across a wide range of kernel versions, but
obviously not with future kernel versions, with which LKRG might or might not
work right. You need to weigh the benefits vs. risks of using LKRG,
considering that LKRG is most useful on systems that realistically, despite of
this being a best practice for security, won't be promptly rebooted into new
kernels (nor live-patched) whenever a new kernel vulnerability is discovered.
LKRG is currently in an experimental stage. We expect occasional false
positives (integrity violations and/or exploits detected when there aren't

15
PERFORMANCE
View File

@ -64,7 +64,7 @@ System configuration:
OS: Ubuntu 18.04, Kernel: 4.15.0-101-generic (x86_64), Desktop: Xfce, Display Server: X Server 1.19.6, OpenCL: OpenCL 1.2 CUDA 10.2.159, Compiler: GCC 7.5.0, File-System: ext4, Screen Resolution: 3840x2160
Below are the raw per-test results, including all the curiosities. (LKRG
Below are our raw per-test results, including all the curiosities. (LKRG
speeds up "Socket Activity" by 30% or 35%?! We don't think it normally does.
We also don't think it normally slows down context switches. This is where the
science is in CS, with experiments sometimes showing weird results. Luckily,
@ -590,3 +590,16 @@ with as many as 58 tests these weird effects mostly cancel out.)
LKRG 0.8 ........................................ 1.617 |===================
LKRG 0.8 light .................................. 1.653 |===================
Without LKRG 2 .................................. 1.626 |===================
Shortly after the LKRG 0.8 release, Michael himself ran different benchmarks of
it (as many as 119 tests) and published an article and the raw results here:
https://www.phoronix.com/scan.php?page=article&item=lkrg-08-linux&num=1
https://openbenchmarking.org/result/2006277-NE-LKRG08BEN46
Once again, we found most of the results reasonable, but were surprised by
some, which we'll be looking into. Unfortunately, automated analytics of the raw
results above show inconsistent geometric means in two places (a bug, which
Michael acknowledged), so we cannot easily and confidently state LKRG's overall
performance impact as seen there, but the individual test results are usable.

8
README
View File

@ -33,9 +33,9 @@ like the below:
wget https://www.openwall.com/signatures/openwall-offline-signatures.asc
gpg --import openwall-offline-signatures.asc
wget https://www.openwall.com/lkrg/lkrg-0.8.tar.gz.sign
wget https://www.openwall.com/lkrg/lkrg-0.8.tar.gz
gpg --verify lkrg-0.8.tar.gz.sign lkrg-0.8.tar.gz
wget https://www.openwall.com/lkrg/lkrg-0.8.1.tar.gz.sign
wget https://www.openwall.com/lkrg/lkrg-0.8.1.tar.gz
gpg --verify lkrg-0.8.1.tar.gz.sign lkrg-0.8.1.tar.gz
Please preserve the GnuPG key above and also use it to verify future releases,
which will most likely work in a similar manner.
@ -389,7 +389,7 @@ The sysctl's are (with default values specified in braces):
Whether and to what extent to validate Control Flow Integrity (CFI) on kernel
functions that we monitor because of their usefulness for exploits' Return
Oriented Programming (ROP) chains. Allowed values are 0 (disabled), 1 (only
sanity-check the stack pointer), and 2 (also sanity-check all stack frames).
validate the stack pointer), and 2 (also validate all stack frames).
Because of the very limited extent of validation performed, we call our CFI
mechanism pCFI, for poor man's CFI.