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.
I have a lot of respect for Nadia Eghbal, partly because I can't help to be
jealous of her work on the economics of Free Software1. If you are not
already familiar with Eghbal, she is the author of Roads and Bridges: The
Unseen Labor Behind Our Digital Infrastructure, a great technical
report published for the Ford Foundation in 2016. You may also have caught her
excellent keynote at LCA 2017, entitled Consider the Maintainer.
Her latest book, Working in Public: The Making and Maintenance of Open Source
Software, published by Stripe Press a few months ago, is a great read and if
this topic interests you, I highly recommend it.
The book itself is simply gorgeous; bright orange, textured hardcover binding,
thick paper, wonderful typesetting it has everything to please. Well, nearly
everything. Sadly, it is only available on Amazon, exclusively in the United
States. A real let down for a book on Free and Open Source Software.
The book is divided in five chapters, namely:
Contrary to what I was expecting, the book feels more like an extension of the
LCA keynote I previously mentioned than Roads and Bridges. Indeed, as made
apparent by the following quote, Eghbal doesn't believe funding to be the
primary problem of FOSS anymore:
A couple of year ago, I moved into a new flat that comes with RJ45 sockets wired for 10 Gigabit (but currently offering 1 Gigabit) Ethernet.This also meant changing the settings on my router box for my new ISP.I took this opportunity to review my router's other settings too. I'll be blogging about these over the next few posts.
Adding IPv6 support to my home LAN
I have been following the evolution of IPv6 ever since the KAME project produced the first IPv6 implementation. I have also been keeping track of the IPv4 address depletion.
Around the time the IPv6 Day was organized in 2011, I started investigating the situation of IPv6 support at local ISPs.
Well, never mind all those rumors about Finland being some high-tech mecca. Back then, no ISP went beyond testing their routers for IPv6 compatibility and producing white papers on what their limited test deployments accomplished.
Not that it matters much, in practice. Most IPv6 documentation out there, including 
It's a bit of a long shot, but maybe someone on Planet Debian or
elsewhere can help us reach the right people at Apple.
Starting with iOS 14, something apparently changed on the way
USB tethering (also called Personal Hotspot) is set up, which broke
it for people using Linux. The driver in use is ipheth, developped
in 
Like 
Welcome to gambaru.de. Here is my monthly report (+ the first week in October) that covers what I have been doing for Debian. If you re interested in Java, Games and LTS topics, this might be interesting for you.
Debian Games
Two years ago, I held the 
Welcome to the 30th post in the rarified R recommendation resources series or 
If you clear your browser cookies regularly (as you should do), Google will annoy you with a full screen cookie consent overlay these days. And - of course - there is no "no tracking consent, technically required cookies only" button. You may log in to Google to set your preference. Yeah, I'm sure this is totally following the intent of the 
Unfortunately none of the big "anti-annoyances" filter lists seem to have picked that one up yet but the friendly folks from the 
