Tag Archives: Meltdown

Another Spectre-Like CPU Vulnerability

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2018/05/another_spectre.html

Google and Microsoft researchers have disclosed another Spectre-like CPU side-channel vulnerability, called “Speculative Store Bypass.” Like the others, the fix will slow the CPU down.

The German tech site Heise reports that more are coming.

I’m not surprised. Writing about Spectre and Meltdown in January, I predicted that we’ll be seeing a lot more of these sorts of vulnerabilities.

Spectre and Meltdown are pretty catastrophic vulnerabilities, but they only affect the confidentiality of data. Now that they — and the research into the Intel ME vulnerability — have shown researchers where to look, more is coming — and what they’ll find will be worse than either Spectre or Meltdown.

I still predict that we’ll be seeing lots more of these in the coming months and years, as we learn more about this class of vulnerabilities.

Schaller: Warming up for Fedora Workstation 28

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

Christian Schaller looks
forward to the Fedora 28 release
(which will evidently be the first on-time Fedora release ever).
The Spectre/Meltdown situation did hammer home to a lot of people
the need to have firmware updates easily available and easy to update. We
created the Linux Vendor Firmware service for Fedora Workstation users with
that in mind and it was great to see the service paying off for many Linux
users, not only on Fedora, but also on other distributions who started
using the service we provided. I would like to call out to Dell who was a
critical partner for the Linux Vendor Firmware effort from day 1 and thus
their users got the most benefit from it when Spectre and Meltdown
hit. Spectre and Meltdown also helped get a lot of other vendors off the
fence or to accelerate their efforts to support LVFS and Richard Hughes and
Peter Jones have been working closely with a lot of new vendors during this
cycle to get support for their hardware and devices into LVFS.

[$] A page-table isolation update

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

Dave Hansen did much of the work to get kernel page-table isolation
(PTI) into the kernel in response to the Meltdown CPU vulnerability. In the
memory-management track of the
2018 Linux Storage, Filesystem, and Memory-Management Summit, he ran a
discussion on how PTI came about, what the costs are, and what can be done
to minimize its performance impact.

[$] The impact of page-table isolation on I/O performance

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

Ever since kernel page-table isolation
(PTI)
was introduced as a mitigation for
the Meltdown CPU vulnerability, users have worried about how it affects the
performance of their systems. Most of that concern has been directed
toward its impact on computing performance, but I/O performance also
matters. At the 2018 Linux Storage, Filesystem, and Memory-Management
Summit, Ming Lei presented some preliminary work he has done to try to
quantify how severely PTI affects block I/O operations.

[$] Finding Spectre vulnerabilities with smatch

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

The furor over the Meltdown and Spectre vulnerabilities has calmed a bit —
for now, at least — but that does not mean that developers have stopped
worrying about them. Spectre variant 1 (the bounds-check bypass
vulnerability) has been of particular concern because, while the kernel is
thought to contain numerous vulnerable spots, nobody really knows how to
find them all. As a result, the defenses that have been developed for
variant 1 have only been deployed in a few places. Recently, though,
Dan Carpenter has enhanced the smatch tool to enable it to find possibly
vulnerable code in the kernel.

The 4.16 kernel is out

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

Linus has released the 4.16 kernel, as
expected. “We had a number of fixes and cleanups elsewhere, but none
of it made me go ‘uhhuh, better let this soak for another week’
“.
Some of the headline changes in this release include initial support for
the Jailhouse
hypervisor, the usercopy whitelisting
hardening patches, some improvements to the deadline scheduler and, of
course, a lot of Meltdown and Spectre mitigation work.

Another Branch Prediction Attack

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2018/03/another_branch_.html

When Spectre and Meltdown were first announced earlier this year, pretty much everyone predicted that there would be many more attacks targeting branch prediction in microprocessors. Here’s another one:

In the new attack, an attacker primes the PHT and running branch instructions so that the PHT will always assume a particular branch is taken or not taken. The victim code then runs and makes a branch, which is potentially disturbing the PHT. The attacker then runs more branch instructions of its own to detect that disturbance to the PHT; the attacker knows that some branches should be predicted in a particular direction and tests to see if the victim’s code has changed that prediction.

The researchers looked only at Intel processors, using the attacks to leak information protected using Intel’s SGX (Software Guard Extensions), a feature found on certain chips to carve out small sections of encrypted code and data such that even the operating system (or virtualization software) cannot access it. They also described ways the attack could be used against address space layout randomization and to infer data in encryption and image libraries.

Research paper.

Qubes OS 4.0 has been released

Post Syndicated from ris original https://lwn.net/Articles/750318/rss

The security-focused distribution Qubes OS has released
version 4.0. “This release delivers on the features we promised in
our announcement
of Qubes 4.0-rc1
, with some course corrections along the way, such as
the switch from HVM to PVH for most VMs in response to Meltdown
and Spectre
. For more details, please see the full Release Notes.

[$] The strange story of the ARM Meltdown-fix backport

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

Alex Shi’s posting of a patch series
backporting a set of Meltdown fixes for the arm64 architecture to the
4.9 kernel might seem like a normal exercise in making important security
fixes available on older kernels. But this case raised a couple of
interesting questions about why this backport should be accepted into the
long-term-support kernels — and a couple of equally interesting answers,
one of which was rather better received than the other.

New Spectre/Meltdown Variants

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2018/02/new_spectremelt.html

Researchers have discovered new variants of Spectre and Meltdown. The software mitigations for Spectre and Meltdown seem to block these variants, although the eventual CPU fixes will have to be expanded to account for these new attacks.

[$] Meltdown and Spectre mitigations — a February update

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

The initial panic over the Meltdown and Spectre processor vulnerabilities
has faded, and work on mitigations in the kernel has slowed since our mid-January report. That work has not
stopped, though. Fully equipping the kernel to protect systems from these
vulnerabilities is a task that may well require years. Read on for an
update on the current status of that work.

Huang: Spectre/Meltdown Pits Transparency Against Liability

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

Here’s a blog post
from “bunnie” Huang
on the tension between transparency and product
liability around hardware flaws. “The open source community could
use the Spectre/Meltdown crisis as an opportunity to reform the status
quo. Instead of suing Intel for money, what if we sue Intel for
documentation? If documentation and transparency have real value, then this
is a chance to finally put that value in economic terms that Intel
shareholders can understand. I propose a bargain somewhere along these
lines: if Intel releases comprehensive microarchitectural hardware design
specifications, microcode, firmware, and all software source code (e.g. for
AMT/ME) so that the community can band together to hammer out any other
security bugs hiding in their hardware, then Intel is absolved of any
payouts related to the Spectre/Meltdown exploits.

[$] The effect of Meltdown and Spectre in our communities

Post Syndicated from jake original https://lwn.net/Articles/745674/rss

A late-breaking development in the computing world led to a somewhat
hastily arranged panel discussion at this year’s linux.conf.au in Sydney.
The embargo for the Meltdown and Spectre
vulnerabilities

broke on January 4; three weeks later, Jonathan Corbet convened
representatives from five separate parts of our community, from cloud to
kernel to the BSDs and beyond. As Corbet noted in the opening, the panel
itself was organized much like the response to the vulnerabilities
themselves, which is why it didn’t even make it onto the conference schedule
until a few hours earlier.

The 4.15 kernel is out

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

Linus has released the 4.15 kernel.
After a release cycle that was unusual in so many (bad) ways, this
last week was really pleasant. Quiet and small, and no last-minute
panics, just small fixes for various issues. I never got a feeling
that I’d need to extend things by yet another week, and 4.15 looks
fine to me.

Some of the more significant features in this release include:
the long-awaited CPU controller for the
version-2 control-group interface,
significant live-patching improvements,
initial support for the RISC-V architecture,
support for AMD’s secure encrypted virtualization feature, and
the MAP_SYNC mechanism for working
with nonvolatile memory.
This release also, of course, includes mitigations for the Meltdown and Spectre variant-2
vulnerabilities
though, as Linus points out in the announcement, the
work of dealing with these issues is not yet done.

The Effects of the Spectre and Meltdown Vulnerabilities

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2018/01/the_effects_of_3.html

On January 3, the world learned about a series of major security vulnerabilities in modern microprocessors. Called Spectre and Meltdown, these vulnerabilities were discovered by several different researchers last summer, disclosed to the microprocessors’ manufacturers, and patched­ — at least to the extent possible.

This news isn’t really any different from the usual endless stream of security vulnerabilities and patches, but it’s also a harbinger of the sorts of security problems we’re going to be seeing in the coming years. These are vulnerabilities in computer hardware, not software. They affect virtually all high-end microprocessors produced in the last 20 years. Patching them requires large-scale coordination across the industry, and in some cases drastically affects the performance of the computers. And sometimes patching isn’t possible; the vulnerability will remain until the computer is discarded.

Spectre and Meltdown aren’t anomalies. They represent a new area to look for vulnerabilities and a new avenue of attack. They’re the future of security­ — and it doesn’t look good for the defenders.

Modern computers do lots of things at the same time. Your computer and your phone simultaneously run several applications — ­or apps. Your browser has several windows open. A cloud computer runs applications for many different computers. All of those applications need to be isolated from each other. For security, one application isn’t supposed to be able to peek at what another one is doing, except in very controlled circumstances. Otherwise, a malicious advertisement on a website you’re visiting could eavesdrop on your banking details, or the cloud service purchased by some foreign intelligence organization could eavesdrop on every other cloud customer, and so on. The companies that write browsers, operating systems, and cloud infrastructure spend a lot of time making sure this isolation works.

Both Spectre and Meltdown break that isolation, deep down at the microprocessor level, by exploiting performance optimizations that have been implemented for the past decade or so. Basically, microprocessors have become so fast that they spend a lot of time waiting for data to move in and out of memory. To increase performance, these processors guess what data they’re going to receive and execute instructions based on that. If the guess turns out to be correct, it’s a performance win. If it’s wrong, the microprocessors throw away what they’ve done without losing any time. This feature is called speculative execution.

Spectre and Meltdown attack speculative execution in different ways. Meltdown is more of a conventional vulnerability; the designers of the speculative-execution process made a mistake, so they just needed to fix it. Spectre is worse; it’s a flaw in the very concept of speculative execution. There’s no way to patch that vulnerability; the chips need to be redesigned in such a way as to eliminate it.

Since the announcement, manufacturers have been rolling out patches to these vulnerabilities to the extent possible. Operating systems have been patched so that attackers can’t make use of the vulnerabilities. Web browsers have been patched. Chips have been patched. From the user’s perspective, these are routine fixes. But several aspects of these vulnerabilities illustrate the sorts of security problems we’re only going to be seeing more of.

First, attacks against hardware, as opposed to software, will become more common. Last fall, vulnerabilities were discovered in Intel’s Management Engine, a remote-administration feature on its microprocessors. Like Spectre and Meltdown, they affected how the chips operate. Looking for vulnerabilities on computer chips is new. Now that researchers know this is a fruitful area to explore, security researchers, foreign intelligence agencies, and criminals will be on the hunt.

Second, because microprocessors are fundamental parts of computers, patching requires coordination between many companies. Even when manufacturers like Intel and AMD can write a patch for a vulnerability, computer makers and application vendors still have to customize and push the patch out to the users. This makes it much harder to keep vulnerabilities secret while patches are being written. Spectre and Meltdown were announced prematurely because details were leaking and rumors were swirling. Situations like this give malicious actors more opportunity to attack systems before they’re guarded.

Third, these vulnerabilities will affect computers’ functionality. In some cases, the patches for Spectre and Meltdown result in significant reductions in speed. The press initially reported 30%, but that only seems true for certain servers running in the cloud. For your personal computer or phone, the performance hit from the patch is minimal. But as more vulnerabilities are discovered in hardware, patches will affect performance in noticeable ways.

And then there are the unpatchable vulnerabilities. For decades, the computer industry has kept things secure by finding vulnerabilities in fielded products and quickly patching them. Now there are cases where that doesn’t work. Sometimes it’s because computers are in cheap products that don’t have a patch mechanism, like many of the DVRs and webcams that are vulnerable to the Mirai (and other) botnets — ­groups of Internet-connected devices sabotaged for coordinated digital attacks. Sometimes it’s because a computer chip’s functionality is so core to a computer’s design that patching it effectively means turning the computer off. This, too, is becoming more common.

Increasingly, everything is a computer: not just your laptop and phone, but your car, your appliances, your medical devices, and global infrastructure. These computers are and always will be vulnerable, but Spectre and Meltdown represent a new class of vulnerability. Unpatchable vulnerabilities in the deepest recesses of the world’s computer hardware is the new normal. It’s going to leave us all much more vulnerable in the future.

This essay previously appeared on TheAtlantic.com.

MagPi 66: Raspberry Pi media projects for your home

Post Syndicated from Rob Zwetsloot original https://www.raspberrypi.org/blog/magpi-66-media-pi/

Hey folks, Rob from The MagPi here! Issue 66 of The MagPi is out right now, with the ultimate guide to powering your home media with Raspberry Pi. We think the Pi is the perfect replacement or upgrade for many media devices, so in this issue we show you how to build a range of Raspberry Pi media projects.

MagPi 66

Yes, it does say Pac-Man robotics on the cover. They’re very cool.

The article covers file servers for sharing media across your network, music streaming boxes that connect to Spotify, a home theatre PC to make your TV-watching more relaxing, a futuristic Pi-powered moving photoframe, and even an Alexa voice assistant to control all these devices!

More to see

That’s not all though — The MagPi 66 also shows you how to build a Raspberry Pi cluster computer, how to control LEGO robots using the GPIO, and why your Raspberry Pi isn’t affected by Spectre and Meltdown.




In addition, you’ll also find our usual selection of product reviews and excellent project showcases.

Get The MagPi 66

Issue 66 is available today from WHSmith, Tesco, Sainsbury’s, and Asda. If you live in the US, head over to your local Barnes & Noble or Micro Center in the next few days. You can also get the new issue online from our store, or digitally via our Android and iOS apps. And don’t forget, there’s always the free PDF as well.

Subscribe for free goodies

Want to support the Raspberry Pi Foundation and the magazine, and get some cool free stuff? If you take out a twelve-month print subscription to The MagPi, you’ll get a Pi Zero W, Pi Zero case, and adapter cables absolutely free! This offer does not currently have an end date.

I hope you enjoy this issue! See you next month.

The post MagPi 66: Raspberry Pi media projects for your home appeared first on Raspberry Pi.

"Skyfall attack" was attention seeking

Post Syndicated from Robert Graham original http://blog.erratasec.com/2018/01/skyfall-attack-was-attention-seeking.html

After the Meltdown/Spectre attacks, somebody created a website promising related “Skyfall/Solace” attacks. They revealed today that it was a “hoax”.

It was a bad hoax. It wasn’t a clever troll, parody, or commentary. It was childish behavior seeking attention.
For all you hate naming of security vulnerabilities, Meltdown/Spectre was important enough to deserve a name. Sure, from an infosec perspective, it was minor, we just patch and move on. But from an operating-system and CPU design perspective, these things where huge.
Page table isolation to fix Meltdown is a fundamental redesign of the operating system. What you learned in college about how Solaris, Windows, Linux, and BSD were designed is now out-of-date. It’s on the same scale of change as address space randomization.
The same is true of Spectre. It changes what capabilities are given to JavaScript (buffers and high resolution timers). It dramatically increases the paranoia we have of running untrusted code from the Internet. We’ve been cleansing JavaScript of things like buffer-overflows and type confusion errors, now we have to cleanse it of branch prediction issues.

Moreover, not only do we need to change software, we need to change the CPU. No, we won’t get rid of branch-prediction and out-of-order execution, but there things that can easily be done to mitigate these attacks. We won’t be recalling the billions of CPUs already shipped, and it will take a year before fixed CPUs appear on the market, but it’s still an important change. That we fix security through such a massive hardware change is by itself worthy of “names”.

Yes, the “naming” of vulnerabilities is annoying. A bunch of vulns named by their creators have disappeared, and we’ve stopped talking about them. On the other hand, we still talk about Heartbleed and Shellshock, because they were damn important. A decade from now, we’ll still be talking about Meltdown/Spectre. Even if they hadn’t been named by their creators, we still would’ve come up with nicknames to talk about them, because CVE numbers are so inconvenient.
Thus, the hoax’s mocking of the naming is invalid. It was largely incoherent rambling from somebody who really doesn’t understand the importance of these vulns, who uses the hoax to promote themselves.

Kroah-Hartman: Meltdown and Spectre Linux Kernel Status – Update

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

Here’s a
brief update from Greg Kroah-Hartman
on the kernel’s handling of the
Meltdown and Spectre vulnerabilities. “This shows that my kernel is
properly mitigating the Meltdown problem by implementing PTI (Page Table
Isolation), and that my system is still vulnerable to the Spectre variant
1, but is trying really hard to resolve the variant 2, but is not quite
there (because I did not build my kernel with a compiler to properly
support the retpoline feature).