Slashdot Mirror
Linus Torvalds Says Intel Needs To Admit It Has Issues With CPUs (itwire.com)
troublemaker_23 shares an article from ITWire:
Linux creator Linus Torvalds has had some harsh words for Intel in the course of a discussion about patches for two bugs that were found to affect most of the company's processors... Torvalds was clearly unimpressed by Intel's bid to play down the crisis through its media statements, saying: "I think somebody inside of Intel needs to really take a long hard look at their CPUs, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed... Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?" he asked. "Because if that's the case, maybe we should start looking towards the ARM64 people more."
Elsewhere Linus told ZDNet that "there's no one number" for the performance drop users will experience after patches. "It will depend on your hardware and on your load. I think 5 percent for a load with a noticeable kernel component (e.g. a database) is roughly in the right ballpark. But if you do micro-benchmarks that really try to stress it, you might see double-digit performance degradation. A number of loads will spend almost all their time in user space, and not see much of an impact at all."
Elsewhere Linus told ZDNet that "there's no one number" for the performance drop users will experience after patches. "It will depend on your hardware and on your load. I think 5 percent for a load with a noticeable kernel component (e.g. a database) is roughly in the right ballpark. But if you do micro-benchmarks that really try to stress it, you might see double-digit performance degradation. A number of loads will spend almost all their time in user space, and not see much of an impact at all."
Won't boot with a Xen hypervisor (eg. Amazon AWS)
The real "Libtards" are the Libertarians!
I think it time for Zhaoxin CPUs. Monopolies are not good thing.
Except the out of order Cortex processors are affected by the same bug. Only the low power in order cores aren't.
I'd really like to see more CPU architectures supported for common operating systems. Linux can run under other architectures, but its not like I can go get it easily running under a PowerPC/ARM/whatever chip with the latest Nvidia graphics particularly easily.
At any rate, if our hardware isn't all the same then we mitigate from future problems like this.
Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?" he asked. "Because if that's the case, maybe we should start looking towards the ARM64 people more."
Not sure how much Intel really cares about threats from the free Linux community - vs Microsoft, etc... To quote Rick Sanchez, "What -- What's this supposed to accomplish? We have infinite grand-kids. You're trying to use Disney bucks at a Caesar's Palace here."
It must have been something you assimilated. . . .
MLGA, Linus, MLGA!
...then clearly the problem was in the kernel - Intel
Wrong, he works for the Linux Foundation, and has since IIRC 2013.
The kernel memory read issue was 90% a design decision to improve performance. I would argue that it should actually be an option in the BIOS. The fact the AMD didn't do this with zen to match Intel is what is really interesting. Intel did a little cheat to improve performance but AMD didn't and chose caution.
To me it's not a clear cut case if you brought a class action into court. The engineers cheated a bit but didn't think it would turn into such a security hole. I can just imagine the closing arguments... point is computers are complicated and not necessarily a guaranteed thing except that they can compute.
I don't think he craves attention; I think he's just a guy who speaks his mind, sometimes a little bit too much. With that said, I don't see why we need to publish so many of his brain dumps; there are many people with a way more valuable opinion on the subject, from a technical, legal or business perspective.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Whoa -- back it up, Sparky.
Are you suggesting that one of the FOSS Gods is yet again spouting off/talking out of his ass/engaging in verbal masturbation and not accomplishing anything of value? That's heresy!
Learn to read, you stupid cunt.
So you decide to speculate a future instruction.
It happens to be a load.
The address is [ebp+eax]. A recent instruction had the same address field, so you speculate that it remained the same.
Now you need to translate the address. The translate might be in the TLB, but you check, and for some reason it isn't.
So you decide to speculatively trigger TLB load.
Finally, you get a physical address back. A previous write instruction is not yet translated, but it seems unlikely it will translate to the same address, so you decide to speculate the load and you make a cache line request from L1.
It might be in L1, but it isn't. So you decide to speculate again, and request it from L2. Not in L3, either, so finally you speculate the load all the way to external memory. When the cache line returns, you speculatively cache this at all levels. Then you speculatively store the value into the target register. The final step was the least dangerous, because you can dump this later, no harm to the abstract state. But the concrete side effects on the TLB and the three layers of cache are not so easily reversed. In theory, the concrete state doesn't leak into the abstract state. Because we simply don't like to think about time (time, above all things, being never simple; hint: functional programming has no time, only progress).
Not all speculative architectures are created equal. There are many opportunities for an architecture to Just Say No.
With cache coherence, you have the MESI protocol (and its bewildering shoe full of second cousins).
One could apply the same concept of "exclusive" to the page tables, an exclusively mapped page being one mapped only onto into the current process and security context. If TLB speculation hits a different kind of beast, abandon speculation. Same thing with cache fill. Concrete side effects thereby only accrue from speculation to exclusive resources. Share-nothing usually solves most problems in computer science (except performance, which is mainly defined in the time domain).
I'm gong to abandon the back of my envelope here, One has to think really damn hard to take this to the next logical level, and frankly, I don't have a damn to spare right this very minute.
But please, advance the conversation beyond:
[_] has speculation
[_] does not have speculation
Because that is Intel's diabolical trap, for as long as their PR department can continue to get away with tugging their wool in broad daylight.
How exactly does he think Intel can fix this issue short of recalling every CPU made for the past 10 years?
To me it sounds like he's saying if Intel don't acknowledge the bug they won't fix it in future designs which is false as it will be scrutinized by many people across the tech industry.
ARM (and AMD) may be susceptible to the lesser of the two [evil] exploits... but the impact for that second one is considerably less than Meltdown (which is specific to Intel only). ARM has been very open and detailed with regards to the impact -- and gives every indication it is taking the issue seriously.
... 250,000 all at one time.... is also optically bad. I understand the need to diversify your investments, but he should only be selling at most 25% of his shares on an annual basis.
Intel on the other hand issued a totally bizarre PR spin. Trying to spin it as works as designed (which might be the case, but the design was flawed), trying to distract the public by using 'Look over there...' deflection technique. Then indicating that the earliest architectural change will be later this year (which by the way coincides with the beginning of the next generation release). Processors for one generation of chips tends to be phased in over a two year period - does this mean that they plan to continue selling defective CPUs for the next 2 and a half years?
On top of that the news that the [probably legal] sale share (after the news of the defect, but before it was made public) -- is at least optically horrible. An ethical CEO would have delayed the planned share sale until after the defect was public - and accepted the risk of holding onto the shares during that time. Not to mention selling 889,700 shares and keeping only the absolute minimum to remain CEO
This all put together indicates to me that the current CEO should be fired.
How's that Transmeta business going?
Most CPU defects can be patched. This one cannot.
The lack of acceptance of responsibility, the attempt to deflect responsibility; the lack of transparency on when/how the defect will be fixed. That is why Linus was right to tear a strip off of Intel.
shut up, troll. take your flaming elsewhere.
I agree Intel's spin is ridiculous, including trying to claim AMD's CPUs are just as vulnerable. But in typical, Linus hissy-fit fashion he pivots to tangential claims, like how Intel will "sell shit forever" and "never fix anything".
well, the right thing for intel to do IS to recall all CPUs for users that request it. also to NOT downplay the huuuge security issue that they have caused, in their race for corner-cutting. maybe to publish some test results for the patches, maybe open some specs that might help the devs in better patching this issue in software, maybe even dump some cash for the devs. These are just from the top of my head, but you get the picture. The whole fiasco was very badly handled by Intel.
BS. There are already proof of concepts that can be run and are in the hands of a select few for testing purposes. We have no idea if these exploits have been used - only that we have no visibility on it. The only real visibility we have is when a whitehat reports it, or when someone is caught. While personal computers are less impacted, the fact that the browsers will all also have to be patched since it can also be exploited through javascript... problematic.
The issue is that through using the exploits you can have access to things like passwords used in kernel code, certificates, etc. -- and that can get this through pilfering the cache -- which breaks the isolation between user applications and the operating system.... While already bad on a personal computer, it is horribly bad for shared hosting environments -- where some actor can get access to a common computing environment and attack from the inside.
And to be quite honest, that was not how I read Linus thing... Linus can be a wrap the contents of a valid issue in a bit of what some have termed a 'Hissy fit'/'tantrum'. The issue that he seems to have is not that there is a defect, not that it has to be patched in the kernel -- but that Intel's PR is on overdrive and gives no indication of taking responsibility... and not being open and transparent with regards to fixing it and timeline for those actions.
It is not the design / defect that I have lost respect for Intel, nor the technical competence of it's employees... My issue resides with the C-level's response to this defect that I have tot take issue with - and that is how I really read the email. ARM is not defect free, but the difference is that their response to it has been much more professional and transparent.
Being a software developer by trade, I am all to familiar that nothing is defect free... and defects are a part of the process.... the response and how these defects are handled is where you win or lose respect (assuming you are not totally incompetent and the software is not unusable).
I pretty much get Linus hates Intel, but almost every article on the Meltdown/Spectre problem talks about at least some of this affecting AMD, and some ARM CPU's as well. I know its easy to pick on Intel and probably many of the CPU engineering of others came from what Intel did. But the basics of physics has caused the chip makers to do things to continue to advance speeds with out actually being able to physically advance core speeds. To me Torvalds rants do not really contribute to anything. He's not in any real position to do much about the future of CPU's other then rant. As a whole much of these CPU's function very similar for a reason. Its because it has been the best way found to advance speed. Torvald is welcome to offer up any options to do this.
The exploit is basically gathering information that could be used to completely invalidate security. Therefore by the time you know you have been compromised the vector that made the that possible would no longer need to be present.
Basically, by the time the world would have visibility - it would already be far too late (and it may be the case). We see the results, but not the attack vector... The odds of a whitehat finding any exploit first -- is probably much less than 50%.
It's too bad Asshole Torvalds isn't still employed by CPU maker Transmeta, so Linus can't tell his loyal following of Linux idiots to boycott Intel crap and buy Transmeta perfection instead. Transmeta CPUs were the bestest ever and that's why Transmeta went out of business, right.
The idea behind the Transmeta architecture may not have panned out, but I'm guessing that it had one redeeming feature compared to the current CPUs on the market: If their CPUs did have this problem, they probably could have fixed them with a firmware update.
You sound salty and mighty envious.
To quote the famous APK..."what have you done ne'er-do-well?
Sidechannel attack research has been big for over a decade, the "white hat" exploit factories are big business ... it's unlikely this wasn't being exploited in the wild.
Never mind dead grandma in the basement, we all have mental health problems.
I like it here. Thanks for offering to suck my rancid anus.
> But in typical, Linus hissy-fit fashion he pivots to tangential claims, like how Intel will "sell shit forever" and "never fix anything".
Dude, you and I are seeing this NOW.
But some folks have been aware of that fact since some time, and no solution came up -- because this one is hard... hardware. The bubble just popped because Google decided enough is enough (not to mention this affects their business directly).
And what about the designers? What were they thinking? Don't they know about space separation? My guess is that is became hard to adhere to Moore's law curve and they had to cut some corners.
Linus is referring to the fact that such problems have not been not addressed nor fixed since years ago. He has worked with processors, he knows what he's saying -- he's not just a software guy.
I'd never use such colorful language as his, but this time it is totally justified -- not just because it's a serious problem, but because it seems Intel is totally blasé about it.
Meltdown and spectre are both user space attacks.
Side effects in caches are practically impossible to avoid if instructions are executed speculatively. With Spectre, a process only gets access to memory that it could already access. The promise that is broken is entirely in software: JITs "guarantee" that some memory won't be accessed, even though it is not protected by the CPU. JITs need to take into account that in-order execution is an abstraction, not reality.
The thing that absolutely has to be fixed is Meltdown, speculatively accessing memory that could not be accessed in-order. It's a violation of memory protection, which is a fundamental guarantee of modern CPUs.
He has found/created a small pond
The world's most widely-used operating system kernel is hardly a "small pond".
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I got to thinking about Google's clever Retpoline from the other day.
Google Says CPU Patches Cause 'Negligible Impact On Performance' With New 'Retpoline' Technique
The problem is, this is not invariant under peephole optimization. These instruction sequences need to be handled by the compiler through a very literal minded end-game code generation pass.
Which got me to thinking about RETGUARD gadgets.
RETGUARD, the OpenBSD next level in exploit mitigation, is about to debut
Retguard: OpenBSD/Clang
I know, both of those sites are horrible, but Google fails me here.
Are speculative gadgets a problem here? If so, Google's clever patch is going to need a sump pump bolted on the side.
And then you get into the whole problem of deterministic compilation in order to be certain that the executable you build contains the necessary mitigations (or some tricky post-compile analysis I sure don't wish to develop myself).
What a giant mess.
Thanks for stepping ahead and talking as an Intel professional, that requires guts, I'll give you that. It's easy to be proud when winning, but defending the fortress in bad times, that's being a good fellow. Again, props to you.
That said, this sh*t has been on the radar of some people for quite some time. And I bet management did nothing because that would mean a hiccup in profits. At the VERY least, offer a line of in-order processors to be used in security-minded areas -- and make it clear that super fast CPUs are nice for games, but can't be used for e.g. Internet banking.
This is more than design being complex or humans committing errors. It's about what you can do when you find a defect which cannot be fixed. Maybe Intel is not as big as we thought, because ignoring the problem is small company behavior.
I don't mean I expect better from AMD, ARM or others. Maybe this is natural for any company working with highly capital-intensive businesses.
Maybe this will require a totally new attitude about online banking and purchasing... maybe we'll need independent card readers at home (just like the ones used in stores). That's extreme, but I feel we cannot trust the computers (desktops, notebooks, tablets, smart phones) to prevent access to our passwords, credit card numbers, smart card PINs etc.
Too bad.
Yeah because democrats were never russian apologists during the cold war....
The problem is, your CPU takes too long to decide whether a memory load is legal or not. Currently, with meltdown, it decides that after the load has happened and additional instructions have been run. That's way too late. An illegal memory access just must not happen in the first place. You try to access memory you are not allowed to access, you get slapped down immediately and not a few instructions later. Otherwise you will have to implement a rollback strategy for all cache levels as well. I doubt you really want to do that.
Yes, I can see the obvious reply already... "But... performance will suffer if we do that!". Doesn't matter, if the next CPU generation doesn't stop meltdown cold, it won't sell.
Theo has essentially said something similar.
While ARM CPUs are relatively ubiquitous in smartphones and tablets, those devices aren't nearly as high-value of a target as servers, where Intel CPUs dominate (well over 90% of the market).
Linus is in a unique position - he is an engineer, almost 100% focused on technical solutions, yet he is also a public facing figure and is able to make public comments. He also (to the best of my knowledge) doesn't have to worry about customers, profits, shareholders, etc., things that a for-profit, publicly-traded company does. Most of the time, the engineers aren't the ones making public comments. I haven't heard from any Intel engineers yet, only their PR department, but I would guess the Intel engineers are just as interested in fixing this as he is, but we aren't hearing about it.
FPGA, Linus, FPGA!
#DeleteFacebook
Why bother with idiots like that? It's not even like Transmeta was Linus' company, he just worked there.
They probably do think that. But I'm hoping that AMD will seize upon the opportunity to post real world comparative figures, with the newly patched kernels. Presumably, for certainly workloads, AMD silicon will utterly spank Intel for performance.
Speaking of distros, when will this be getting backported to older LTS kernels like in the 4.4 branch? I'm running Ubuntu 14.04 and haven't seen a kernel update yet.
As for the situation you described, users had better hope they kept some an old kernel around to boot from. I know that Ubuntu has looked into ideas to remote the old kernels that don't get removed during updates, but it's good to keep something around that's certain to boot properly. If so, the only real harm is an extra reboot and not having a patch for Meltdown yet.
The odds of a whitehat finding any exploit first -- is probably much less than 50%.
What is your rationale for this claim?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Title Fixed
and republicans have a hard time not living in the past
make merucia gureat again
CentOS's kernel-plus 7.4 boots fine under Xen 4.9 running with Fedora 27, all with the latest patches.
RHAT doesn't give a damn about Xen. Maybe they didn't break it intentionally on 7.4 but they didn't test it either. 'Cause nobody like Amazon uses Xen, right?
But buy their KVM product, it's much less prone to [their] breakage. Hah. Debian isn't hostile to Xen, nor is Arch.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Ask anyone involved - even whitehats - and you are likely to be told that the demand and renumeration for exploits on the open market is higher than it is for submitting it and expecting a bounty. You have state sponsors (some that are closer to mafia states) such as North Korea and Russia financing the finding of exploits. Your own government is also accumulating exploits - but the only time you see them used is when they are leaked - they are not typically submitted to companies - since they want to use them. You have major multinational criminal organizations that make significant amounts of their income through high tech attacks -- which can net billions in a single attack - making the cost of acquiring exploits a rounding error. You have thriving dark web marketplaces for selling these exploits. This industry dwarfs the whitehat industry considerably. Basically, there is more investment on monetizing exploits than there is discovering these exploits for ethical purposes.
next to his Nick :) Already too late for you, obv.
I had already considered this a number of years ago. You know how I am prepared to mitigate it?
By owning hardware and software old enough to probably have avoided these attacks, and having enough knowledge of the build chains that, so long as the source code is not also backdoored, I can build everything from scratch on 80s-90s era hardware, going from old versions of gcc to modern versions of gcc/clang/etc. All of the backup data necessary being saved on single write optical disk media kept in a dark temperate place. Having verified these disks in the past couple years, 20 years on most of them have either no, or negligable data loss, and any with concerns have been ripped and burned as isos onto newer media. So long as they don't have a single uniform backdoor in all sdcards, or hard disk drives capable of providing backdoors on both older intel hardware, as well as older unixes simultaneously, I can regenerate whatever toolchains are needed up to the modern era, so long as they can be compiled directly, or indirectly from a C compiler.
The only ones I know of that can't ATM, are Rust, Ada, and Haskell, none of which appear to have an open source compiler available in a language compilable from gcc. While you need an old version, GPC+3.x era GCC can bootstrap older versions of FPC, allowing you an authenticated C chain up to modern Pascal versions, as can gdc I believe. Rust can in theory be bootstrapped from the original ocaml implementation up to current, but build instructions for every step of the process may or may not still exist, and it has some signing stuff built in that may cause your compiler to register as 'inauthentic'. Ada/GNAT AFACT hasn't had a non-Ada open-source bootstrap compiler since the very early 90s at latest, meaning there is no easy path to build a trustworthy Ada compiler from source without trusting that GNAT isn't backdoored. Haskell I have looked into the least, but I could not find an alternative language bootstrap compiler to start it in, and even there it was limited on what arches it supported.
I am not aware of Linus hating Intel, he definitely hates the way Intel has tried to BS / Spin / deflect blame / avoid responsibility. If you appreciate companies that spend more time on BS / Spin / deflecting blame and avoiding responsibility rather than being transparent about their own failures and how THEY plan to address it... then Intel is the company for you (under this CEO anyways - we will see if he lasts).
ARM has been transparent, detailed and transparent about their failings (the lesser of the defects) and deserves respect for that.
I think that the bad kernel package has been withdrawn.
The real "Libtards" are the Libertarians!
https://en.wikipedia.org/wiki/...
Uh, Linux geek since 1999.
oops, transparent was duplicated
How about some clawback from the previous CEO(s) who profited while this design decision was being made?
The Linux kernel development is transparent - you can go see every issue that is logged and needs to be fixed. next.
His quote: "Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?"
I think the record until now clearly shows that Intel's CPU products have actually been generally pretty good and that they actually do release fixes for their fuckups.
Let's put this into perspective: its a security hole not a major functional failure. People are having to get amazingly creative in finding new ways to break into anything. Basically anything even slightly complex has potential exploit risks, including Arm64 CPUs.
Linus needs to get real and give Intel a chance to do their thing.
Intel chip designer that can't even use capital letters properly? Checks out.
Good luck with all that propaganda, hope you manage to keep it all down.
Hes just throwing shit around in the hopes they get some in their face. I would do the same in his position, the only way to deal with evil untouchable entities like this is to humiliate them in public.
Meanwhile, enjoying my Ryzen, largely unaffected by Meltdown or Spectre in spite of some well meaning or self-serving FUD to the the contrary. Yes, I got an early part with the segfault bug, but AMD RMAed without fuss when presented with appropriate https://github.com/suaefar/ryz...>test data to eliminate the possibility of bad motherboard, memory or overclocking. Quite different attitude compared to Intel! And the Ryzen is sweet - 16 high performing CPU threads, tiny power consumption at idle and respectable under full load. Integer performance, iow, compiling is stellar and floating point is not shabby. Basically, Ryzen out-cores Intel's competing i7 parts by a wide margin, acquits itself well in single-core too and draws so little power that the CPU fan is off or barely turning for most normal desktop usage. And when all 16 threads are going full blast, iow doing real work, total system power is around 120 watts, the system still runs nearly silent. Can't say enough good things about it.
If you do step up to Ryzen, be aware of two things: 1) Check the production week stamped on the CPU, it has the form 17xx where xx is the week... make sure this is higher than week 25, otherwise run kill-ryzen.sh to verify the segfault bug and get an RMA promptly from AMD's only support site, if you see it. Windows users need to boot Linux to do this, get a live iso on a usb stick to do this in maximum comfort, and preferably, just overwrite Windows when done :-) Most of that early production is sold out already, so the chance of getting a bad part is slim, but be aware. Windows users for the most part don't seem to see any issue even with the early parts. Good for them, but it goes along with significantly lower performance without the upgrade to LInux :-) 2) Be aware that Ryzen has no on-board GPU, in spite of the fact that your Ryzen motherboard has video connectors... these are for AMD's APUs, which use the same socket. Respectable chips in their own right especially in terms of value for money, but when you run Ryzen you need to run a discrete GPU too. This is what you want anyway, because what is the point of crippling your high end desktop processor with a mickey mouse embedded GPU? To be specific: AMD's fattest APU has eight compute units (512 stream processors) vs 64 in the current Vega part, plus uses processor memory instead of higher bandwidth dedicated graphics memory.
Of course, what I really want is a threadripper... that's next.
When all you have is a hammer, every problem starts to look like a thumb.
How could a recall even be possible at this time? To me a recall implies that it is possible to repair the fault, which is clearly not possible now and for some time to come. As for the other things that you mention, they take time. Nothing happens instantaneously.
Redhat's support is very selective these days. There is a clear imperative to more quickly support products that they can wrap a support contract around like RHEL. I understand that since they've got Wall Street to please, salaries to pay, etc., but it would not be a lot of extra effort to also support the free products in their ecosystem at a similar cadence. As a result, I have been weaning applications off Redhat products. The availability of support is great, but the vast majority of my applications don't require it so I've been leaning more towards the Debian ecosystem where my particular nits have been more quickly addressed and I don't feel like I'm going to be held hostage to ponying up for a support subscription to get a critical bug fix in a timely manner.
And, to be honest, the larger world has no idea who the guy is nor to they pay any attention to what he has to say no matter how much attention he seeks. He has found/created a small pond, and careens around like a shark in a goldfish bowl. That's not particularly bad or at all unique, but certainly no one at Intel gives a crap what he thinks, and to expect any different shows a lack of perspective.
Guess what? Nobody give a shit what you think either. As the software he writes and manages runs most of the devices on the planet and is the world's most widely used OS, some of us actually care what he thinks. You, not so much...
"Those that start by burning books, will end by burning men."
I'm no fan of Trump, but let's remember that Mueller's investigation is still ongoing.
Even the publicly know facts are damning, just one example: the Trump tower meeting with Russians, including denials already admitted as false, and multiple attempted cover ups. It's hard to imagine any objective observer not already having enough evidence at hand to know that America is currently under the control of a criminal gang of thugs.
When all you have is a hammer, every problem starts to look like a thumb.
Your mom loves to suck MY rancid anus. That is, when your dad isn't pushing her out of the way to take his turn at it.
This is not about Republicans versus Democrats, it is now about saving democracy.
When all you have is a hammer, every problem starts to look like a thumb.
The problem is that Linus doesn't quite have the maverick cachet that Gates, Jobs, or Musk do. Torvalds has equal or better technical chops but he divorced himself from "the rat race" for lack of a better term. Jobs was the rock star, filling stadiums with screaming fans. Torvalds is the street performer who plays a little better but didn't care enough about gratuitous adulation or "being #1" to make it to the stadium.
...Most of them anyway. I guess there's a few swayed by MS or Apple salesmen.
Some people see this and call him irrelevant. They feel that he shouldn't be allowed an opinion, or that it should be worth less, because he's not on the Forbes list. Thankfully, they take a more objective, impersonal assessment when it comes time to choose which OS to run on their servers.
what about the designers? What were they thinking? Don't they know about space separation?
You seem less than clear on the details. There is nothing wrong with Intel's privilege separation, however nobody anticipated that timing attacks could be so effective, even the researchers. It came down to luck more than anything: AMD, by luck more than anything, implemented algorithms that avoid the worst of it, but bad luck for Intel. Hard to fault the Intel engineers, but one can certainly fault the managers for a less than forthcoming response.
When all you have is a hammer, every problem starts to look like a thumb.
They probably do think that.
No they don't, they have plenty of competent kernel engineers on staff. Some PHB thinks that.
When all you have is a hammer, every problem starts to look like a thumb.
they still won't admit any fault...
even after they get sued into bankruptcy by whatever governments or megacorps take the brunt of it.
something.. something.. disclaimers about not using for mission critical functions.. etc.. etc..
Intel has said they are working together with oem partners blah blah but i have yet to see their microcode patches posted on their website. I build my own machine, i can't contact Lenovo (who haven't even acknowledged most of their products are vulnerable)
Open Source Java Web Forum with LDAP authentication
These are not bugs. These are features baked in the CPUs.
What, Linus isn't calling Intel out on including this exploit at the hardware level?
Poor boy, has gone soft in the head.
Oh, it was an accident you say?
Well then, nothing to see here, back to being well entertained.
In this case the CPU cannot be patched. This defect is permanent, it can never be fixed in the current processors. When new processors come out (assuming the next gen uses the same socket -- a crap shoot) you could replace the CPU. The fix is for the OSes to basically compensate and work around the defects - which may have moderate to severe performance penalties depending on CPU and what you are doing. What Intel is saying is actually a lie, they are helping the OS or "bios" vendors basically duct tape over the defect and hide it. Intel has indicated the earliest you will see "patched" CPUs is the end of the year - which depending on the CPU - could be end of the year or end of the follow year if they follow any type of release cycle (likely to be next gen CPUs only). So updating your motherboard to the latest firmware and installing the latest version of the OS is all that you can do for now.
He's an attention whore and frequently wrong.
YMCA Linus, YMCA
>you heard me. he may be a great programmer, but he doesn't know DICK about how hard it is to make a CPU
Did you forget that Linus worked at Transmeta?
Arm A15, A57, A72 and A75 are all impacted by this as well.
It seems you're not clear on the details, actually.
Literally any logical person can see that Intel's suck-it-and-see approach is terrible. AMD's (and everyone else's) engineers specifically addressed the issue by using the correct logic. That's not luck. That's called doing it right.
Logical order of operations:
1) Begin speculative execution
2) Encounter ring-0 request
3) Check for ring-0 permission
4) Only allow speculative operation to be processed if permission is allowed
Literally everyone but Intel does it this way because they're smarter than Intel.
Intel's janky-ass order of operations:
1) Begin speculative execution
2) Encounter ring-0 request
3) Allow request to be processed, no matter what
4) When resolving branching, check if requester has ring-0 access and invalidate the results if not
The trouble comes with: 3.5) Unprivileged requester inspects artifacts (registers, cache values, etc.) of processing prior to speculative branch resolution.
The blame for this lays at the feet of Intel's engineers as much as anyone else. Granted, it's possible they found this a while ago and wanted to fix it, but were thwarted by management. Everybody knows that management sucks in every company, and they probably were the most recent roadblock to progress here. But this design got to production in the first place, and that's the engineers' fault.
1 If the patch is in software, in the OS, can't malicious code (e.g. after privilege escalation exploit) undo any OS patch and then go wild on other people's memory?
2 Does this also bypass Intel SGX isolation?
I'm no fan of Trump, but let's remember that Mueller's investigation is still ongoing.
Even the publicly know facts are damning, just one example: the Trump tower meeting with Russians, including denials already admitted as false, and multiple attempted cover ups. It's hard to imagine any objective observer not already having enough evidence at hand to know that America is currently under the control of a criminal gang of thugs.
And another publicly known fact is that there are a bunch Russians slimeballs with skin in the game, going so low as to troll-mod community sites like Slashdot. Understand this Ivan: you just provide more evidence every time you do it.
When all you have is a hammer, every problem starts to look like a thumb.
The air in your room is constantly computing, the electrons in all matter
on earth are constantly computing.
The point with processors like Intel's is that it is easier to control
the computation with standard, widely available methods (software). This bug inhibits this control. Which was their only point to begin with, as compared to "computation" devices like air.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
The point is Intel CPUs are designed for two things, Speed or efficiency. Security has never been their selling point. If they traded for a huge security issue, and it's impossible their engineers and testers didn't know this was a possible bug... what else have they done for speed?
If it's so obvious then why did it take nearly two decades for anyone to notice?
I like this comment "Don't these kernel updates get any testing? I realize that CentOS may have very limited resources for testing, but doesn't Red Hat test these updates?".
What? Maybe it compiled just fine!
Slashdot, fix the reply notifications... You won't get away with it...
Since this news broke, I've been sitting on one question that bothers me, and I can't figure out the answer:
How much would this kind of global, hard-to-find, not-so-hard-to-exploit-once-you-know-what-to-look-for issue been worth to an interested party in 1995?
Assorted stuff I do sometimes: Lemuria.org
So if I am big bad hacker, how do I use this vulnerability? Through a tedious process (carefully arranging for page faults and cache misses in speculatively executed code), I can determine bit by bit the value of other processes memory (which the OS and hardware should not allow); but I don't get a snap shot of the complete state of memory. Instead I get a peak at the value of the memory I should not have access to, word by word, memory which is changing as I am looking at it. How useful is this? Just figuring out what other process is running on the machine with you is tough, but can be done using this process. Of course by then, the other process has exited or been moved. Maybe worth doing if you know there is a program running with very sensitive data on the machine you are using; but why are they letting you on their machine in the first place? To prevent this difficult-to-use security leak, we can and should take the performance hit and disable this optimization on shared machines (such as in the cloud) where strangers programs are running on the same machine. But for privately owned machine running time-critical code, I would expect we'd recognize there is no risk here and continue using the fastest machines, with this security-risking vulnerability in place, along with its speed boost. I can imagine the cloud users would demand that the vendors supply them machines where the cpu is not shared with un-trusted players; and in the meantime Intel will come out with new chips that close this vulnerability; and before that Linux and Microsoft and Apple et al will deploy patches that mitigate the problem.
ARM (and AMD) may be susceptible to the lesser of the two [evil] exploits... but the impact for that second one is considerably less than Meltdown (which is specific to Intel only).
That's incorrect. Per Apple's statement, all of Apple's ARM designs except the watch are vulnerable to meltdown. Also, the Cortex-A75 is vulnerable to meltdown. I agree that the initial PR spin from Intel was pretty ridiculous, but the good news is it looks like some engineers at Intel released a actual technical response. Reading through the whitepaper, it looks like Intel has figured out how to patch both meltdown and spectre on existing chips using a combination of microcode updates and OS updates.
Not really. Everyone is allowed their opinion. And if he speaks out about OS design, coding standards, or even processor architecture, I’d listen, since he knows a fair bit about those subjects. If he voices an opinion on how to manage a FOSS community, I’d still listen even though I don’t agree with his management style, because he ostensibly has experience on that front either. But if he tells others how to run their business or how to handle PR or legal matters, then yeah, he is largely irrelevant. Because he didn’t join the rat race, and those things lie outside his area of expertise.
His opinions on those matters might still be interesting and insightful, but they don’t really have any more weight than those of the rest of us.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Excellent capsule summary of the issue, by the way. But you still can't blame the engineers... at the time, this kind of timing attack was not a thing. Nobody had a crystal ball, nobody saw it. Maybe you did, and you just forgot to send the memo.
When all you have is a hammer, every problem starts to look like a thumb.
I think that Meltdown is more architectural and OS problem than just Intel's flaw. CPUs have always been designed to be as fast as possible. If you want fast - you might have to sacrifice the security. If you need secirity - do things right and slow.
How could a recall even be possible at this time? To me a recall implies that it is possible to repair the fault, which is clearly not possible now and for some time to come. As for the other things that you mention, they take time. Nothing happens instantaneously.
Yes, and if they recall the cpus, what will you do with the motherboard and the other periphery?
Not 'anyone', but 'someone/org' probably noticed, this is Intel we're talking about ;)
I guess they will have to add journaling to the CPU cache levels.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Linus created an operating system, while Trump got caught committing treason colluding with a foreign hostile adversary's attack on our democracy.
I don't see the comparison.
Trump is going to prison.
Linus is a good person.
Nearly right!
Linus created an operating system
Linus wrote a kernel. Most of the rest of Linux distributions comes from elsewhere, hence the preferred title GNU/Linux.
while Trump got caught committing treason
No he didn't. If you think otherwise, please give details of what exactly he did and why it is legally treasonous.
treason
n noun
1 (also high treason) the crime of betraying one's country, especially by attempting to kill or overthrow the sovereign or government.
2 (petty treason) historical the crime of murdering a master or husband.
colluding with a foreign hostile adversary's attack on our democracy.
collude
n verb come to a secret agreement in order to deceive others; conspire.
Governments (like corporations) always collude; in terms of foreign policy, they do little else. But what is this "foreign hostile adversary"? (a multiply redundant expression, by the way). Russia is in no way hostile to the USA, and the only way in which it is an adversary is that it competes in trade - which is what capitalism enjoins - and sometimes declines to do what the US government orders it to do.
Needless to say, there was no "attack on our democracy". First because there was obviously no "attack", and second because there is obviously no "democracy".
https://www.thenation.com/arti...
https://consortiumnews.com/201...
https://www.youtube.com/watch?...
https://www.strategic-culture....
https://scholar.princeton.edu/...
yournewswire.com/jimmy-carter-the-u-s-is-completely-subverted-by-oligarchs/
Trump is going to prison.
No, he isn't.
I am sure that there are many other solipsists out there.
It's hard to imagine any objective observer not already having enough evidence at hand to know that America is currently under the control of a criminal gang of thugs.
Now that is certainly true; as it has been true every year since the 1950s, and probably long before.
I am sure that there are many other solipsists out there.
And another publicly known fact is that there are a bunch Russians slimeballs with skin in the game, going so low as to troll-mod community sites like Slashdot. Understand this Ivan: you just provide more evidence every time you do it.
Can you cite the slightest piece of concrete evidence for this lurid fantasy?
I am sure that there are many other solipsists out there.
This is not about Republicans versus Democrats, it is now about saving democracy.
How can you save what you never had, and never wanted? The Founding Fathers (with the noble but doomed exception of Jefferson) were dead set against democracy, and deliberately created a republic instead. They took great pains to keep power away from the mass of the people.
I am sure that there are many other solipsists out there.
Not this again. The US government IS a democracy, a democratic republic.
It's not a DIRECT democracy, but in its broad sense, democracy just means "rule by the people" and that is what we have.
Your pedantry doesn't make you seem erudite, just anal.
The deal with Centos has always been that it gets the same support that RHEL gets, but later.
It is a pretty good deal, actually. They don't hold fixes back, but don't expect their engineers to be doing overtime and getting called in on the weekend to massage a free patch. That's exactly what support subscriptions are for!
Centos will get all the fixes, and they will work well. History teaches this clearly.
LOL why shouldn't Intel act like this so long people keep buying their shit?
"the current CEO should be fired" said some shlub form the interweb who doesn't even sweep the floors at Intel.
No, Intel should run its own business and if people don't like the way Intel runs its business, they should stop giving them money. If this hits Intel's bottom line they will have a reason to make adjustments without referring to random Internet person "Craig Cruden" giving them free advise.
You either didn't read Apple's statement before linking it, or you didn't understand it.
What it actually says is that Apple's ARM designs are all vulnerable to [Meltdown or Spectre]. So you got the most important part muddled.
And another publicly known fact is that there are a bunch Russians slimeballs with skin in the game, going so low as to troll-mod community sites like Slashdot. Understand this Ivan: you just provide more evidence every time you do it.
Can you cite the slightest piece of concrete evidence for this lurid fantasy?
Why don't you just go ahead and cite your concrete evidence that Russian slimeballs are not slithering around this site, Igor.
When all you have is a hammer, every problem starts to look like a thumb.
Nice description. Now tell me how knowing the _addresses_ in L[123] cache is any kind of exploitable breech? No-one is talking _data_, and the 'sploit described (history dumped) is pure userspace, most likely a cleverly crafted URL like file:///C\:Users\ .
If you're as worried as Theo, just turn off RDTSC (seccomp) as MS did long ago (Win98?), likely to disable a less-than-favorable benchmark.
"at the time, this kind of timing attack was not a thing."
It's a classic race condition.
Any time there's a possibility of a race condition, sooner or later it will bite you in the ass. The only way to win is to ensure there's never a race to be won.
"The right thing for intel to do IS to recall all CPUs for users that request it."
Are you kidding?
This is the same Intel who released Atom chips which _will_ drop dead at ~2 years of runtime and will only exchange them if they do so within the warranty period.
It's a classic race condition.
Not it isn't, it's a statistical timing thing.
When all you have is a hammer, every problem starts to look like a thumb.
"While the vast majority of computing devices are impacted by these flaws, the sky is not falling. Both vulnerabilities require an attacker to be able to run their code on the device they are attacking. The typical consumer is still vastly more likely to be targeted by something like a phishing email than a targeted attack exploiting Meltdown or Spectre.
"However, these vulnerabilities break down some of the most fundamental barriers computers use to keep data safe, so cloud providers need to act quickly to ensure that unauthorised access, which would be very difficult to detect, does not occur."
Kalember said that if there was some good news, it was fortunate that these vulnerabilities were discovered and responsibly disclosed by respected researchers as opposed to being exploited in a large-scale, potentially-damaging global attack.
"Organisations worldwide need to immediately implement the Kaiser patch to address the Meltdown threat and we applaud the quick action by companies such as Amazon, Google, and Microsoft to do so. While there is no immediate fix for Spectre, we would hope the chip manufacturers learn from these vulnerabilities and weigh the security implications of their new product features," he added.
Basically this isn't a big deal to anyone but cloud services. Normal end users don't need to patch anything and will be totally safe not doing so. Also Meltdown is fixable but Spectre is not.
If this really were serious, it would have been exploited way before now sometime in the 23 years since it existed. It is NOT a flaw, it's a standard design which was intended.
Ummm, the cold war was invented (trumped up, lol) by a nazi defector to russia.
| Not it isn't, it's a statistical timing thing.
What do you think a race condition is?
Please stay far away from any code I care about.
When all you have is a hammer, every problem starts to look like a thumb.
Ubuntu has fixed kernels in testing now for 14.04. I don't see any final release date slated. They're not currently available via the standard package trees. You need to add a PPA to get the testing version. Ubuntu SecurityTeam Spectre and Meltdown
"it would have been exploited way before now sometime in the 23 years since it existed"
These arguments are totally bogus.
How do you *know* that it hasn't been exploited?
These two vulnerabilities have the NSA stink all over them. Obviously not for creating the bug in the first place, but I wouldn't be surprised if they have working exploits, and may even have "encouraged" Intel to delay patching.
Okay, so why isn't this a race condition, and what IS the difference between a race condition and a statistical timing condition?
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Linux has a problem with OS's.
My concern is that since AMD CPUs are (nearly completely) immune from these issues, will software patch/band-aids for these issues also affect software on AMD platforms?
Self-importance and self-indulgence is the root of ALL evil.
The timing thing is about a side channel. Race conditions are not about side channels, they are about lack of essential synchronization.
When all you have is a hammer, every problem starts to look like a thumb.