Documentation update for 0.8.1

CHANGES

@@ -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

CONCEPTS

@@ -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

PERFORMANCE

@@ -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.

README

@@ -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.