Connect with us

Gadgets

Linus Torvalds weighs in on Rust language in the Linux kernel

Published

on

Enlarge / No, not that kind of Rust.

This week, ZDNet’s Steven J. Vaughan-Nichols asked Linus Torvalds and Greg Kroah-Hartman about the possibility of new Linux kernel code being written in Rust—a high performance but memory-safe language sponsored by the Mozilla project.

C versus Rust

As of now, the Linux kernel is written in the C programming language—essentially, the same language used to write kernels for Unix and Unix-like operating systems since the 1970s. The great thing about C is that it’s not assembly language—it’s considerably easier to read and write, and it’s generally much closer to directly portable between hardware architectures. However, C still opens you up to nearly the entire range of catastrophic errors possible in assembly.

In particular, as a nonmemory-managed language, C opens the programmer up to memory leaks and buffer overflows. When you’re done with a variable you’ve created, you must explicitly destroy it—otherwise, old orphaned variables accumulate until the system crashes. Similarly, you must allocate memory to store data in—and if your attempt to put too much data into too-small an area of RAM, you’ll end up overwriting locations you shouldn’t.

High-level languages—such as PHP, Python, or Java—aim to be both easier to read and write and safer to write code in. A large part of the additional safety they offer comes from implicit memory management—the language itself will refuse to allow you to stuff 16K of data into a 2K buffer, thereby avoiding buffer overflows. Similarly, high-level languages automatically reclaim “orphaned” RAM via garbage collection—if a function creates a variable which can only be read by that function, then the function terminates, the language will reclaim the variable once it’s no longer accessible.

Rust, like Google’s Go, is one of a new generation of languages which aims to hit somewhere in between—it provides the raw speed, flexibility, and most of the direct mapping to hardware functionality that C would while offering a memory-safe environment.

Linux Plumbers 2020

At the Linux Plumbers conference in 2020, kernel developers began seriously discussing the idea of using Rust language inside the kernel. To be clear, the idea isn’t an entire, ground-up rewrite of the kernel in Rust—merely the addition of new code, written in Rust, which interfaces cleanly with existing kernel infrastructure.

Torvalds didn’t seem horrified at the idea—in fact, he requested that Rust compiler availability be enabled by default in the kernel-build environment. This didn’t mean that Rust-code submissions would be accepted into the kernel willy-nilly. Enabling automatic checks for Rust-compiler presence simply meant that it should be as easy as possible to get any potential submissions built (and automatically tested) properly like any other kernel code would.

Fast forward to 2021

A significant amount of work has been done on Rust in the kernel since the 2020 Linux Plumber’s Conference, including on a Rust-language port of GNU Coreutils. The port’s author, Sylvestre Ledru—a Mozilla director and Debian developer—describes it as being in working condition, though not yet production ready. Eventually, the Rust port might replace the original GNU Coreutils in some environments—offering built-in thread safety and immunity to memory management errors such as buffer overflows.

Torvalds says he’s in the “wait and see” camp about all this:

I’m interested in the project, but I think it’s driven by people who are very excited about Rust, and I want to see how it actually then ends up working in practice.

Torvalds goes on to describe device drivers as obvious low-hanging fruit for potential new work to be done in Rust. He says that because there are tons of them, and they’re relatively small and independent of other code.

Kernel maintainer Greg Kroah-Hartman agrees:

… drivers are probably the first place for an attempt like this as they are the “end leafs” of the tree of dependencies in the kernel source. They depend on core kernel functionality, but nothing depends on them.

Kroah-Hartman goes on to describe the difficulties which must be overcome for successful production integration of Rust code into a primarily C-language kernel:

It will all come down to how well the interaction between the kernel core structures and lifetime rules that are written in C can be mapped into Rust structures and lifetime rules… That’s going to take a lot of careful work by the developers wanting to hook this all up, and I wish them the best of luck.

An important first step

Although we don’t expect to see a full implementation of the Linux kernel in Rust anytime soon, this early work on integrating Rust code into the kernel’s C infrastructure is likely to be very important.

Both Microsoft and the Linux community agree that two-thirds or more of security vulnerabilities stem from memory-safety issues. As software complexity continues to increase, making it safer to write in the first place will become more and more important.

Continue Reading

Gadgets

Apple reaches quiet truce over iPhone privacy changes

Published

on

Enlarge / A privacy notice appears on an iPhone 12 under the new iOS 14.5.1 operating system. Developers of an application have to ask for the user’s permission to allow cross-app tracking.

Picture Alliance | Getty Images

Apple has allowed app developers to collect data from its 1 billion iPhone users for targeted advertising, in an unacknowledged shift that lets companies follow a much looser interpretation of its controversial privacy policy.

In May Apple communicated its privacy changes to the wider public, launching an advert that featured a harassed man whose daily activities were closely monitored by an ever-growing group of strangers. When his iPhone prompted him to “Ask App Not to Track,” he clicked it and they vanished. Apple’s message to potential customers was clear—if you choose an iPhone, you are choosing privacy.

But seven months later, companies including Snap and Facebook have been allowed to keep sharing user-level signals from iPhones, as long as that data is anonymised and aggregated rather than tied to specific user profiles.

For instance Snap has told investors that it plans to share data from its 306 million users—including those who ask Snap “not to track”—so advertisers can gain “a more complete, real-time view” on how ad campaigns are working. Any personally identifiable data will first be obfuscated and aggregated.

Similarly, Facebook operations chief Sheryl Sandberg said the social media group was engaged in a “multiyear effort” to rebuild ad infrastructure “using more aggregate or anonymized data”.

These companies point out that Apple has told developers they “may not derive data from a device for the purpose of uniquely identifying it.” This means they can observe “signals” from an iPhone at a group level, enabling ads that can still be tailored to “cohorts” aligning with certain behavior but not associated with unique IDs.

This type of tracking is becoming the norm. Oren Kaniel, the chief executive of AppsFlyer, a mobile attribution platform that works with app developers, said that when his company introduced such a “privacy-centric” tool based on aggregated measurement in July 2020, “the level of pushback that we received from the entire ecosystem was huge.”

But now such aggregated solutions are the default for 95 percent of his clients. “The market changed their minds in a radical way,” he said.

It is not clear whether Apple has actually blessed these solutions. Apple declined to answer specific questions for this article but described privacy as its North Star, implying it was setting a general destination rather than defining a narrow pathway for developers.

Cory Munchbach, chief operating officer at customer data platform BlueConic, said Apple had to stand back from a strict reading of its rules because the disruption to the mobile ads ecosystem would be too great.

“Apple can’t put themselves in a situation where they are basically gutting their top-performing apps from a user-consumption perspective,” she said. “That would ultimately hurt iOS.”

For anyone interpreting Apple’s rules strictly, these solutions break the privacy rules set out to iOS users.

Lockdown Privacy, an app that blocks ad trackers, has called Apple’s policy “functionally useless in stopping third-party tracking.” It performed a variety of tests on top apps and observed that personal data and device information is still “being sent to trackers in almost all cases.”

But the companies aggregating user-level data said the reason apps continue to “leak” information such as a user’s IP address and location was simply because some require such information to function. Advertisers must know certain things such as the user’s language or the device screen size, otherwise the app experience would be awful.

The risk is that by allowing user-level data to be used by opaque third parties so long as they promise not to abuse it, Apple is in effect trusting the very same groups that chief executive Tim Cook has lambasted as “hucksters just looking to make a quick buck.”

Companies will pledge that they only look at user-level data once it has been anonymized, but without access to the data or algorithms working behind the scenes, users won’t really know if their data privacy has been preserved, said Munchbach.

“If historical precedent in adtech holds, those black boxes hide a lot of sins,” she said. “It’s not unreasonable to assume it leaves a lot to be desired.”

© 2021 The Financial Times Ltd. All rights reserved Not to be redistributed, copied, or modified in any way.

Continue Reading

Gadgets

Roku vs. Google drama winds down as companies forge multi-year YouTube deal

Published

on

Enlarge / Roku’s 4K Streaming Stick.

Roku

Roku and Google have arrived at a multi-year deal that will keep the YouTube and YouTube TV apps available on Roku’s devices, Roku announced on Twitter this morning. The agreement comes months after the YouTube TV app was pulled from the Roku Channel Store and just one day before the regular YouTube app would have been removed from the store.

Specific terms of the deal haven’t been announced, including how many years “multi-year” means and whether Roku will begin adding decoding support for the AV1 video codec to its hardware. We also don’t know whether the $65-per-month YouTube TV service will return to the Roku store as its own dedicated app or if it will continue to be rolled into the main YouTube app, as it has been since Google added it there to sidestep Roku’s restrictions in May.

Support for the AV1 codec has been one of the major sticking points between the two companies. The YouTube and YouTube TV apps use AV1 (which is backed by Google, among other companies) to deliver compressed 4K and 8K video streams. But because streaming devices tend to use slower, cheaper processors, they rely on dedicated video decoding hardware to be able to actually decompress and display those video files, and while most of these devices support the commonly used H.265/HEVC codec for high-resolution video streams, fewer support the royalty-free AV1 codec.

Roku has said that adding AV1 support to its devices would “increase consumer costs,” and requiring it for YouTube and YouTube TV support would effectively allow Google to dictate which chips Roku uses in its own products. Google has also accused Roku of using its position in the streaming-device market to secure more favorable terms (Roku’s devices account for a plurality of all streaming in North America, though its market share is lower in other regions). The YouTube and YouTube TV apps may not be able to stream high-resolution video on devices without AV1 support, though having those apps available in Roku’s store in any capacity is probably better for both companies than allowing them to be pulled entirely.

Continue Reading

Gadgets

Razer’s RGB smartphone cooler attaches to iPhones with MagSafe

Published

on

Enlarge / Razer Phone Cooler Chroma.

PC gamers know about heat. When you’re in the middle of an intense in-game battle, the last thing you want is for your computer to start acting up because your CPU or GPU got too hot. That’s why gamers and other extreme users rely on products like CPU coolers and liquid cooling systems. You probably haven’t been as concerned about your smartphone’s thermals while playing Candy Crush on your iPhone. Nevertheless, Razer released a new product, the Phone Cooler Chroma, on Tuesday to ensure your smartphone doesn’t overheat the next time you use it for gaming.

Of course, mobile gaming has grown beyond the likes of Candy Crush and Angry Birds. Razer (and some other vendors) have been trying to make mobile gaming a serious thing for a while. The company’s efforts are mostly focused on controllers, like the Razer Kishi, that attach to your smartphone. There’s also Razer’s finger sleeve for mobile gaming.

The Phone Cooler Chroma released Tuesday has a different purpose. Compatible with both iPhone and Android phones (it supports “most smartphones,” Razer’s product page claims), the product is meant to help keep your phone cool while it’s pushing those frames.

Interestingly, the fan takes advantage of Apple’s MagSafe, allowing you to attach the cooler magnetically. That’s convenient, but it also means the cooler won’t sit directly above the phone’s SoC.

If you don’t have a MagSafe-compatible phone, you can opt for the version with a universal clamp.

Clamp option.

We don’t know how adjustable the cooler is, but Razer says it works with phones that are 2.64-3.46 inches (67-88 mm) wide.

Staying cool?

1. RGB, 2. cover, 3. fan, 4. heatsink, 5. Peltier cooling tile, 6. cooling plate.
Enlarge / 1. RGB, 2. cover, 3. fan, 4. heatsink, 5. Peltier cooling tile, 6. cooling plate.

A cooling plate sits on the back cover and is topped by an electronic tile that uses Peltier cooling, also known as thermoelectric cooling, to transfer heat. The next layer is a heatsink under a seven-bladed fan spinning at up to 6,400 revolutions per minute, adjustable via Bluetooth. Razer says the cooler can stay at 30 dB.

On top of the fan lies a cover with air vents, and—of course—RGB lighting. Does the lighting help your phone stay cool? Absolutely not. But it almost wouldn’t be a Razer product without it. The gaming brand even put RGB on its N95 mask, so Chroma lighting here is no surprise.

RGB feels like a Razer requirement.
Enlarge / RGB feels like a Razer requirement.

There are 12 RGB LEDs in the cover, and each can be set to its own color and effect.

You’ll need a USB-C cable to power the Phone Cooler Chroma. The cooler comes with a 4.9-foot (1.5 m) USB-C to USB-C cable, but this seems like it could be burdensome when gaming on the go, as a mobile gamer is inclined to do.

Power over USB-C required.
Enlarge / Power over USB-C required.

Razer didn’t make any claims about how much cooler the product will keep your phone’s components. Unlike a CPU cooler, this cooler doesn’t come into direct contact with the processor, and it doesn’t have any exhaust vents to work with as some laptop fan coolers do. So the heat transfer from the actual SoC may be limited. Hardcore mobile gamers can find out for themselves for $60.

Ars Technica may earn compensation for sales from links on this post through affiliate programs.

Continue Reading

Trending