Hírolvasó

Using strings with contents that are supplied by users can be fraught with peril; SQL injection is a well-known technique for attacking applications that stems from that, for example. Generally, database frameworks and libraries provide mechanisms that seek to lead programmers toward doing The Right Thing, with parameterized queries and the like, but they cannot enforce that—inventive developers will seemingly always find ways to inject user input into places it should not go. A recently adopted Python Enhancement Proposal (PEP) provides a way to enforce the use of strings that are untainted by user input, but it uses the optional typing features of the language to do so; those wanting to take advantage of it will need to be running a type-checking program.

The 5.17.3, 5.16.20, 5.15.34, and 5.10.111 stable kernel updates have been released after a relatively quick review cycle. Each contains a relatively large set of important fixes. Note that 5.16.20 is the final update in the 5.16.x series.

Security updates have been issued by Arch Linux (gzip, python-django, and xz), Debian (chromium, subversion, and zabbix), Red Hat (expat, kernel, and thunderbird), SUSE (go1.16, go1.17, kernel, libexif, libsolv, libzypp, zypper, opensc, subversion, thunderbird, and xz), and Ubuntu (git, linux-bluefield, nginx, and subversion).

Version 6.3 of the Qt graphics library has been released. "Qt 6.3 also comes with a decent set of new functionality. A total of 250 user stories and tasks implementing new functionality have been completed for 6.3. Those are of course too many to list individually, and if you want to have all the details, have a look at our new features page and our Release Notes."

Git maintainer Junio C Hamano has announced the release of v2.35.2, along with multiple other Git versions ("v2.30.3, v2.31.2, v2.32.1, v2.33.2, and v2.34.2"), to fix a security problem that can happen on multi-user machines (CVE-2022-24765). This GitHub blog post has more details, though the GitHub service itself is not vulnerable. The description in the announcement seems a bit Windows-centric, but Linux multi-user systems are apparently vulnerable as well: On multi-user machines, Git users might find themselves unexpectedly in a Git worktree, e.g. when another user created a repository in `C:\.git`, in a mounted network drive or in a scratch space. Merely having a Git-aware prompt that runs `git status` (or `git diff`) and navigating to a directory which is supposedly not a Git worktree, or opening such a directory in an editor or IDE such as VS Code or Atom, will potentially run commands defined by that other user.

When last we looked in on the proposed trusted_for() system call, which would allow user-space interpreters and other tools to ask the kernel whether a file is "trusted" for execution, it looked like it was on-track for the mainline. That was back in October 2020; the patch has been updated multiple times since then, made its way into linux-next, and a pull request was made by Mickaël Salaün for the 5.18 merge window. But it seems that there will be more to the story of getting this functionality into the kernel, as Linus Torvalds declined to pull trusted_for(), at least partly because he did not like the name, but there were other reasons as well. While he is not opposed to the functionality it would provide, he also had strong feelings that a new system call was not the right approach.

David Malcolm has posted an update on the state of static analysis in GCC 12.

Some other languages, such as Perl, can track input and flag any variable that should not be trusted because it was read from an outside source such as a web form. Flagging variables in this manner is called tainting. After a program runs the variable through a check, the variable can be untainted, a process called sanitization.

Our GCC analyzer's taint mode is activated by -fanalyzer-checker=taint (which should be specified in addition to -fanalyzer). Taint mode attempts to track attacker-controlled values entering the program and to warn if they are used without sanitization.

The 4.9.310 stable kernel update has been released; the changes consist mostly of backported Spectre mitigation patches.

Security updates have been issued by Debian (thunderbird and usbguard), Fedora (containerd, firefox, golang-github-containerd-imgcrypt, nss, and vim), Oracle (firefox, kernel, kernel-container, and thunderbird), Red Hat (thunderbird), Scientific Linux (thunderbird), SUSE (libexif, mozilla-nss, mysql-connector-java, and qemu), and Ubuntu (libarchive and python-django).

Filesystems and the virtual filesystem layer are in the business of managing files that actually exist, but the Linux "dentry cache", which remembers the results of file-name lookups, also keeps track of files that don't exist. This cache of "negative dentries" plays an important role in the overall performance of the system but, if it is allowed to grow too large, its role can become negative in its own right. As the 2022 Linux Storage, Filesystem, and Memory-Management Summit (LSFMM) approaches, the subject of negative dentries has come up yet again; whether one can be positive about the prospects for a resolution this time around remains unclear.

The second 5.18 kernel prepatch is out for testing. "Things look fairly normal here, although it's early in the release cycle so it's a bit hard to say for sure. But at least it's not looking particularly odd, and we have fixes all over."

Security updates have been issued by Debian (gzip, libxml2, minidlna, openjpeg2, thunderbird, webkit2gtk, wpewebkit, xen, and xz-utils), Fedora (crun, unrealircd, and vim), Mageia (389-ds-base, busybox, flatpak, fribidi, gdal, python-paramiko, and usbredir), openSUSE (opera and seamonkey), Oracle (kernel and kernel-container), Red Hat (firefox), Scientific Linux (firefox), Slackware (libarchive), SUSE (389-ds, libsolv, libzypp, zypper, and python), and Ubuntu (python-django and tcpdump).

Version 9.0 of OpenSSH has been released. Notable changes include:

• scp(1) uses the SFTP protocol by default.
• ssh(1)/sshd(8) use the "sntrup761x25519-sha512@openssh.com" post-quantum key exchange (KEX) algorithm by default.
• ssh-agent restriction [See earlier article] is supported.
• The sftp(1) client has gained a "copy"/"cp" command that supports server-side copying of files (using the new "copy-data" protocol extension).

OpenBSD 7.1 will include the new release.

A while ago I helped a colleague, Vadim, debug a performance issue with TensorFlow in an unexpected location. I thought this was a bit interesting so I've been meaning to share it; here's a rough post of the details. ## 1. The Expert's Eye Vadim had spotted something unusual in this CPU flamegraph (redacted); do you see it?: I'm impressed he found it so quickly, but then if you look at enough flame graphs the smaller unusual patterns start to jump out. In this case there's an orange tower (kernel code) that's unusual. The cause I've highlighted here. 10% of total CPU time in page faults. At Netflix, 10% of CPU time somewhere unexpected can be a large costly issue across thousands of server instances. We'll use flame graphs to chase down the 1%s. ## 2. Why is it Still Faulting? Browsing the stack trace shows these are from __memcpy_avx_unaligned(). Well, at least that makes sense: memcpy would be faulting in a data segment mappings. But this process had been up and running for hours, and shouldn't still be doing so much page fault growth of its RSS. You see that early on when segments and the heap are fresh and don't have mappings yet, but after hours they are mostly faulted in (mapped to physical memory) and you see the faults dwindle. Sometimes processes page fault a lot because they call mmap()/munmap() to add/remove memory. I used my eBPF tools to trace them ([mmapsnoop.py]) but there was no activity. So how is it still page faulting? Is it doing madvise() and dropping memory? A search of madvise in the flame graph showed it was 0.8% of CPU, so it definitely was, and madvise() was calling zap_page_range() that was calling the faults. (Click on the [flame graph] and try Ctrl-F searching for "madvise" and zooming in.) ## 3. Premature Optimization I read the kernel code related to madvise() and zap_page_range() from mm/advise.c. That showed it calls zap_page_range() for the MADV_DONTNEED flag. (I could have also traced sys_madvise() flags using kprobes/tracepoints). This seemed to be a premature optimization gone bad: The allocator was calling dontneed on memory pages that it did in fact need. The dontneed dropped the virtual to physical mapping, which would soon afterwards cause a page fault to bring the mapping back. ## 4. Allocator Issue I suggested looking into the allocator, and Vadim said it was jemalloc, a configure option. He rebuilt with glibc, and the problem was fixed! Here's the fixed flame graph: Initial testing showed only a 3% win (can be verified by the flame graphs). We were hoping for 10%! [mmapsnoop.py]: https://github.com/brendangregg/bpf-perf-tools-book/blob/master/originals/Ch07_Memory/mmapsnoop.py [flame graph]: /blog/images/2022/cpuflamegraph.tensorflow0-red.svg

OpenSSH 9.0 has been released. It is claimed to be primarily a bug-fix release, but it also switches to a new, quantum-computer-proof key-exchange protocol by default and includes a number of sftp changes, some of which may create some compatibility issues (described in the announcement) with scp.

We consider the removal of the need for double-quoting shell characters in file names to be a benefit and do not intend to introduce bug-compatibility for legacy scp/rcp in scp(1) when using the SFTP protocol.

The readahead code in the Linux kernel is nominally responsible for reading data that has not yet been explicitly requested from storage, with the idea that it might be needed soon. The code is stable, functional, widely used, and uncontroversial, so it is reasonable to expect the code to be of high quality, and largely this is true. Recently, I found the need to document this code, which naturally shone a rather different light on it. This work revealed minor problems with functionality and significant problems with naming.

The 5.17.2, 5.16.19, 5.15.33, and 5.10.110 stable kernels have been released. These post-merge-window updates have a larger than usual set of fixes, throughout the tree. Users of those series should upgrade.

Security updates have been issued by Arch Linux (libtiff), Debian (chromium), Fedora (buildah and chromium), openSUSE (firefox), SUSE (firefox, libsolv, libzypp, and openjpeg2), and Ubuntu (firefox and python-oslo.utils).

Version 1.60.0 of the Rust language is available. Changes include coverage-testing improvements, the return of incremental compilation, and changes to the Instant type:

Prior to 1.60, the monotonicity guarantees were provided through mutexes or atomics in std, which can introduce large performance overheads to Instant::now(). Additionally, the panicking behavior meant that Rust software could panic in a subset of environments, which was largely undesirable, as the authors of that software may not be able to fix or upgrade the operating system, hardware, or virtualization system they are running on.

Cloud computing is a wonderful thing; it allows efficient use of computing systems and makes virtual machines instantly available at the click of a mouse or API call. But cloud computing can also be problematic; the security of virtual machines is dependent on the security of the host system. In most deployed systems, a host computer can dig through its guests' memory at will; users running guest systems have to just hope that doesn't happen. There are a number of solutions to that problem under development, including this KVM guest-private memory patch set by Chao Peng and others, but some open questions remain.