Language Selection

English French German Italian Portuguese Spanish

Kernel: LWN Coverage (No Longer Paywalled) and Initial HDMI 2.0 Support With Nouveau Slated For The Next Linux Kernel

Filed under
Linux
  • Revenge of the modems

    Back in the halcyon days of the previous century, those with a technical inclination often became overly acquainted with modems—not just the strange sounds they made when connecting, but the AT commands that were used to control them. While the AT command set is still in use (notably for GSM networks), it is generally hidden these days. But some security researchers have found that Android phones often make AT commands available via their USB ports, which is something that can potentially be exploited by rogue USB devices of various sorts.

    A paper [PDF] that was written by a long list of researchers (Dave (Jing) Tian, Grant Hernandez, Joseph I. Choi, Vanessa Frost, Christie Ruales, Patrick Traynor, Hayawardh Vijayakumar, Lee Harrison, Amir Rahmati, Michael Grace, and Kevin R. B. Butler) and presented at the 27th USENIX Security Symposium described the findings. A rather large number of Android firmware builds were scanned for the presence of AT commands and many were found to have them. That's not entirely surprising since the baseband processors used to communicate with the mobile network often use AT commands for configuration. But it turns out that Android vendors have also added their own custom AT commands that can have a variety of potentially harmful effects—making those available over USB is even more problematic.

    They started by searching through 2018 separate Android binary images (it is not clear how that number came about, perhaps it is simply coincidental) from 11 different vendors. They extracted and decompressed the various pieces inside the images and then searched those files for AT command strings. That process led to a database of 3500 AT commands, which can be seen at the web site for ATtention Spanned—the name given to the vulnerabilities.

  • XFS, LSM, and low-level management APIs

    The Linux Security Module (LSM) subsystem allows security modules to hook into many low-level operations within the kernel; modules can use those hooks to examine each requested operation and decide whether it should be allowed to proceed or not. In theory, just about every low-level operation is covered by an LSM hook; in practice, there are some gaps. A discussion regarding one of those gaps — low-level ioctl() operations on XFS filesystems — has revealed a thorny problem and a significant difference of opinion on what the correct solution is.

    In late September Tong Zhang pointed out that xfs_file_ioctl(), the 300-line function that dispatches the various ioctl() operations that can be performed on an XFS filesystem, was making a call to vfs_readlink() without first consulting the security_inode_readlink() LSM hook. As a result, a user with the privilege to invoke that operation (CAP_SYS_ADMIN) could read the value of a symbolic link within the filesystem, even if the security policy in place would otherwise forbid it. Zhang suggested that a call to the LSM hook should be added to address this problem.

  • Initial HDMI 2.0 Support With Nouveau Slated For The Next Linux Kernel

    Days after Nouveau DRM maintainer Ben Skeggs began staging changes for this open-source NVIDIA driver ahead of the next kernel cycle, this evening Ben Skeggs submitted the DRM-Next pull request to queue this work for the Linux 4.20/5.0 kernel cycle.

    As covered in that previous article, there isn't a whole lot on the Nouveau kernel driver front at this time. Skeggs summed up these open-source NVIDIA driver changes as: "Just initial HDMI 2.0 support, and a bunch of other cleanups."

  • Device-to-device memory-transfer offload with P2PDMA

    One of the most common tasks carried out by device drivers is setting up DMA operations for data transfers between main memory and the device. Often, data read into memory from one device will be immediately written, unchanged, to another device. Common examples include carrying the image between the camera and screen on a mobile phone, or downloading files to be saved on a disk. Those transfers have an impact on the CPU even if it does not use the data directly, due to higher memory use and effects like cache trashing. There are cases where it is possible to avoid usage of the system memory completely, though. A patch set (posted by Logan Gunthorpe with contributions by Christoph Hellwig and Steve Wise) has been in the works for some time that addresses this case for PCI devices using peer-to-peer (P2P) transfers, with a focus on offering an offload option for the NVMe fabrics target subsystem.

More in Tux Machines

The Last Independent Mobile OS

The year was 2010 and the future of mobile computing was looking bright. The iPhone was barely three years old, Google’s Android had yet to swallow the smartphone market whole, and half a dozen alternative mobile operating systems—many of which were devoutly open source—were preparing for launch. Eight years on, you probably haven’t even heard of most of these alternative mobile operating systems, much less use them. Today, Android and iOS dominate the global smartphone market and account for 99.9 percent of mobile operating systems. Even Microsoft and Blackberry, longtime players in the mobile space with massive revenue streams, have all but left the space. Then there’s Jolla, the small Finnish tech company behind Sailfish OS, which it bills as the “last independent alternative mobile operating system.” Jolla has had to walk itself back from the edge of destruction several times over the course of its seven year existence, and each time it has emerged battered, but more determined than ever to carve out a spot in the world for a truly independent, open source mobile operating system. After years of failed product launches, lackluster user growth, and supply chain fiascoes, it’s only been in the last few months that things finally seem to be turning to Jolla’s favor. Over the past two years the company has rode the wave of anti-Google sentiment outside the US and inked deals with large foreign companies that want to turn Sailfish into a household name. Despite the recent success, Jolla is far from being a major player in the mobile market. And yet it also still exists, which is more than can be said of every other would-be alternative mobile OS company. Read more

How I Quit Apple, Microsoft, Google, Facebook, and Amazon

It was just before closing time at a Verizon store in Bushwick, New York last May when I burst through the door, sweaty and exasperated. I had just sprinted—okay I walked, but briskly—from another Verizon outlet a few blocks away in the hopes I’d make it before they closed shop for the night. I was looking for a SIM card that would fit a refurbished 2012 Samsung Galaxy S3 that I had recently purchased on eBay, but the previous three Verizon stores I visited didn’t have any chips that would fit such an old model. When I explained my predicament to the salesperson, he laughed in my face. “You want to switch from you current phone to an... S3?” he asked incredulously. I explained my situation. I was about to embark on a month without intentionally using any services or products produced by the so-called “Big Five” tech companies: Amazon, Apple, Facebook, Google, and Microsoft. At that point I had found adequate, open source replacements for most of the services offered by these companies, but ditching the Android OS, which is developed by Google, was proving difficult. Most of the tech I use on a day-to-day basis is pretty utilitarian. At the time I was using a cheap ASUS laptop at work and a homebrew PC at my apartment. My phone was a Verizon-specific version of the Samsung Galaxy J3, a 2016 model that cost a little over $100 new. They weren't fancy, but they’ve reliably met most of my needs for years. For the past week and a half I had spent most of my evenings trying to port an independent mobile OS called Sailfish onto my phone without any luck. As it turned out, Verizon had locked the bootloader on my phone model, which is so obscure that no one in the vibrant Android hacking community had dedicated much time to figuring out a workaround. If I wanted to use Sailfish, I was going to have to get a different phone. Read more

RISC-V Will Stop Hackers Dead From Getting Into Your Computer

The greatest hardware hacks of all time were simply the result of finding software keys in memory. The AACS encryption debacle — the 09 F9 key that allowed us to decrypt HD DVDs — was the result of encryption keys just sitting in main memory, where it could be read by any other program. DeCSS, the hack that gave us all access to DVDs was again the result of encryption keys sitting out in the open. Because encryption doesn’t work if your keys are just sitting out in the open, system designers have come up with ingenious solutions to prevent evil hackers form accessing these keys. One of the best solutions is the hardware enclave, a tiny bit of silicon that protects keys and other bits of information. Apple has an entire line of chips, Intel has hardware extensions, and all of these are black box solutions. They do work, but we have no idea if there are any vulnerabilities. If you can’t study it, it’s just an article of faith that these hardware enclaves will keep working. Now, there might be another option. RISC-V researchers are busy creating an Open Source hardware enclave. This is an Open Source project to build secure hardware enclaves to store cryptographic keys and other secret information, and they’re doing it in a way that can be accessed and studied. Trust but verify, yes, and that’s why this is the most innovative hardware development in the last decade. Read more

ONAP Myths Debunked

The Linux Foundation’s Open Network Automation Platform (ONAP) is well into its third 6-month release (Casablanca came out in Dec ’18), and while the project has evolved since it’s first release, there is still some confusion about what it is and how it’s architected. This blogs takes a closer look at ONAP, under-the-hood, to clarify how it works. To start, it is important to consider what functionality ONAP includes. I call ONAP a MANO++, where ONAP includes the NFVO and VNFM layers as described by ETSI, but goes beyond by including service assurance/automation and a unified design tool. ONAP does not include the NFVI/VIM or the NFV cloud layer. In other words, ONAP doesn’t really care whether the NFV cloud is OpenStack, Kubernetes or Microsoft Azure. Nor does ONAP include VNFs. VNFs come from third-party companies or open source projects but have VNF guidelines and onboarding SDKs that ease the deployment. In other words, ONAP is a modular platform for complete Network Automation. Read more