[$] Strict memcpy() bounds checking for the kernel
The C programming language is famously prone to memory-
safety problems that lead to buffer overflows and a seemingly endless stream of
security vulnerabilities. But, even in C, it is possible to improve the
situation in many cases. One of those is the memcpy() family of functions,
which are used to efficiently copy or overwrite blocks of memory; with a bit of
help from the compiler, those functions can be prevented from writing past the
end of the destination object they are passed. Enforcing that condition in the
kernel is harder than one might expect, though, as this massive patch set from
Kees Cook shows.
Security updates for Friday
Security updates have been issued by Debian (libsndfile and
openjdk-11), Fedora (php-pear and seamonkey), openSUSE (fastjar and php7), SUSE
(php72, qemu, and sqlite3), and Ubuntu (libsndfile, php-pear, and qpdf).
The GNU C Library copyright-assignment policy changes
The change in copyright-assignment policy proposed in June
for the GNU C Library project has now been adopted: The changes to accept
patches with or without FSF copyright assignment will be effective after
August 2nd, and will apply to all open branches. Code shared with other
GNU packages via Gnulib will continue to require assignment to the
FSF.
The library will continue to be licensed under the GNU Lesser Public
License v2.1 or later.
FSF-funded call for white papers on philosophical and legal questions around Copilot
On its blog, the Free Software Foundation (FSF) has
announced a call for white papers about GitHub Copilot and the questions
surrounding it. The FSF will pay $500 for papers that it publishes because they
"help elucidate the problem": We can see that Copilot's use of freely licensed
software has many implications for an incredibly large portion of the free
software community. Developers want to know whether training a neural network on
their software can really be considered fair use. Others who may be interested
in using Copilot wonder if the code snippets and other elements copied from
GitHub-hosted repositories could result in copyright infringement. And even if
everything might be legally copacetic, activists wonder if there isn't something
fundamentally unfair about a proprietary software company building a service off
their work.
[$] Hole punching races against page-cache filling
Filesystem developers tend to disagree with each other
about many things, but they are nearly unanimous in their dislike for the
truncate() system call, which chops data off the end of a file. Implementing
truncate() tends to be full of traps for the unwary — the kind of traps that can
lead to lost data. But it turns out that a similar operation, called "hole
punching", may be worse. This operation has been subject to difficult-to-hit
but real race conditions in many filesystems for years; this patch set from Jan
Kara may finally be at a point where it can fill the hole in hole
punching.
