Oracle says SPARCv9 has Spectre CPU bug, patches coming soon Oracle has told users of its SPARC-powered platforms that they have the Spectre processor design flaw. A support document buried in Oracle’s customers-only portal, but seen by The Register, states: “Oracle believes that certain versions of Oracle Solaris on SPARCv9 are affected by the Spectre vulnerabilities.” The document, …
Yes, as we've repeatedly reported since January 2
True. However, "design flaw" is debatable, and Simon's "the Spectre processor design flaw" is worse.
Modern general-purpose computers are rife with side channels. Spectre is a class of vulnerabilities - not singular - that involve the interaction of speculative execution and side channels.
Inter-process side channels were always going to exist on any timesharing system, so the only candidate for "flaw" is speculative execution. Since spec-ex does exactly what it was intended to do, achieves its goal, and was clearly rewarded by the marketplace, it's hard to see how calling it a "flaw" is justified. An intruder can break one of windows of my house and gain entry - that doesn't mean windows are a design flaw.
The flaw is in imagining that modern general-purpose CPUs provided some magic, inviolable guarantee of trust boundaries. That's due to a fundamental misunderstanding of IT security, which is never about absolutes. It's about risks, probabilities, and work factors. The Spectre paper showed that the work factor for using unprivileged-software-accessible side channels to violate various trust boundaries was lower than commonly supposed.
Eliminating spec-ex would (by definition) prevent Spectre attacks, but not other side channel attacks. Increasing the work factor for particular side channels and attack vectors described in the Spectre literature (as we've seen with browser and OS vendors over the past couple of weeks) just means attackers have to switch to other side channels and attack vectors. These mitigations will always be partial, and they quickly approach a point of diminishing returns. Probably the only way to get cost factors higher after that is to reduce the number and degree of trust boundaries on a physical machine.
It certainly has a long track record and it's always been pretty good. I've watched with amusement as Linux has gradually reinvented things that Solaris has had for a long time.
I miss trade good old days when to do any serious work you needed a decent SPARC workstation with one of their high end monitors. PCs ended up out developing them alas.
Nowadays I worry that the same fate will befall PCs; no one is buying them, it's all smartphones and tablets. Well, not enough people are buying them. But the world needs people to have access to cheap desktop computers; whatever else is the engineering / content creation going to be done on? That market cannot be allowed to collapse.
"I miss trade good old days when to do any serious work you needed a decent SPARC workstation with one of their high end monitors"
That would be the good old days of all the EU projects (ESPRIT etc) where it seemed that every project budget included a new a SparcStation per team member .... I wonder if anyone ever worked out the benefits to Sun from EU research funding!
It occurred to me yesterday that the benefits of a bygone era in which the cost of the minimum equipment for business was far higher than today, actually existed in the effect of serious attention being paid to the quality and performance and service we received for our strenuously squirreled sovereigns. Of course I will inevitably find the occasional delight in the availability of some"incredibly good value" tech twiddler, but I am entirely unsure about the much wider effect. I used to be able to assume that if a interviewee had emailed me from his own told via a MTA on their own carrier independent subnet, we were quite likely to have a productive meeting. El Reg readership, in the McGee days almost guaranteed I'll enjoy the encounter.
Today.. Ahm.. less so. I have been driven to despair and randomly quizzing the candidate for the acronym definition of television features, on my phone screening.
As long as laptops and desktops provide a service, they'll continue to sold - and in enough volume to maintain reasonable prices, even if the premium buyers stick with phones and tablets/convertibles.
There has been some consolidation in the market, but part of it has been that there's no super-huge reason to get new devices. After all, they all run Windows 7, and if they do that, they can likely run 10, too. Well, now there may be a good reason for businesses to upgrade.
With 32 cores on the latest M7 5 Million, if you believe the number, doesn't look such a big number, each of the 2-3 largest public clouds has a lot more cores than that.
Don't misunderstand, I love Solaris and have a long history with it including many years @Sun.
I just hate what Oracle have done to it, and its once loyal userbase.
Meltdown is a really serious design flaw in x86 cpus. SPARC is immune to Meltdown. It doesnt matter if you run Java ontop SPARC or any other software - Meltdown cannot happen.
All cpus are vulnerable to Spectre, which is a much more difficult bug to use and not a big worry. However, Meltdown is a big worry.
The JRE, like other managed-language JITers and interpreters, has 1) gadgets that are useful for Spectre-class attacks (bounds-checked accesses and indirect branches, plus others not described in the Spectre paper), and 2) ample and interesting trust boundaries. Spectre-class attacks most definitely apply to the JRE.
But that just means the JRE is an obvious target. Nearly all non-trivial applications running on a superscalar processor with speculative execution are potential Spectre targets. And that means basically all modern general-purpose computers, except some1 smartphones.
As more native compilers come out with Spectre-mitigation features, I imagine Oracle will be rebuilding the Oracle JRE with at least the most prominent Spectre gadgets protected. And you can always build a Spectre-resistant (though never Spectre-proof) OpenJDK JRE yourself. LLVM, GCC, and MSVC all have Spectre mitigation options available, at least as preliminary patches, for some CPUs.
1Some ARM CPU designs have spec-ex; others don't. I believe Apple has announced that their ARM-based iPhone CPUs have spec-ex. I don't have a good sense for what the smartphone CPU market looks like, so I couldn't guess percentages. Older phones are unlikely to have speculatively-executing CPUs, so time to dust off that Symbian 6 Nokia? (Really, given the hilariously poor security of typical smartphone OSes, I can't see many people trying to mount Spectre-class attacks against them, other than for research and lulz.)
I still confuse reading this new,
There are no single strong and explicit paragraph that confirmed if SPARC platform need the Solaris OS tobe patched for Spectre.
Anyone can give me/us a confirmation on this matter?
please note that x86 platform is excluded from this question
"Oracle believes that certain versions of Oracle Solaris on SPARCv9 are affected by the Spectre vulnerabilities"
and
"Oracle is working on producing the patches for all affected versions that are under Premier Support or Extended Support."
Pretty clear to us. SPARC v9, running Solaris, is vulnerable to Spectre.
C.
"What part of Spectre being a hardware bug did you fail to understand? If a chip is vulnerable it doesn't matter what software you are running on it."
It appears to be theoretically possible to defeat those attacks with suitably crafted software, but that's a case of running new binaries - and likely some kind of hit in performance. The big.little boxes out there could run sensitive processes on an in-order processor - and the less sensitive workload on faster OOO cores.
All CPUs that perform speculative execution and have any sort of software-visible side channel (which would be all CPUs that perform spec-ex, except possible in quite unusual embedded applications) are vulnerable to the Spectre family of attacks.
If such a CPU is used to run workloads with trust boundaries - i.e. where any part of any program should not have access to any piece of data - then you have a Spectre vulnerability.
The beauty of side channel vulnerabilities like Spectre is that they do not need a failure of the permissions mechanism, so even a semi-capability architecture like IBM's i has Spectre vulnerabilities. All you need is speculative execution, a side channel, and a trust boundary.
"The batch of fixes also states that “Oracle OS and Oracle VM patches for CVE-2017-5715 will include updated Intel microcode,” which is a little odd as Oracle Linux and Oracle Virtualization have already received patches."
This only seems "a little odd" because you've conflated two different things.
The clue is in the names; the software in Oracle Linux & Oracle Virtualization is written by Oracle whereas the software in the Intel microcode is written by Intel.
Whilst Oracle can write patches/updates for their own packages they can't apply new microcode until Intel supply it.
Once Oracle, and all the other OS producers, receive Intel's new microcode they can create a package for it and then release it, as an update or patch, so that so that their OS's can apply it.
Is it really that difficult to understand?
To be fair, these attacks aren't very old, for people who don't make a habit of studying these things. And there's a great deal of noise about them. So I think we should make some allowance for confusion.
As I wrote in another post, the advantage of a side-channel attack (like the Spectre family) is that it doesn't directly violate any permissions boundaries. That's what a side channel is: an information leak that happens even when all the architected permissions are enforced correctly.
If SSM flushes the cache line on a trap, that would make inter-process Spectre a little more complicated. Flushing a line has timing effects too, though. I haven't thought about this rigorously, but I think a bounds-checked-access Spectre attack could make use of SSM by timing cache flush effects. And I don't know that SSM actually flushes the line - it might just trap and leave the line loaded, in which case it wouldn't affect most Spectre attacks at all.
Here, the fundamental issue is that CPUs have various features to make things go faster (because that's what buyers want), and those features can't be successful 100% of the time (because CPUs aren't magic). The discrepancy between faster and slower execution leaks information about the CPU's internal state.
If you want immunity from timing side-channel attacks, you need a CPU that either doesn't try to make things go faster (basically, a deterministic constant time for any given operation), or one that's magic. Or you only allow any given CPU to run "friendly" code - workloads completely under your control, or where there's no sensitive information, or where there's little reward for leaking it.
More realistically, you introduce various mitigations until you believe Spectre-class attacks are more expensive than other holes in your system, driving attackers toward those. Then you have a different problem to deal with. This is what we call "job security".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
