Previously:
v5.6
Linux v5.7 was released at the end of May. Here s my summary of various security things that caught my attention:
arm64 kernel pointer authentication
While the ARMv8.3 CPU Pointer Authentication (PAC) feature
landed for userspace already, Kristina Martsenko has now
landed PAC support in kernel mode. The current implementation uses
PACIASP which protects the saved stack pointer, similar to the existing
CONFIG_STACKPROTECTOR feature, only faster. This also paves the way to sign and check pointers stored in the heap, as a way to defeat function pointer overwrites in those memory regions too. Since the behavior is different from the traditional stack protector, Amit Daniel Kachhap added an
LKDTM test for PAC as well.
BPF LSM
The kernel s Linux Security Module (LSM) API provide a way to write security modules that have traditionally implemented various Mandatory Access Control (MAC) systems like SELinux, AppArmor, etc. The LSM hooks are numerous and no one LSM uses them all, as some hooks are much more specialized (like those used by IMA, Yama, LoadPin, etc). There was not, however, any way to externally attach to these hooks (not even through a regular loadable kernel module) nor build fully dynamic security policy, until KP Singh landed the API for
building LSM policy using BPF. With this, it is possible (for a privileged process) to write kernel LSM hooks in BPF, allowing for totally custom security policy (and reporting).
execve() deadlock refactoring
There have been a number of long-standing races in the kernel s process launching code where ptrace could deadlock. Fixing these has been attempted several times over the last many years, but Eric W. Biederman and Ernd Edlinger decided to dive in, and successfully landed the a series of refactorings,
splitting up the problematic locking and refactoring their uses to
remove the deadlocks. While he was at it, Eric also
extended the exec_id counter to 64 bits to avoid the possibility of the counter wrapping and allowing an attacker to send arbitrary signals to processes they normally shouldn t be able to.
slub freelist obfuscation improvements
After Silvio Cesare observed some weaknesses in the implementation of
CONFIG_SLAB_FREELIST_HARDENED s freelist pointer content obfuscation, I
improved their bit diffusion, which makes attacks require significantly more memory content exposures to defeat the obfuscation. As part of the conversation, Vitaly Nikolenko pointed out that the freelist pointer s location made it relatively easy to target too (for either disclosures or overwrites), so I
moved it away from the edge of the slab, making it harder to reach through small-sized overflows (which usually target the freelist pointer). As it turns out, there were a few assumptions in the kernel about the location of the freelist pointer, which had to also get
cleaned up.
RISCV page table dumping
Following v5.6 s
generic page table dumping work, Zong Li landed the
RISCV page dumping code. This means it s much easier to examine the kernel s page table layout when running a debug kernel (built with
PTDUMP_DEBUGFS), visible in
/sys/kernel/debug/kernel_page_tables.
array index bounds checking
This is a pretty large area of work that touches a lot of overlapping elements (and history) in the Linux kernel. The short version is: C is bad at noticing when it uses an array index beyond the bounds of the declared array, and we need to fix that. For example, don t do this:
int foo[5];
...
foo[8] = bar;
The long version gets complicated by the evolution of
flexible array structure members, so we ll pause for a moment and skim the surface of this topic. While things like
CONFIG_FORTIFY_SOURCE try to catch these kinds of cases in the
memcpy() and
strcpy() family of functions, it doesn t catch it in open-coded array indexing, as seen in the code above. GCC has a warning (
-Warray-bounds) for these cases, but it was
disabled by Linus because of all the false positives seen due to fake flexible array members. Before flexible arrays were standardized, GNU C supported zero sized array members. And before that, C code would use a 1-element array. These were all designed so that some structure could be the header in front of some data blob that could be addressable through the last structure member:
/* 1-element array */
struct foo
...
char contents[1];
;
/* GNU C extension: 0-element array */
struct foo
...
char contents[0];
;
/* C standard: flexible array */
struct foo
...
char contents[];
;
instance = kmalloc(sizeof(struct foo) + content_size);
Converting all the zero- and one-element array members to flexible arrays is one of Gustavo A. R. Silva s goals, and
hundreds of these changes started landing. Once fixed,
-Warray-bounds can be re-enabled. Much more detail can be found in the kernel s
deprecation docs.
However, that will only catch the visible at compile time cases. For runtime checking, the Undefined Behavior Sanitizer has an option for adding runtime array bounds checking for catching things like this where the compiler cannot perform a static analysis of the index values:
int foo[5];
...
for (i = 0; i < some_argument; i++)
...
foo[i] = bar;
...
It was, however, not separate (via kernel Kconfig) until Elena Petrova and I
split it out into CONFIG_UBSAN_BOUNDS, which is fast enough for production kernel use. With this enabled, it's now possible to instrument the kernel to catch these conditions, which seem to come up with some regularity in Wi-Fi and Bluetooth drivers for some reason. Since UBSAN (and the other Sanitizers) only
WARN() by default, system owners need to set
panic_on_warn=1 too if they want to defend against attacks targeting these kinds of flaws. Because of this, and to avoid bloating the kernel image with all the warning messages, I
introduced CONFIG_UBSAN_TRAP which effectively turns these conditions into a
BUG() without needing additional sysctl settings.
Fixing "additive"
snprintf() usage
A common idiom in C for building up strings is to use
sprintf()'s return value to increment a pointer into a string, and build a string with more
sprintf() calls:
/* safe if strlen(foo) + 1 < sizeof(string) */
wrote = sprintf(string, "Foo: %s\n", foo);
/* overflows if strlen(foo) + strlen(bar) > sizeof(string) */
wrote += sprintf(string + wrote, "Bar: %s\n", bar);
/* writing way beyond the end of "string" now ... */
wrote += sprintf(string + wrote, "Baz: %s\n", baz);
The risk is that if these calls eventually walk off the end of the
string buffer, it will start writing into other memory and create some bad situations. Switching these to
snprintf() does not, however, make anything safer, since
snprintf() returns how much it would have written:
/* safe, assuming available <= sizeof(string), and for this example
* assume strlen(foo) < sizeof(string) */
wrote = snprintf(string, available, "Foo: %s\n", foo);
/* if (strlen(bar) > available - wrote), this is still safe since the
* write into "string" will be truncated, but now "wrote" has been
* incremented by how much snprintf() *would* have written, so "wrote"
* is now larger than "available". */
wrote += snprintf(string + wrote, available - wrote, "Bar: %s\n", bar);
/* string + wrote is beyond the end of string, and availabe - wrote wraps
* around to a giant positive value, making the write effectively
* unbounded. */
wrote += snprintf(string + wrote, available - wrote, "Baz: %s\n", baz);
So while the first overflowing call would be safe, the next one would be targeting beyond the end of the array and the size calculation will have wrapped around to a giant limit. Replacing this idiom with
scnprintf() solves the issue because it only reports what was actually written. To this end, Takashi Iwai has been
landing a bunch scnprintf() fixes.
That's it for now! Let me know if there is anything else you think I should mention here. Next up: Linux v5.8.
2020, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
A new RcppSimdJson release arrived on CRAN yesterday bringing along the simdjson 0.5.0 release that happened a few weeks.
RcppSimdJson wraps the fantastic and genuinely impressive simdjson library by Daniel Lemire and collaborators. Via very clever algorithmic engineering to obtain largely branch-free code, coupled with modern C++ and newer compiler instructions, it results in parsing gigabytes of JSON parsed per second which is quite mindboggling. The best-case performance is faster than CPU speed as use of parallel SIMD instructions and careful branch avoidance can lead to less than one cpu cycle per byte parsed; see the video of the talk by Daniel Lemire at QCon (also voted best talk).
Beside the upstream update, not too much happened to our package itself since 0.1.1 though Brandon did help one user to seriously speed up his JSON processing. The (this time very short) NEWS entry follows.
The thirteenth release of 
For almost a decade, I ve been very slowly making progress on a multicast IPTV
system. Recently I ve made a significant leap forward in this project, and I
wanted to write a little on the topic so I ll have something to look at when I
pick this up next. I was aspiring to have a useable system by the end of today,
but for a couple of reasons, it wasn t possible.
When I started thinking about this project, it was still common to watch
broadcast television. Over time the design of this system has been changing as
new technologies have become available. Multicast IP is probably the only
constant, although I m now looking at IPv6 rather than IPv4.
Initially, I d been looking at DVB-T PCI cards. 
Two Raspberry Pis with DVB hats installed, TV antenna sockets showing
I upgraded my home internet connection to fibre (FTTP) 
I did try out RouterOS to start with, but I didn t find it particularly compelling. I m comfortable configuring firewalling and routing at a Linux command line, and I run some additional services on the router like my