Brief items

Removing syscall() from OpenBSD

For a view into the OpenBSD approach to security, see this message from Theo de Raadt, where he describes a plan to remove the syscall() system call (which allows the invocation of any available system call by providing its number) from the kernel. The purpose, of course, is to make it harder for an attacker to invoke an arbitrary system call, even if they are able to run some code on the target system.

I hope I am forcing attack coders into using increasingly more complicated methods. Same time, it means fewer methods are available. Other methods make exploitation more fragile. This is pushing success rates into "low-percent statistical" success. If we teach more software stacks to "fail hard, don't try to recover", that is an improvement in security.

Full Story (comments: 33)

Security quote of the week

Amazon can do this because the Alexa's operating system sits behind a cryptographic lock, and any tool that bypasses that lock is a felony under Section 1201 of the DMCA, punishable by a 5-year prison sentence and a $500,000 fine. That means that it's literally a crime to provide a rival OS that lets users retain functionality that Amazon no longer supports.

This is the proverbial gun on the mantelpiece, a moral hazard and invitation to mischief that tempts Amazon executives to run a bait-and-switch con where they sell you a gadget with five features and then remotely kill-switch two of them. This is prime directive of the Darth Vader MBA: "I am altering the deal. Pray I don't alter it any further."

— Cory Doctorow on Amazon killing Alexa integration with IFTTT

Comments (29 posted)

Kernel release status

The 6.6 kernel was released on October 29; Linus commented: "So this last week has been pretty calm, and I have absolutely no excuses to delay the v6.6 release any more, so here it is."

Headline features in 6.6 include the earliest eligible virtual deadline first (EEVDF) CPU scheduler, a number of enhancements (quota support, user extended attributes, direct I/O) to the tmpfs filesystem, the fchmodat2() system call, initial support for building a kernel without buffer-head support, the kmalloc() randomness patches, user-space shadow stacks for Intel CPUs, and quite a bit more. See the LWN merge window summaries (part 1, part 2) and the KernelNewbies 6.6 page for more information.

Stable updates: none have been released in the last week. The 6.5.10 and 6.1.61 updates are in the review process; they are due on or after November 2.

Comments (1 posted)

Garrett: Why ACPI?

Matthew Garrett explains why ACPI exists and why it is not as bad a thing as some think.

There's an alternative universe where we decided to teach the kernel about every piece of hardware it should run on. Fortunately (or, well, unfortunately) we've seen that in the ARM world. Most device-specific simply never reaches mainline, and most users are stuck running ancient kernels as a result. Imagine every x86 device vendor shipping their own kernel optimised for their hardware, and now imagine how well that works out given the quality of their firmware. Does that really seem better to you?

Comments (50 posted)

A recent talk on kernel maintainership

LWN editor Jonathan Corbet was asked to give a brief talk about kernel maintainership at the recently concluded Linux Foundation Member Summit. That talk was recorded and has now been made available on YouTube. There is little in it that will be news to regular LWN readers, but it may be instructive to folks who are less well versed in how kernel development works.

Comments (5 posted)

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

The New Stack covers a conference talk by Bjarne Stroustrup on turning C++ into a safer language.

Stroustrup has arrived at his solution: profiles. (That is, a set of rules which, when followed, achieve specific safety guarantees.) They’d be defined by the ISO C++ standard, addressing common safety issues like pointers and array ranges. In response to a later question from the audience about the difficulty of adding new tooling, Stroustrup pointed out that the C++ compiler itself is now a pretty sophisticated static analyzer, and could also be tasked with meeting the profile's requirements.

Comments (328 posted)

Incus 0.2 released

Version 0.2 of Incus, an LXD fork, has been released. "This version incorporates most changes that went into LXD 5.19 as well as introduce a few additional features and improvements." Changes include NVME storage support, support for migrating clustered environments from LXD, and more.

Comments (4 posted)