All posts by corbet

Behind the One-Way Mirror (EFF)

Post Syndicated from corbet original https://lwn.net/Articles/807044/rss

The Electronic Frontier Foundation has posted a detailed
study
on third-party corporate surveillance on the Internet (and
beyond). “Both Google and Apple encourage developers to use ad IDs
for behavioral profiling in lieu of other identifiers like IMEI or phone
number. Ostensibly, this gives users more control over how they are
tracked, since users can reset their identifiers by hand if they
choose. However, in practice, even if a user goes to the trouble to reset
their ad ID, it’s very easy for trackers to identify them across resets by
using other identifiers, like IP address or in-app storage. Android’s
developer policy instructs trackers not to engage in such behavior, but the
platform has no technical safeguards to stop it. In February 2019, a study
found that over 18,000 apps on the Play store were violating Google’s
policy.

Vetter: Upstream Graphics: Too Little, Too Late

Post Syndicated from corbet original https://lwn.net/Articles/806892/rss

Daniel Vetter has posted a
summary of his LPC talk
on kernel graphics drivers.
Unfortunately the business case for ‘upstream first’ on the kernel
side is completely broken. Not for open source, and not for any fundamental
reasons, but simply because the kernel moves too slowly, is too big,
drivers aren’t well contained enough and therefore customer will not or
even can not upgrade. For some hardware upstreaming early enough is
possible, but graphics simply moves too fast: By the time the upstreamed
driver is actually in shipping distros, it’s already one hardware
generation behind. And missing almost a year of tuning and performance
improvements. Worse it’s not just new hardware, but also GL and Vulkan
versions that won’t work on older kernels due to missing features,
fragmenting the ecosystem further.

[$] The end of the 5.5 merge window

Post Syndicated from corbet original https://lwn.net/Articles/806576/rss

By the end of the merge window, 12,632 non-merge changesets had been
pulled into the mainline repository for the 5.5 release. This is thus a
busy development cycle — just like the cycles that preceded it. Just over
half of those changesets were pulled after the writing of our first 5.5 merge-window summary. As is
often the case later in the merge window, many of those changes were
relatively boring fixes. There were still a number of interesting changes,
though; read on for a summary of what happened in the second half of this
merge window.

Kernel prepatch 5.5-rc1

Post Syndicated from corbet original https://lwn.net/Articles/806772/rss

Linus has released the 5.5-rc1 kernel
prepatch and closed the merge window for this development cycle. “Everything looks fairly regular – it’s a tiny bit larger (in commit
counts) than the few last merge windows have been, but not bigger
enough to really raise any eyebrows. And there’s nothing particularly
odd in there either that I can think of: just a bit over half of the
patch is drivers, with the next big area being arch updates. Which is
pretty much the rule for how things have been forever by now.

Outside of that, the documentation and tooling (perf and selftests)
updates stand out, but that’s actually been a common pattern for a
while now too, so it’s not really surprising either.”

[$] Developers split over split-lock detection

Post Syndicated from corbet original https://lwn.net/Articles/806466/rss

A “split lock” is a low-level memory-bus lock taken by the processor for a memory
range that crosses a cache line. Most processors disallow split locks, but
x86 implements them, Split locking may be convenient for developers, but
it comes at a cost: a single split-locked instruction can occupy the memory
bus for around 1,000 clock cycles. It is thus understandable that interest
in eliminating split-lock operations is high. What is perhaps less
understandable is that a patch set intended to detect split locks has been
pending since (at least) May 2018, and it still is not poised to enter the
mainline.

VPN hijacking on Linux (and beyond) systems

Post Syndicated from corbet original https://lwn.net/Articles/806546/rss

William Tolley has disclosed a severe VPN-related problem in most current
systems: “I am reporting a vulnerability that exists on most Linux distros, and
other *nix operating systems which allows a network adjacent attacker
to determine if another user is connected to a VPN, the virtual IP
address they have been assigned by the VPN server, and whether or not
there is an active connection to a given website. Additionally, we are
able to determine the exact seq and ack numbers by counting encrypted
packets and/or examining their size. This allows us to inject data into
the TCP stream and hijack connections.
” There are various partial
mitigations available, but a full solution to the problem has not yet been
worked out. Most VPNs are vulnerable, but Tor evidently is not.

[$] Debian votes on init systems

Post Syndicated from corbet original https://lwn.net/Articles/806332/rss

In November, the topic of init systems and, in particular, support for
systems other than systemd reappeared on the
Debian mailing lists
. After one month of sometimes fraught discussion,
this issue has been brought to the project’s developers to decide in the
form of a general
resolution (GR) — the first such since the project voted on the status of
debian-private discussions
in 2016. The issues under discussion are
complex, so the result is one of the most complex ballots seen for some
time in Debian, with seven options to choose from.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

Post Syndicated from corbet original https://lwn.net/Articles/806266/rss

ZDNet reports
that two more malicious modules have been removed from the Python Package
Index. “The two libraries were created by the same developer and mimicked other more popular libraries — using a technique called typosquatting to register similarly-looking names.

The first is ‘python3-dateutil,’ which imitated the popular ‘dateutil’
library. The second is ‘jeIlyfish’ (the first L is an I), which mimicked
the ‘jellyfish’ library.” The latter of the two had been in PyPI
for nearly a year.

Wielaard: A public discussion about GNU

Post Syndicated from corbet original https://lwn.net/Articles/806184/rss

Mark Wielaard has posted a
summary of the discussion thus far
on the governance of the GNU
project. “The mentoring and apprenticeship discussion focused on the
GNU maintainers as being the core of the GNU project. But as was pointed
out there are also webmasters, translators, infrastructure maintainers
(partially paid FSF staff and volunteers), education and conference
organizers, etc. All these people are GNU stakeholders. And how we organize
governance of the GNU project should also involve them.

[$] Fixing SCHED_IDLE

Post Syndicated from corbet original https://lwn.net/Articles/805317/rss

The Linux kernel scheduler is a complicated beast
and a lot of effort goes into improving it during every kernel release
cycle. The 5.4 kernel release includes a few improvements to the existing
SCHED_IDLE scheduling policy that can help users improve the
scheduling latency of their high-priority (interactive) tasks if they use
the SCHED_IDLE policy for the lowest-priority (background)
tasks. Read on for a description of this work contributed by Viresh Kumar.

The 5.4 kernel has been released

Post Syndicated from corbet original https://lwn.net/Articles/805462/rss

Linus has released the 5.4 kernel.
Not a lot happened this last week, which is just how I like
it
“. Significant features in this release include
the haltpoll
CPU governor,
the iocost (formerly io.weight) I/O
controller,
the EROFS filesystem,
an implementation of the exFAT filesystem
that may yet be superseded by a better version,
the fs-verity file integrity mechanism,
support for the BPF
compile once, run everywhere
mechanism,
the dm-clone
device mapper target,
the virtiofs
filesystem,
kernel lockdown support (at last),
kernel symbol namespaces, and a new
random-number generator meant to solve the
early-boot entropy problem.
See the KernelNewbies 5.4
page
for a lot more details.

[$] Fedora’s modularity mess

Post Syndicated from corbet original https://lwn.net/Articles/805180/rss

Fedora’s Modularity
initiative
has been no stranger to controversy since its inception in 2016. Among other things, there
were enough problems with the original design that Modularity went back to the drawing board in early 2018.
Modularity has since been integrated with both the Fedora and Red Hat
Enterprise Linux (RHEL) distributions, but the controversy continues, with
some developers asking whether it’s time for yet another redesign — or to
abandon the idea altogether. Over the last month or so, several lengthy,
detailed, and heated threads have explored this issue; read on for your
editor’s attempt to integrate what was said.

[$] Some near-term arm64 hardening patches

Post Syndicated from corbet original https://lwn.net/Articles/804982/rss

The arm64 architecture is found at the core of many, if not most, mobile
devices; that means that arm64 devices are destined to be the target of
attackers worldwide. That has led to a high level of interest in
technologies that can harden these systems. There are currently several
such technologies, based in both hardware and software, that are being
readied for the arm64 kernel; read on for a survey on what is
coming.

Kernel prepatch 5.4-rc8

Post Syndicated from corbet original https://lwn.net/Articles/805038/rss

As expected, 5.4-rc8 was released on
November 17 rather than the final 5.4 release.
I’m not entirely sure we need an rc8, because last week was pretty
calm despite the Intel hw workarounds landing. So I considered just
making a final 5.4 and be done with it, but decided that there’s no
real downside to just doing the rc8 after having a release cycle that
took a while to calm down.

[$] Keeping memory contents secret

Post Syndicated from corbet original https://lwn.net/Articles/804658/rss

One of the many responsibilities of the operating system is to help
processes keep secrets from each other. Operating systems often fail in
this regard, sometimes due to factors — such as hardware bugs and user-space
vulnerabilities — that are beyond their direct control. It is thus
unsurprising that there is an increasing level of interest in ways to
improve the ability to keep data secret, perhaps even from the operating
system itself. The MAP_EXCLUSIVE
patch set from Mike Rapoport is one example of the work that is being done
in this area; it also shows that the development community has not yet
really begun to figure out how this type of feature should work.