Slashdot Mirror
OpenBSD's De Raadt Pans 'Incredibly Bad' Disclsoure of Intel CPU Bug (itwire.com)
troublemaker_23 quotes ITWire:
Disclosure of the Meltdown and Spectre vulnerabilities, which affect mainly Intel CPUs, was handled "in an incredibly bad way" by both Intel and Google, the leader of the OpenBSD project Theo de Raadt claims. "Only Tier-1 companies received advance information, and that is not responsible disclosure -- it is selective disclosure," De Raadt told iTWire in response to queries. "Everyone below Tier-1 has just gotten screwed."
In the interview de Raadt also faults intel for moving too fast in an attempt to beat their competition. "There are papers about the risky side-effects of speculative loads -- people knew... Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies -- so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk."
He points out this will make it more difficult to develop kernel software, since "Suddenly the trickiest parts of a kernel need to do backflips to cope with problems deep in the micro-architecture." And he also complains that Intel "has been exceedingly clever to mix Meltdown (speculative loads) with a separate issue (Spectre). This is pulling the wool over the public's eyes..."
"It is a scandal, and I want repaired processors for free."
In the interview de Raadt also faults intel for moving too fast in an attempt to beat their competition. "There are papers about the risky side-effects of speculative loads -- people knew... Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies -- so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk."
He points out this will make it more difficult to develop kernel software, since "Suddenly the trickiest parts of a kernel need to do backflips to cope with problems deep in the micro-architecture." And he also complains that Intel "has been exceedingly clever to mix Meltdown (speculative loads) with a separate issue (Spectre). This is pulling the wool over the public's eyes..."
"It is a scandal, and I want repaired processors for free."
OpenCores.org
J-Core.org
riscv.org
gaisler.com
OpenSPARC
There is a path forward, but it will take Fab relationships and people willing to test and then buy the first practical and fully open systems...
You know, he's not wrong. This is, in impact, way bigger than Intel's FDIV fiasco and that ended up in recalls.
I disagree. Wider disclosure of a vulnerability means a greater chance that it's leaked to those who would exploit it for malicious purposes. There are lots of operating systems that run on the 32 and 64 bit AMD/Intel architecture. Should every single OS developer be notified of the vulnerability? Alternatively, notify those who have the largest user base, while trying to limit the disclosure. There is no perfect solution, but I favor limited disclosure. Frankly, OpenBSD just isn't that widely used, and if there were more users, they probably would have been notified ahead of the public disclosure.
Yes, Intel has tried to conflate Spectre and Meltdown to avoid negative PR. That is a legitimate criticism, but one that's not at all new. Otherwise, it's a lot of butthurt because OpenBSD just doesn't have that many users, and therefore wasn't notified.
Disclsoure is incredibly bad.
It only took 1 more second to add architect@FreeBSD.org in the CC box. It wasnâ(TM)t hard to do.
While I agree the whole thing was handled badly, in fact it was The Register who was going to print the story long before Intel, Google or anyone wanted them too. This sort of threat required more secrecy and unfortunately The Register exposed it long before fixes were really ready. Moore's Law seems to be the big culprit in this as the chip makers ran up against a brick wall in terms of core speed. I don't agree that Intel knew the risk and not even sure given the exposure time without a exploit has been a big risk. Over a decade and no attack against this? No a huge risk to me. Sadly the hype and anger against Intel is unfounded and Intel is not alone in using this design and I am sure other chip makers saw it as a good way to increase speed.
Yeah the computer industry is totally different from the automotive industry.
Funny, both me and my friend worked at companies where we were told to ignore risk. Why would intel be different?
Avantgarde Hebrew science fiction
+1.
Sounds like Theo is channeling his inner Donald Trump.
However...
Both FreeBSD *AND* NetBSD knew about the bug before it was public knowledge. If OpenBSD didn't know then ...
This has been extremely worrying. What's more worrying are the number of 'security researchers' regurgitating Intel's bullshit verbatim. We have yet to fully see the fallout from this.
He's also dead right in that Intel has been mixing up the two issues, Meltdown and Spectre, deliberately, so they could tell everyone that it wasn't just Intel that was affected, and they also gave the impression that Spectre had been fixed when it was Meltdown that had been mitigated - with a patch that creates unacceptable performance problems, to a lesser or a greater extent.
Yes, all processor manufacturers are affected by Spectre, but it is Intel that is mostly affected because they implemented speculative loads badly without much attempt at segregation. They've also attempted to pass this off as 'historical architectural decisions we can do nothing about, but it is working as designed'.
On january 4. I noticed a sudden change in our systems running in AWS. I have set some scaling factors that suddenly started kicking in without any visible changes in traffic pattern or userbase. It turns out our EC2 instances have seen a 50% inrease in idle load, that is quite significant!
Allthough it is only from 20% load to 30% I will still claim significant being idle load.
captcha: banally
>is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk
The specific issue that Pentium line CPUs: a) do privilege check asynchronously; b) do it only for the "winning" execution branch was very well known among CPU design community.
Intel architects even bragged about that as their "innovation" in industry journals and filled a number of patents for that (this is the reason amd privilege checker runs on all branches)
Intel makes a monumental decision to benefit the short-term interest of their corporation at the long-term expense of their customers, then tries to weasel out of a equitable fix for their customers? It's not only their product that can't be trusted, it's their judgement at all levels. Heads need to roll at Intel for this....
Everything in the Universe sucks: It's the law!
"It is a scandal, and I want repaired processors for free."
And I want a pet unicorn. Come to think of it, unicorns are about as real a thing as a "repaired processor" since they physically cannot be repaired. He wants a replacement processor which almost certainly is never going to happen. Basically he's asking for every processor produced in the last 20 years to be replaced for free. If you think that's realistic I've got a bridge to sell you.
There will be plenty of legal action over this and the results of that will be the full extend of any compensation. Furthermore to get compensation he will have to show actual harm incurred. Simple fact is that at least so far there has been little to no tangible harm from this problem to date so standing will be an issue for anyone who sues. This might change in the coming months/years but until it does the chip makers aren't going to pay a dime to replace anyone's chip - flawed or otherwise.
He wants Intel to redesign and fab up EVERY processor made in those years. Ainâ(TM)t gonna happen.
Crock of shit, you mean like your own comment?
To quote Linus "A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains." It's pretty bleeding obvious that either the Intel engineers are completely incompetent, or they were instructed to look the other way.
There are no other alternatives. Linus says so, and now Theo too. Who are you, oh mighty commenter who knows better?
Yawn. Ankle grabber, STFU.
Open Hardware doesn't fix problems in silicon that has already been manufactured. It might help with the next generation but it won't prevent bugs from appearing in the first place.
Bear in mind that the reason Open Source software works so well is that the marginal cost of (re)production is close to zero and that there are (comparatively) minimal capital costs. Really you just need a PC and a lot of time. Open Hardware is a worthy goal but it's going to be a LOT trickier to pull off in the real world for mostly economic reasons. Furthermore hardware isn't protected by copyright for the most part. It's protected by patents and those are expensive. Worse once someone has one on a piece of kit they can basically shut down any open hardware that uses that idea for the next 20 years.
"... I want repaired processors for free."
So do I. I want backdoor-free processors without payment. I will send Intel the faulty processors.
Intel CPU Backdoor Report (Jan. 1, 2018)
My opinion: Intel is a world-class company, with poor top-level management. Brian Krzanich is not the kind of person who is necessary. He is not a person with enthusiasm for technology combined with the social ability to lead a large company. One story about Krzanich: Intel CEO sold all the stock he could after Intel learned of security bug.
Paul Otellini, the previous CEO, was worse, in my opinion. Otellini "joined the finance department in 1974" I complained about Otellini 11 1/2 years ago in a Slashdot comment: More Intel employees should say in public what they have told me in private: Intel CEO Paul Otellini is not a competent leader. He lacks social ability. (June 09, 2006)"
Intel's health and strength is important to everyone on the planet, it seems to me. The technological part of the company can be excellent, but recent top management has not been able to handle the challenges.
The underlying issue, it seems to me, is that the process of choosing new CEOs tends to be defective. Perhaps all employees should have 50% of a vote, with the board of directors having 50%.
Beating the competition happens without increased risks to customers?
How do you measure risk as a buyer and what are the alternatives?
Lisa Nowak, a NASA astronaut, drove two days and 900 miles in a space diaper to confront a woman dating her ex-boyfriend. Why would anyone not do the same?
To quote Linus "A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains." It's pretty bleeding obvious that either the Intel engineers are completely incompetent, or they were instructed to look the other way.
Oh, Linus said it so that means he's an expert at CPU design. That's like saying competent engineers don't work at failed CPU companies yet Linus worked at Transmeta, so go figure.
I dont care how much better their next CPUs might be, im jumping ship for AMD on my next upgrade. I did the same after NVidia fucked me over.
Comment removed based on user account deletion
To quote Linus "A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains."
That's bullshit. When Intel introduced speculation across protection domains everyone including Linux was happy because it reduced system call costs. Without this, as soon as you get to a syscall / sysenter instruction, you stall the pipeline until all pending instructions have been committed. On a modern Intel CPU with close to 200 instructions in flight at a time, that's a measurable performance overhead.
We've known for a long time that side channels of this kind were possible, but not that they were performant. The new attacks are not interesting because they're side channels that allow data to be disclosed, they're interesting because they're side channels that allow disclosure far faster than previously believed. CPU designers believed that this kind of attack could only be exploited to get a bit every few seconds, at which rate it's not really worth trying as an attack and is pretty easy for software to spot (hmm, why is this thread at 100% and triggering insane numbers of cache misses? Looks malicious...). Now we know that you can use these attacks to get data at about 0.5MB/s, so you can scan the whole of memory in a few minutes.
I am TheRaven on Soylent News
hahahahahaha
You really are an idiot. First of all, it's not Linus says, it's Linus and Theo who, wonders of wonders are in agreement, even if they express it somewhat differently.
Secondly Linus doesn't work at a failed CPU company. He works afaik for the Linux foundation.
Thirdly, Linus once worked for a company which failed, so therefore Intel engineers are competent and their management all above board, despite the evidence? Ever heard of a non sequitur? Because if you didn't, well, congratulations, you just wrote pretty much a schoolbook example of one.
Fourthly, none of that addresses the issue of "who are you, who claim to know better than these too at least reasonably competent people"? Let me guess, a lame failure at life, trying to make up for that by spreading bile on various forums on internet.
I was one of those who called "no way" at first, but just yesterday I found this quote from an Intel engineer. It was originally posted in a reddit thread but has since been deleted - but not before being confirmed by other former engineers at Intel.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
As others have previously, it is now time for a completely open processor. I like the work of openrisc and risc v projects. In my opinion, Intel is standing at the precipice of its own undoing. Intel's steadfast refusal to issue a recall is just hubris and might be a call to arms for competition to knock it down. This year might very well be the year that a few kickstarter projects get launched and that we have the beginnings of an exciting new trend in computing.
Not to be an Intel apologist, but clearly they can't afford to replace everyone's Intel with an identical socket that is unaffected by the problem. The best I'd think that could be hoped for would be a refund with depreciation of value on the processor. That'd still suck but I can't see how we'd get any more. A class action would just get us all a $15 coupon towards our next Intel purchase.
And I want a pony
Ok, so instead of one software engineer who's not a CPU designer making claims about what represents good CPU design you're quoting two software engineers who are not CPU designers. That gives a lot more weight to your argument.
When you look at the actual affected processors vs. the number of people who will actually get off their ass and make a claim to have a processor replaced for free, it becomes very clear how affordable this really is.
A good point but not as good as you make it seem. Quite a lot of affected chips are not user serviceable for reasons such as being soldered to the board. This means that it isn't a simple matter of sending a customer a new chip. In many cases the boards in question won't be available for any price so the most a chipmaker could do would be to pay for a replacement. A repair simply isn't going to be an option in many cases.
But you are right, 99.99999% of people will probably have forgotten about this in a week and the only people concerned about it are the 5 or so of us who still read slashdot. Most people won't have even heard about the problem and most of those who do wouldn't know how to deal with it anyway. Basically it will go away when the current generation of PCs is retired in a few years.
Funny, both me and my friend worked at companies where we were told to ignore risk. Why would intel be different?
There is risk and there is risk. In the work I do risk means that someone could die. It may be that in your and your friends work risk means some people might not be able to access their social media platform for a few hours and not be able to post pics of their cats. For Intel the risk is that their systems run unchanged for multiple years at a time and have a huge market share and could require a hardware fix in order to correct any issues that come up.
I am Slashdot. Are you Slashdot as well?
If I may, I'd have to call this an anecdote rather than a quote. The description is from years after the Intel meeting, and doesn't have direct quotes of speech or writing of the personnel involved in the policy change.
With that understood about the anecdote's provenance, it is _completely_ believable. It is precisely the sort of mandate that can save a company in the short term, preserving the jobs and careers and technological development the company is doing, at the risk of a deadly failure down the road. It's the sort of business risk assessment that occurs on an annual basis when testing standards and guidelines are set. It also occurs on a daily basis when security practices are created: do we accept the risk of a breach today, while this is unpatched, versus the risk of service failure or loss of business during system updates?
No, it's not tricky to pull off.
If it wasn't tricky to pull off then it would have already been done on a wide scale. I'm not saying it's impossible but it is going to be a much tougher nut to crack than open software. Mostly for economic reasons rather than technical ones.
- Research and make use of expired patents extensively, file new ones defensively.
Who is going to do this? Who has the funding and more importantly the incentive to do this? IBM received 8000 patents in 2016 and numerous other tech companies received thousands more each. Exactly how do you plan to match that sort of pace? How do you plan to produce anything really useful without infringing on a pile of those patents? Not to mention fending off the flesh eating lawyers that give those patents teeth...
It's more capital intensive than software, but it's also not that expensive either.
I'm a certified accountant and an industrial engineer. I do cost accounting for a living. It is a LOT more expensive than software no matter how clever you are. There is a reason gross margins in manufacturing hardware are far thinner than in software. You don't escape these costs by just doing design either. Someone eventually has to make the product and that will require substantial capital. Then you have the cost of distributing the product. Unlike software which can be sent across the net for nearly free, hardware has to be shipped, stored and turned into products, all of which cost non trivial amounts of cash. If you think it isn't substantially more expensive than making and distributing software you haven't done the math.
" I bet they were instructed to ignore the risk."
While the hood is open on the chip, the info leak seems relatively easy to fix.
If so, then to say don't do it would only make sense if they learned way late in their design cycle.
The thing that makes mem requests probably knows what ring the processor is at.
With a few more parts, it could include this in the mem request.
The part of the memory that knows the physical address also knows which rings are ok and could tag the request as not good to go.
Then if the request was not good, the result could be set to zero.
Just let everything run as it does now and set the result to zero.
Removing the 'feature' might not affect the flow of the logic that much.
As for the layout, it is not that much more logic who knows until thy try it?
Of course, when Linux was new the argument was that an OS was just too big for a bunch of Free Software fans to manage.
You are making a false equivalency here. Making and distributing software is COMPLETELY different than making and distributing hardware. The economics could not be more dissimilar. The legal protections (patents vs copyright) are different. The amount of up front capital required is different. You can modify software after it has been release but you cannot do that with (most) hardware. Basically just because it worked out well for software is does not mean it will work out well for hardware. Hope for the best of course but it's likely to be a difficult nut to crack.
Only a big corporate structure could support development of anything as complex as an OS.
Ultimately that turned out to be true. Basically all the developers of linux and most other major OSS projects are employed at large tech firms (and a few large foundations) and are paid to maintain them. It isn't a bunch of hobbyists in their garages.
Open hardware is harder, but probably not impossible.
Not impossible but for non-trivial applications it appears pretty close to it. The obstacles are predominately economic ones and some legal ones and they aren't minor obstacles. I'm not about to hold my breath for patent reform anytime soon and the patent swamp is a real problem. And the economics of making and distributing hardware are immutable. I think Open Hardware is a very worthy goal but it's going to be quite the challenge.
I thought that was the point. So info doesn't leak to attackers. Stupid comment on this guy's part IMO. There is no way to keep something secret if you tell too many people.
It would be interesting if anyone who knew about the bug traded on the known info
When Intel introduced speculation across protection domains everyone including Linux was happy because it reduced system call costs
Is that the case? Was this attack known, and deemed an acceptable risk because of the incredible low rate at which data could supposedly be extracted? I remember some papers around 2015 on an attack involving data leaking between processes through the cache, but that did not rely on speculative execution IIRC.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Sod off!
Everyone running an intel CPU will suddenly discover that they have 5-30% less processor than they paid for.
Untrue. The hardware is unchanged and can run exactly as fast as it always did. Security updates and software slow machines all the time. You'll have to credibly explain why this case requires special consideration. Easy to claim here but not so easy in front of a judge. Frankly most people aren't even going to notice and the few that do notice are going to be corner cases, mostly in large corporations with adequate resources to deal with the problem. From a 10,000 foot view it's not clear why this is meaningfully different than any other serious malware incident. It's not as if it is the first time a flaw has been taken advantage of in hardware.
In many cases, that difference would have resulted in going with the AMD processor. That is a real economic harm that deserves compensation.
I'm afraid it's not nearly that easy. Product liability is a funny thing. First off there is not likely any strict liability here so there is no automatic requirement for compensation. Second, there is unlikely to be any physical danger to anyone. Third, while there is a cost to dealing with the issue it isn't clear that the cost is out of line with other serious security issues including malware. Finally, you still haven't shown the economic harm. I'm sort of playing devil's advocate here just to illustrate the challenges here. In principle I agree with you but the law very likely may not agree with us.
Yes, because hardware isn't magic. Hardware, just like software is basically logic.
All that engineer this or engineer that aside, anyone with half a brain understands that handing out the keys to the kingdom to anyone asking for them just in case they actually might be entitled to do so in the hope that you'll be able to stop unauthorized use before anything actually happens is an extremely stupid thing to do. It's literally playing Russian roulette with five chambers loaded, gambling that you'll be able to push a screwdriver in front of the hammer in time to save yourself if needed.
And I'm not making _any_ argument, I'm just noting that these two people, who are generally considered both smart and talented but usually can't sing from the same sheet to save their lives are in complete agreement.
You, on the other hand make all kinds of claims about their personalities, their motives, the motives Intel management etc, etc.. And you won't event tell us who you are, or what your qualifications are. (None, I take it.)
I'm done with you. Good day, sir.
Change log:
2018/01/01 - Added 14 Useful Links. Disable Intel ME 11 via undocumented NSA "High Assurance Platform" mode, Blackhat Dec 2017 presentation, Intel ME CVEs (CVSS Scored 9.0-10.0)
Intel CPU Backdoor Report
The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.
What we know about Intel CPU backdoors so far:
TL;DR version
Your Intel CPU and Chipset is running a backdoor as we speak.
The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.
30C3 Intel ME live hack:
[Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Quotes] Vortrag:
"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".
"We can permanently monitor the keyboard buffer on both operating system targets."
Backdoor removal:
The backdoor firmware can be removed by following this guide using the me_cleaner script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.
2017 Dec Update:
Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP mode.
Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.
If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).
Useful links (Added 2018 Jan 1):
Disabling Intel ME 11 via undocumented mode (NSA High Assurance Platform mode)
Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine
EFF: Intel's Management Engine is a security hazard, and users need a way to disable it
Sakaki's EFI Install Guide/Disabling the Intel Management Engine
Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws.
CVE-2017-5689: An unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs
CVE-2017-5705: Multiple buffer overflows in kernel in Intel Manageability Engine Firmware
CVE-2017-5706: Multiple buffer overflows in kernel in Intel Server Platform Services Firmware
He's right. "disclsoure" is incredibly bad. My English teacher would have rapped his knuckles.
Funny, both me and my friend worked at companies where we were told to ignore risk. Why would intel be different?
Because all companies are not identical? Do you think everything you and your (imaginary?) friend have in common is also common to every company?
Also, what do you mean by "risk"? Do you think it's reasonable (or even possible) to eliminate all risk of a security breach? When did anyone accomplish that?
Was this attack known, and deemed an acceptable risk because of the incredible low rate at which data could supposedly be extracted?
Not this specific attack, but it was known that any source of nondeterminism in a processor was a source of side channels. These were largely ignored because these attacks get lots of papers at top security conferences but are really hard and slow to carry out in practice. Most of the existing attacks used the cache, but there are others involving things like the fact that computation on denormals is much slower than on normal floating point values (a fun one of these lets you scrape browser contents via WebGL and I don't believe has been mitigated yet in spite of being published a couple of years ago).
Speculative execution was known to be a potential source of these side channels for a while. Now that it's shown to be feasible, expect a lot more similar attacks.
I am TheRaven on Soylent News
Maybe Theo de Raadt would be notified more in advance if he didn't break embargos like he did with the KRACK vulnerability...
From a big picture perspective, the making of the hardware has already been detached from the design of the system.
Doesn't matter. You still have to make it and that still will cost money. Doesn't matter if you make it in house or if you hire someone else to do it. If doesn't matter if you have the secret formula for Coke, you still have to put sugar water in bottles and ship it somewhere which is expensive. It's FAR harder to bootstrap the funding for an open source hardware design than open source software.
Would a manufacturer take the risk of making a huge investment that relies on Open Source designs? They already do. Most mobile phones are entirely worthless without Android, an Open Source software.
You're conflating issues. You can already send an open source chip design to a chip fab or a hardware design to a contract manufacturer. My day job is general manager of a contract manufacturer (wire harnesses) so I'm more than passingly familiar. But just because you have outsourced production doesn't mean that the costs for it go away. Your analogy to Android is a meaningless one here.
Just because someone else makes it doesn't make the patent swamp go away. Open source software works precisely because how copyright law is written. The GPL and every other license basically only works because of copyright law. That doesn't apply to hardware. To protect hardware designs you have to get patents on the design and that costs serious money. Not only that you have to avoid infringing other companies patents which is not a trivial exercise when companies like IBM, Google, Apple, etc are getting thousands of new ones every year.
Companies that rely heavily on open source software can do so because they have an alternative revenue source. Typically service or engineering - sometimes ads. What is the alternative revenue source for open hardware? Service? Maybe but the revenue streams aren't quite as clear for open hardware. And even if they become clear it still doesn't solve the capital costs and patent issues.
I'm not saying it's impossible but it definitely will be difficult for open hardware to achieve the sort of success we've seen with open software.
The ONLY example were patent enforcement works in OTHER people's favor. Thanks Intel.
Alexander Peter Kowalski you really need to stop spamming your work that offers no provable security.
I provided you with numbers showing that your work reduces the attack surface by less than 1/(1x10^100) or a value that easily rounds to 0.
Your work doesn't stop attacks before hand only long after they are discovered.
Your work also requires that people take manual action to get those updates other wise they are not protected.
So just remember folks Alexander Peter Kowalski can't wait to spam is garbage work that is as effective as an AV scanner that matches only based off of file names.
Lisa Nowak, a NASA astronaut, drove two days and 900 miles in a space diaper to confront a woman dating her ex-boyfriend. Why would anyone not do the same?
fake story. you imagine she wore a diaper because they were in her car, yet zero evidence that she EVER wore one.
I think your making a mountain out of a mole hill. I agree, Intel should take a hit, but you DO NOT fix hardware problems with software. Not that it can't be done, but that is not the way it should be done.
The team that developed the lookahead hardware wasn't in sync with the other teams working on other parts of the CPU. Sounds like they went to press still lacking the ability to set parameters that would limit the scope or bounds of the lookahead.
I doubt anyone was instructed to ignore the problem. I think they went with what they had at that time, then someone hit the GO button and pushed the product out the door. Was it an EARLY release? Most likely.
The problem I see is the way the info was released. Why is it so hard to find good help to run some of the largest companies in the world. Management dropped the ball. End of story!
*BSD isn't even as big as a pimple on bull's ass. *BSD is a non-player in the real world.
AMD gave performance AND security BUT that's NOT what people wanted. They wanted performance above all else to the point the media was calling AMD the walking dead till their latest CPU came out. Fanbois were bragging and telling everyone they wouldn't buy AMD because...tah dah...performance.
Linux Now Has its First Open Source RISC-V Processor, Slashdot. To answer AC's question a few moths later: "What's the big advantage with RISC over ARM or x86?" Meltdown, Spetre.
ARM is a RISC architecture, and plenty of RISC architectures suffer from Spectre
I think the GP was using RISC as an abbreviation for the RISC-V brandname, not RISC as in the architecture design approach. Indicating an advantage of RISC-V CPUs over ARM or x86 CPUs.
That is just APK (Alexander Peter Kowalski) not signing his work.
As such he will post it 100 more times today, just like he does with hosts.
He doesn't sign things that are ultra racist or ultra anti-Semitic but he likes to post them.
He will frequently do the same to make it look like he has some support of his poor security advice as well.
This is the best comment to the situation I have read so far.
...?". One can say that the question is very legitimate - yes it is, when it is asked in each case.
I find it peculiar that when Intel CPUs have a bug, it is "all computers", otherwise CPUs manufacturers are named, similar when MS Windows have security issues it is "all computers", whilst otherwise an OS is named explicitly. One may say it is purely because of the sheer number, however I do listen and read a lot and the corporate PR behind the "neutral" news announcements is so obvious that it becomes comical to certain extent.
Once, when listening to some podcast the WiFi key issue was mentioned and one could almost hear the chink of silvers behind the question "Are all OSes affected by this
Speculative execution across ring changes is the root cause of this.
Amazing how cascade works. Ultimately as Arstechnica pointed out things like the TLB, pre-fetching, and splitting as well as rings and modes all result from a lack of ability to fitting the entire page table into chip-memory. Just think of how many problems would go away if one could do that.
Please stop spamming.
Sounds like timing is the thing that doesn't need to cross security boundaries. Timing itself can be inferred.
Bullshit you say, and yet it's only Intel and a few, comparatively insignificant ARM chips which are affected by meltdown, which btw, was what Linus was referring to.
I can only presume AMD is an imaginary entity in your little world, because they apparently managed to solve all these impossible problems without handing out the keys to the kingdom to everyone who asked for them.
Bullshit, yeah, plenty of that in your post.
I'm no fan of Intel but I can't help but see Meltdown as at least partly the fault of OS vendors. They decided to keep kernel and user memory in the same address space for performance despite known problems with branch prediction and despite KPTI being an option.
I doubt Intel ever claimed prediction could not be detected nor forced kernel devs not to use KPTI. Usually when a vulnerability is found in a software architecture you blame the software.
yet another vulnerability that could have been avoided by using C++ instead of C. std::string, anyone?
I've been seeing some estimates of 5%-30% load increases when patches for Meltdown are applied to various OSs.
So I'm running VirtualBox for VM test-bed stuff. If the host OS (Linux, in this case) has this extra load, I'm guessing the guests will also have their own extra load added in. Is it correct to think that the host CPU might well have >50% load thanks to this?
Trolling is a art,
(Posting anon to protect myself.)
I was involved with Intel and their Curie module.
If you know how bad that was and how many silicon level bugs there were, well, at this point I think you would believe it.
They made a TV series from that chip (as a PR move). Just a year later, they EOLd the chip and now Mouser/etc have thousands of unsellable Curie chips that no one wants. Intel even removed all traces of their TV show event, as if it was an embarassment to them. Everyone that was part of that event left Intel, as far as I know.
The Intel CEO grabbed a lot of the glory of dealing with celebrities and just wanted to be on TV. I can tell you that people who worked that project were treated like crap, but the execs got TV time and glory.
The chip still sucked and its unsellable, now.
Intel gave up on IoT. They had to. They would not listen to anyone and of course they failed since this is not their core competancy.
Intel is now a joke. H1B's walk the hallways. And contractors, tons of contractors. What does that tell you, when they hire temps more than fulltime people?
I would not integrate with Intel chips, given what I've seen.
FreeBSD represents over 50% of the data moving across the Internet. And it's estimated that 90% of all traffic going through a device powered by FreeBSD or in-house custom OS based on FreeBSD.
I am willing to bet a marsbar that you weren't "told to ignore risk" but rather that the risk assessment process was handled by a different department or at a different paygrade.
Humans are horrible judges of risk which is why it *should* never be left up to individual people (especially people within a single field) to determine.
Intel should let all affected processors on all motherboards be overclockable. That might satisfy the tech nerds who care about this most without costing Intel too much money.
(T>t && O(n)--) == sqrt(666)
That meeting there in late 2013 signalled a sea change at Intel to many of us who were there.
Well maybe it was, but these problems predate 2013. Guess the "validation" that was happening in the 18 years between 1995 and 2013 didn't amount to much.
Maw! Fire up the karma burner!
But, wasn't Meltdown an issue with Intel CPU's far before this change in validation happened?
OpenBSD's De Raadt Pans 'Incredibly Bad' Disclsoure of Intel CPU Bug
"Disclosure" in the headline has been incorrectly typed out is "disclsoure".
Perhaps the groundwork needs to be laid for an open, modular FPGA platform, to allow for the creation/modification of CPU cores without having to rework the silicon weekly.
There is no XUL, only WebExtensions...
Comment removed based on user account deletion
Man, have you ever drunk the software caveat-emptor Kool-Aid whole cloth.
The specifications for hardware and software are not that it will work as specified.
The specification is that, with sufficient user cleverness (and sweat streaming off a bulging forehead, and unbroken vigilance) it is possible to almost get the hardware or software to attain its putative performance ratings without catching one or more incurable black hat diseases along the way.
This ethos dates from the 1980s and 1990s when the upgrade cycle (both hardware and software) was three years at most, and the whole drama could barely play out in that time frame.
I bought my Sandy Bridge Xeon in January 2013 and I'm not sure I'd take a free swap to Intel's newest equivalent, because the hassle of swapping over probably exceeds the expected gain (my average uptime, when the power company isn't replacing faulty-from-birth concrete power poles, has averaged well over a year, and there hasn't been a single hardware or OS glitch that I know about since I eliminated one suspect hardware card, back in the first few months).
I make fairly heavy use of BSD jails, and I've always regarded process isolation as more important than raw performance.
Punting isolation from hardware to software is a Sisyphean burden. One important binary on your system that wasn't compiled with the right compiler (on the right day) and the game is lost. Worst, if there's a 'retguard' gadget variant of the attack, you also have to use the right linker (on the right day), because security is (potentially) no longer link-order independent. Lovely, lovely, isn't that lovely.
This giant, amorphous, hard-to-discern attack surface is now my problem because "durf durf, complicated, too many transistors" and "we can't read widely circulated papers pointing out that one of our optimizations is full of shit" and "caveat-emptor grandfather clause—so suck it!".
If there was a paper from long ago pointing this out (as I've seen stated in this thread, but haven't check out myself) then there's going to be an MFT of legal discovery pointed at Intel to find out what they knew and when they knew it.
The GHz wars were a great thing, because it rapidly erased your worst corporate blunders.
The beleaguered end-user responded to constant threat by refusing to buy computer systems with CPUs and memory soldered to the mainboard (only then it was a bug in an ASUS northbridge—newly introduced when they bumped the much-loved board from an A to B revision—that caused the disk controller to scribble randomly over my hard drive, taking out three different OS boot partitions in a single bound).
Once vendors start soldering CPUs and memory to main boards, it's like, so long puberty, you're apparently an adult now.
Adults in every other industry recall or replace products that don't work as least marginally to original specifications (without forcing the end-user to jump through a thousand flaming hoops).
It's high time to set aside childish ideas that this technology (alone) can demand unlimited user backflips before any restitution is warranted or justified.
To steal a recent quote about this issue, "I don't need to be a baker to know when the bread is stale."
A cutting-edge fab can cost $10 billion. A non-cutting edge fab isn't going to be remotely competitive with offerings from Intel.
Tape out to a foundry? Doable, though expensive. And if you do that, how do you know the NSA doesn't have them bake in a tiny spy core into the chip?
Think of it as the hardware equivalent of the Ken Thompson compiler-injection attack.
Here is their timeline. Surprising that (unlike RedHat) there is still no patch.
You are mentally modelling KPTI as an annoying one-time fix (with not much further burden), and not as a brittle work-around that requires permanent vigilance to pervasively deploy and enforce (Google's retpoline certainly falls into the class of permanent vigilance burdens).
Not to mention that your carefully performance-balanced server loads need to be re-engineered around this unpredictable new performance sink-hole. KPTI is not as simple as a CPU microcode update (which also has performance implications, though not usually broad and severe).
This whole mindset of "a patch, is a patch, is a patch" coincides with faulty logic in OS hardening. You see this opinion all the time that an attack mitigation that can be easily worked around isn't worth implementing.
That's the non-metabolic view.
The metabolic view is that every extra difficulty adds complexity to carrying out a successful attack. When we are trying to build something constructive, difficulty scales exponentially in the size of the specification, as we all know. When we are tying to build something destructive (a root kit), this same scaling term is now magically rendered sub-linear. (There might actually be a grain of truth here, due to the inherent asymmetry of success and failure, but that should hardly be taken for granted.)
We try to stack up ASLR and sundry related obstacles to tilt the balance in our favour, then along comes Intel, who dumps a permanent burden on the white hat side of the fence.
How many hundreds of millions of devices out there are never going to receive a patched OS that's compatible with the existing, validated device configuration?
Well, of course, the newest version of the OS is a strict superset of the old OS (though MacOS is not included on this list by virtue of superior Design), and you should stay up to date anyway.
I've been in this industry since the 8080. Enough already with the Stockholm syndrome.
Just imagine Boeing retrofitting your turbo fan with 20% less maximal thrust due to faulty wing design. So the airlines need to stop flying Boeing into Denver on hot days? (Surely your air service scheduling system can manage one more tiny constraint.) What's the big deal? Problem solved.
Comment removed based on user account deletion
Don't know who dubbed it "meltdown" but some non-techies think that this involves physical damage to their processor.
...I would not be surprised to see advocacy for alternative architectures from those circles, be that AMD or ARM.
Theo can now rightly say that Intel design flaws will have 0-day impacts on OpenBSD that are beyond his control.
If Intel are not going to supply paid replacements at reasonable cost, then I expect them to be forced to supply for free all necessary info to anyone else who wishes to make and sell replacements to me on pain of jailing every single shareholder.
You were being more or less reasonable up until that last sentence. Then you took a sharp left towards Crazytown. Intel isn't going to be forced to give up their trade secrets or intellectual property and their shareholders certainly aren't going to jail because you are having a temper tantrum. They aren't going to replace every processor made in the last 20 years nor are they going to even try because it would be impossible. At most you might get a small financial settlement through a class action suit. That's reality and I suggest you start dealing with it.
If they are not willing to co-operate with their customers in producing an equitable fix, the whole lot of them are guilty of unjust enrichment, obtaining pecuniary advantage by deception, fraud, conspiracy to defraud, and anything else a bunch of greedy corporate lawyers can invent.
There is absolutely no evidence that fraud was involved because there was no evidence of intent to deceive. It was to all appearances an honest (albeit serious) error. Therefore by definition it isn't fraud,deception or any of the other words you so casually tossed out there. They may have some product liability but it isn't going to result in jail time for anyone unless there is information we don't yet know.
If Intel goes bust as a result of this, we can expect the official receiver to sell off the patents to someone who will sell us cheaper and more reliable processors (probably not Cyrix).
Intel isn't going anywhere. If companies like VW and BP don't get the death penalty for actual provable fraud, Intel certainly isn't going to see much more than a slap on the wrist.
How is this different (aside from magnitude/number of units sold) from Takata's airbag recall?
Nobody is going to die from this mistake. Pretty big and important difference there. Product defects that result in actual provable fatalities tend to get a lot more scrutiny.
I suspect a recall this large would bankrupt Intel, much like the airbag recall is bankrupting Takata.
Won't happen and while this is a serious issue, it isn't THAT serious. I expect Intel will pay some cash to settle some class action lawsuits (and so will some other chipmakers) but that's probably about as far as it will go unless there are revelations we haven't heard yet.
Bullshit you say, and yet it's only Intel and a few, comparatively insignificant ARM chips which are affected by meltdown, which btw, was what Linus was referring to.
Ye, because Intel patented the technique and didn't license it to anyone else.
I can only presume AMD is an imaginary entity in your little world, because they apparently managed to solve all these impossible problems without handing out the keys to the kingdom to everyone who asked for them.
Nope, AMD pays a higher penalty on system calls, though they mitigate this to some extent by having shorter and narrower pipelines.
I am TheRaven on Soylent News
I'm inclined to agree. Perhaps the CPU engineer could have foreseen prediction leaks, but so too could the OS devs have foreseen problems sharing address space. Why was there not already a KPTI switch?
There's plenty of egg to go 'round faces if you ask me.
I'm personally stunned to see the extend of the Intel-bashing. This "bug" has been around for years and everyone was fine. From a QA perspective, the product was (almost) perfect. Now, yes, a bug has been discovered after years ... that's life.
I'm not an Intel fan but seriously, most people don't realize how tricky exploiting this flaw is. Yes, we have a good exploit now and it works remarkably well, which is why it is such a serious issue. But I can't blame Intel for that, except if they knew it was *that* serious and decided to ignore it.
But in every design there is a security risk and you investigate them and you conclude that some are not likely to happen and sometimes, you may be wrong. But this is a really non-trivial problem, and I'm very surprised to see everybody taking this as a "stupid bug" and ranting about Intel problems (which exist for sure but just like in any company).
But if that was such a stupid bug, why did it go unnoticed for years ??? Kudos to the security researchers finding it.
Would be making Intel give up or provide free licenses to all its patents/copyrights on architectures older than the ones they were willing to replace processors on, and allow 3rd parties to develop compatible processors for Intel architecture motherboards.
Hell, while we are at it, force them to provide documentation for third party developers at some fixed licensing cost for the next 10 years as a punitive measure, opening us back up to second source motherboard and cpu chipsets, something Intel slowly forced out of the market between the Pentium Pro and Pentium 4 eras (Core 2 boards with non-Intel chipsets were mostly P4 boards, with 1333 and above being limited to Intel only chipsets?)
That would be the real way to solve this problem once and for all. Monocultures on hardware platforms with more than a fraction of a percent of marketshare need to be stamped out. While once can say that 'the market can decide that for itself' it obviously can't, and the failures this can cause ruins whole generations of hardware that may only be fit for offline use (basically impossible today) or the scrap heap.
As a random addition: Thanks to Intel ME, there is a good probability everything after the LGA1366 hardware would be difficult to use aftermarket CPUs on thanks to the firmware signing, so that would have to go in order to allow 3rd party cpu support.
Well, that's a good use of a patent then. Who'd have thunk. It's not really all that relevant though, Intel cheated for performance, patented their cheat and eventually got bitten in the arse by it. Now they are trying to pull everyone else with them. That's the story, and it really leaves us only with two options, either Intel are incompetent, or they are corrupt. Why exactly nobody else did the same thing is neither here nor there.
And yes, that might very well be that AMD pays more for syscalls, but the point is, they are pretty damned close to Intel as is. ...And they didn't have to resort to the magical patents to get there. In fact they are so close that Intel apparently are pressuring Linus/Microsoft to gimp AMD with the Meltdown patches, although they are not needed, in the name of some ominous "general security" "threat". Yeah, it's bullshit, but that's how afraid they are of AMD.
And I'd be happy too if you were selling me beef at $0.50/pound. Even if you told me you weren't washing out the containers every single time and those sorts of time savings were why the beef were so cheap. Until, of course, it turns out that people weren't washing their hands and failing to wear gloves all the time.
And this is the issue. Cryptography experts routinely speak of cryptographic schemes being insecure well before attacks on them are performant. It's understood that it's likely someone will come up with a more effective attack within a couple dozen years likely on at least *some* of the potential vectors of attack which will render at least *some* of those cryptographic schemes no longer valid, so it's better to move away from those schemes now. So, even if we were to acknowledge what you're saying, it stands to reason that once those papers were published (a quick google search and there's papers about effective cache attacks from at least 2013) that changes should been made then. Instead, ARM, AMD, and Intel all waited until a performant attack exists and then there's a scramble to try to find fixes and workarounds.
PS - STEALTHMEM: System-Level Protection Against Cache-Based Side Channel Attacks in the Cloud from 2012 and it sounds like much better performance costs compared to KAISER, although not being a security researcher I have no idea if this would be sufficiently to protest against speculative execution as well.
In the case of FDIV, one could point to the IEEE floating point specification (and a hand-calculator) and show that the Intel processor produced a verifiably wrong answer to a divide operation.
There is an explicit set of rules (called this instruction set architecture or ISA) which govern exactly how a given computer is allowed to behave, and the CPU vendors all produced chips which follow those rules.
The ISA says that the memory returned by a load operation is subject to the permissions as setup through the virtual memory protocol, it provides no protection to a malicious person inferring the secret through some other means. They would never provide such a guarantee because there is no known solution to the general problem of 'side-channel communication'.
So, if Intel was looking for a legal solution to avoid paying for a recall--all they have to do is say, "you wanted an x86 ISA chip, that's what you got. caveat emptor". You can't claim they even violated "fitness for a purpose" constraints (in jurisdictions where those protections apply) because these chips are perfectly fit for the purpose of running non-malicious code--and there is basically no known theoretical solution which guarantees containment of malicious code (apart from wiping all implementation state when switching between different threads or something).
Now in practice, Intel (and the other affected manufacturers) are going to do better than throwing their hands up and saying "it's your problem", because there is free market pressure to do so. But they are most likely on firm legal ground in avoiding any sort of massive recall.
But if that was such a stupid bug, why did it go unnoticed for years ??? Kudos to the security researchers finding it.
1.) What is the relationship between time to detection and the level of stupidity necessary to create a bug in the first place?
2.) If a bug gets noticed immediately does that necessarily make it stupid?
3.) If a bug goes unnoticed for some period of time does that necessarily make it not stupid?
Answers:
1 = None
2 = No
3 = No
Avg antivirus is taking up 17mb on your system. While your Host File is taking up a whopping 37mb. A single view program that just adds entries to a Host File takes up 37mb of fucking ram. Jesus Christ man. You talk about bloat. Your program is filled with bloat. A single view program that adds entries to a text file should not take 37mb of ram. Ever.
Funny how all of those recommendations from pros are ancient in computer terms. /. quotes you use have been taken out of context, retracted, or disowned so all other should be viewed as suspect.
How come none of those pros is recommending your software, must not be very effective then?
I wouldn't call HpHosts including your software at the bottom in the Misc. section a recommendation of it, instead it seems like an also ran.
Also a surprising number of
Furthermore user testimonials are not proof, so why don't you just stop embarrassing your self by using them as they are mostly used by commercials on late night TV pushing questionable products (hey that sounds strangely like your work too).
Just because Alexander Peter Kowalski can't follow simple math and logic doesn't mean it is wrong, as they actually do prove that APK's work is easily circumvented and offers no real security.
Yet I see you are still making that same tired claim (your more with less claim in case you lost track) with no evidence, or proof to back it up.
I am not Arth1 but then you have claimed I am everyone who has ever dared point out your near endless failings at one point or another.
I'm not the one making grandiose claims here without proof, you are so you are the one who needs to offer actual proof.
I keep asking for proof and you keep failing to provide any because apparently your work is indefensible.
I might actually believe what you say if you could maybe offer some actual proof of any one of the following but I suspect you can't and instead will go full retard.
1. How it is physically possible for your software to enumerate all possible hosts (about 6x10^98) in a single domain, as any script can simply generate any random valid host name and add that to a valid domain name thus forcing you to have to block all possible hosts in a single domain to block that domain?
2. How a hosts file can stop inbound connections?
3. That the Chinese actually did copy you instead of implementing old, simple, and obvious ideas entirely on their own, and the article from The Register you keep posting is not proof or evidence as no where does it mention you, or your work that you admit to copying (porting) from someone else first.
It is my understanding that Meltdown is Intel only, Spectre affects AMD/ARM/Intel (though not the same impact). I don't believe either of these exploits affect POWER or SPARC. Basically Meltdown is caused by being overly aggressive in that it does not check permissions to access -- until after it has moved it to cache, AMD checks this before. Using this and the ability to get timing information (only really needed for debugging) - a clever algorithm can basically access and piece together kernel (protected data) on the processor from user space processes. To me if one architecture has issues with something and all others don't it leads me to the conclusion that it is an architectural (CPU) design defect.
I am not familiar with the internals of it and it has been a good 30+ years since I have written x86 assembly code (and I am sure it has changed a lot, but they do keep backwards compatibility). Memory segmentation in Intel chips is a legacy that dates back to not being able to address the entire memory space because the limitation of memory being larger than addressable space due to the limitations of 16 bits. The memory had to be addressed by using a segment register and then offset from that register (a segment at that time would be limited to 64K). It was never designed as a way to protect the kernel address space. This memory addressing scheme is both costly and reduced the ability to usefully use the address space. Today 64 bit processors can address 16 exabytes, and the segmentation is a legacy left over from the early days. Use of segmented memory to protect the kernel is IMHO a hack that only serves to duct-tape over the defect and the downside is that it affects performance. I thought most other architectures (that are not affected) -- have flat and not segmented memory?
I don't ask for free replacement, but as someone who has been looking to build a new machine for a couple years, I would now like to know when we can expect new processors that are not venerable to any of these issues.
Everyone KNOWS antivirus slows you down - my program speeds you UP 2 ways (like no other of its kind).
See subject & lookup Tavis Ormandy & see if he found security issues in AVG (bet he did - he did in just about every AV there is) & it's due to complexity room for exploit & shitty coding!
* Tavis found NONE in my work (he'd have to find holes in the IP stack itself as it's solid & proven since 1973 iirc).
APK
P.S.=> My program uses ~10mb resident as 64-bit - less in 32-bit OS & 32-bit model about 5mb there (but has to load emulation DLL in Win64 OS for 32-bit) as it's resident protecting hosts BEYOND Windows' WFP/SFP ACL protection & only uses more processing host block data only - NOT EVEN A "NICE TRY", lol - screen YOU SAW @ it's download @ start64.com IS DURING BLOCKLIST PROCESSING dummy & w/ MY PERSONAL HOSTS DATA (much larger than you'll have in a decade++ & it took ME that long to get that much)...apk
It is about the protection barrier between the kernel data and user space melting down... Meltdown is as good as any other name.
.... scaring non-techies with technobabble is always fun. Besides, maybe I can convince my non-technical manager that I need a new computer since my old one melted down before the patch was installed.
If some non-techies get the wrong idea -- great -- I can have fun with that
Please stop spreading FUD like that. The only safe way to write software is with rust.
Fact: kernels and user level software written in rust is safe from sphinctr and meltdown attacks. C, C++, even javascript are unsafe. Rust.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Because a proper risk evaluation should have shown that this risk was too high to be acceptable.
Risk can be accepted, there is nothing special about that. When you drive to work in the morning, you implicitly accept the risk of a traffic accident. When a company does business, they accept a lot of risks, because without taking risks you can't do business.
But you evaluate your risks and rate them and any halfway sane evaluation of this risk would've broken even the most aggressive risk acceptance criteria.
Assorted stuff I do sometimes: Lemuria.org
See subject: Arth1's crushed faulty theory vs REALITY (stopped botnet plus your faulty premise) https://yro.slashdot.org/comments.pl?sid=11532533&cid=55833641/
Security pros on hosts = good security ahref=https://yro.slashdot.org/comments.pl?sid=11532533&cid=55815915/rel=url2html-5244https://yro.slashdot.org/comme...>
As do quoted /.ers https://hardware.slashdot.org/comments.pl?sid=11573413&cid=55871787/
Hosts do MORE 4 LESS vs. "so-called 'solutions'" slowing U or soldout (adblock) crippled by default or easily detected & BLOCKED addons or w/ security issues (antivirus/dns/routers) https://tech.slashdot.org/comments.pl?sid=11579085&cid=55885555/
APK
P.S.=> You lose & EAT YOUR WORDS - I'll let others judge for themselves (quoted /.ers did above AS DO RESPECTED SECURITY PROS)... apk
Patched Win7's FASTER! I noted it by 'feel' & saw I'm NOT ONLY ONE (formal tests on Win10 though) https://hardware.slashdot.org/comments.pl?sid=11574131&cid=55874785/ & everyone KNOWS 10 is slower!
I prepped for speed-hit (I'll take accuracy & security vs. speed) - but they did what I do in MY work!
(vs. security issue riddled "so-called 'solutions'" in remote DNS/Antivirus/routers making you slower OR 'souled-out' solutions in addons (adblock crippled to NOT do 1 job (far short of what hosts do for speed/security/reliability))):
APK Hosts File Engine 10++ SR-1 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/
APK
P.S.=> Making you FASTER & SAFER (for less & FOR FREE as I do)... apk
See subject: That lunatic is stalking me all over this forums as you saw & I just blow him away as you said via this https://bsd.slashdot.org/comments.pl?sid=11579585&cid=55888869/ & he freaks out spouting "phantasy theories" I totalled as you saw too with reality by stopping a botnet + destroying his 'idea' easily, lol!
* The UNIDENTIFIABLE anonymous nutjob doing it is a whacko loon no questions asked - no proof for his ideas but I have VERIFIABLE TONS for mine (/.ers, security pros, fact).
APK
P.S.=> He has mental issues, no doubt about it (not even sane enough to admit he lost right off the bat & everytime as all I have to do is show the link above, lol)... apk
There should be at least some attempt at reparations. Any processor currently being manufactured (3 years or younger) -- you would have the option of opting to get a replacement for the CPU if it is socketed by sending it into Intel (or taking it to a service centre of Intel's choosing to replace) and then getting a fixed CPU (probably timeline at least 9 months). Manufacturers could opt to replace the board at cost with new CPUs for computers that are currently in use. If you opt to keep it you would get a reimbursement of about 25% of the tray price of the CPU - which would be funnelled through manufacturers/retailers.
I think you would find that a small minority would opt to have the CPU replaced or the board replaced -- costing much less than what might be feared. It would however give the impression that the manufacturer (Intel) stands behind their products.
Sorry retard APK you can't provide proof.
So instead Alexander Peter Kowalski posts as AC and doesn't sign it to make it look like he has some support.
Go is probably safer.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
Bad form there APK.
You really shouldn't post replies to your self to make it look like someone supports you.
I see you can't actually address any point I made to defend your retard work.
Also I am not the mentally ill one as I don't post easily refuted lies, threaten people, or go full retard, like Alexander Peter Kowalski does.
I just point out the fallacies with your statements.
If I was as dumb as you claim then you shouldn't have any problem providing actual proof to refute my statements but instead the best you can offer is more BS.
I guess Alexander Peter Kowalski really is the mentally deficient one here.
Also lots of people like to make fun of you, as evident by the number of troll posts and posts pretending to be you that aren't mine.
Finally I don't sit there and keep spamming the same posts over and over like the spammer Alexander Peter Kowalski does.
IBM is releasing firmware, AIX, and Linux updates for POWER systems to address something but they haven't clearly stated if it's for Meltdown, Spectre, or both.
Intel cheated for performance
I don't know if you've looked at any processor design since the 386, but they all cheat for performance. 95% of the die area of a modern processor is things that cheat for performance. Most of that is caches, that cheap by pretending that main memory is faster than it really is.
I am TheRaven on Soylent News
And I'd be happy too if you were selling me beef at $0.50/pound. Even if you told me you weren't washing out the containers every single time and those sorts of time savings were why the beef were so cheap. Until, of course, it turns out that people weren't washing their hands and failing to wear gloves all the time.
This isn't some kind of secret thing that Intel does. They announced it with great fanfare in the '90s and had a bunch of tech news articles about how clever it is. None of the people who are now saying 'bad Intel sold me a thing that I didn't know was insecure but they should have done' came forward to say 'no, please don't do this (or at least let us turn it off) because it's probably insecure'. They all said 'Wow, Intel has made system calls cheaper, that's great!'. Including Linus, who I seem to recall complained in the late '90s about how much slower system calls were on AMD than Intel.
PS - STEALTHMEM: System-Level Protection Against Cache-Based Side Channel Attacks in the Cloud [usenix.org] from 2012 and it sounds like much better performance costs compared to KAISER, although not being a security researcher I have no idea if this would be sufficiently to protest against speculative execution as well.
STEALTHMEM is a protection against a different kind of timing attack and wouldn't protect against Meltdown or Spectre. A huge family of similar mitigations have been proposed, which partition the cache for different security domains. The problem with all of them is that they lead to inefficient cache usage: if one process is memory bandwidth limited and the other is CPU-bound, then this will slow down the bandwidth-limited process a lot, whereas sharing the cache would let it run faster without slowing down the CPU-bound one.
In this case, the attacks use a value that is already in the cache to speculatively do something data-dependent that is measurable, letting you determine what that value was even though you shouldn't have access to it. There are a lot of possible side channels that can be used with this general category of attack. The simplest is to do a data-dependent branch to either a location that's in the cache or one that isn't. Alternatively, doing a data-dependent branch to a divide or an add instruction will give you timing data. There are a bunch of Spectre-like attacks that some of the mitigations won't cover.
I am TheRaven on Soylent News
Nobody can die from this? What about all those workstations and computers in hospitals that run Intel.
What about them? The odds of this flaw actually resulting in a patient fatality are vanishingly small and there have been ZERO proven instances of harm to any patient of any kind. Compare with numerous known and proven fatalities from Takata airbags. Don't get me wrong, if patients actually are harmed by this it makes it a whole different ballgame but that's simply not what has happened here. You are reaching for hypothetical failure modes that haven't been shown to exist in the real world.
This is another reason I grow weary of replacing humans with computers. We are dumbing down ourselves and allowing computers to take over every task we deem as mundain.
An idiotic argument if I ever heard one. If you think computers and automation are a bad thing, I'd suggest slashdot isn't the place for you to hang out. Go find some Amish people to commiserate with.
Sounds like timing is the thing that doesn't need to cross security boundaries. Timing itself can be inferred.
One of the countermeasures for sandbox environments is to lower the timing resolution but this only lowers the rate at which data can be recovered.
See subject & you can't help but fail https://bsd.slashdot.org/comments.pl?sid=11579585&cid=55888429/ & don't bullshit me:
All you DO is stalk me by UNIDENTIFIABLE anonymous posts you pitiful little "ne'er-do-well" do-nothing loser
HOWEVER - I like it - you ALWAYS SCREWUP vs. me! ... & when you were asked if you had done a damn thing in computing you had ZERO TO SHOW FOR YOURSELF (but I can by truckloads) - YOU = A HUMAN FAIL - that's YOUR 'equation'
* RoTfLmAo @ U Mr. erroneous hypothesis based on FAULTY premise (unreality of even trying to create & store 4++ billion hostnames let alone to MANAGE THEM) + tons of other mistakes I point out here https://bsd.slashdot.org/comments.pl?sid=11579585&cid=55885757/ on NoScript (does less wildcard or not), DNS (tons of security issues & uses FAR more vs. hosts & is slower) + security pros & even /.ers quoted supporting me which you say they don't? LMAO - bullshit & I have proof unlike YOUR SORRY ASS (you do-nothing fool).
APK
P.S.=> I dusted the hell out of you easily many times shown in links above & you just added yet ANOTHER one in your blunder on memory usage of my program (eats more when processing like any program but NOT when resident (easily 1/4 of total ANY security issue riddled antivirus does in .exe + services & data in memory))... apk
Nope, AMD pays a higher penalty on system calls, though they mitigate this to some extent by having shorter and narrower pipelines.
How is that? Checking for permissions before speculation costs hardware and power but not speculating a path which is not going to be used anyway is hardly going to increase latency and saves the power which would otherwise be used and the cost of any memory transactions.
System calls involve a lot of microcode and other functions so it is not surprising they have a high and different cost between processors.
That meeting there in late 2013 signalled a sea change at Intel to many of us who were there.
Well maybe it was, but these problems predate 2013. Guess the "validation" that was happening in the 18 years between 1995 and 2013 didn't amount to much.
The timeline fits with things Bob Colwell said about changes for the worse in Intel's management just before he left Intel.
The bug I can understand. I am more upset about Intel's disingenuous PR statements which conflate different exploits making it seem that their main competitor is no better.
For once I am happy about Intel's excessive market segmentation; it convinced me to go with AMD after the Pentium 4.
After Vault 7, is very hard to believe that there is a "bug" that allow someone to pull data out of your CPU without leaving a single trace.
My prog eats more if processing data NOT if resident protecting hosts https://bsd.slashdot.org/comments.pl?sid=11579585&cid=55888429/ (easily 1/4 of security issue riddled antivirus .exe + services, drivers & data in memory)
Your FAULTY premise trying to create & store 4++ billion hosts https://yro.slashdot.org/comments.pl?sid=11532533&cid=55833641/ FAILS!
NoScript (does less vs. hosts & inefficiently/redundantly vs. 3rd party script) https://developers.slashdot.org/comments.pl?sid=11549257&cid=55843151/
DNS (security issues galore & remotely is slower + more complexity for exploit) https://tech.slashdot.org/comments.pl?sid=11579085&cid=55885555//
APK
P.S.=> security pros say hosts = good security https://developers.slashdot.org/comments.pl?sid=11549257&cid=55839269/ /.ers quoted support me https://hardware.slashdot.org/comments.pl?sid=11573413&cid=55871787/
My prog eats more if processing data NOT if resident protecting hosts https://bsd.slashdot.org/comments.pl?sid=11579585&cid=55888429/ (easily 1/4 of security issue riddled antivirus .exe + services, drivers & data in RAM)
Your FAULTY premise trying to create & store 4++ billion hosts https://yro.slashdot.org/comments.pl?sid=11532533&cid=55833641/ FAILS!
NoScript (does less vs. hosts & inefficiently/redundantly vs. 3rd party script) https://developers.slashdot.org/comments.pl?sid=11549257&cid=55843151/
DNS (security issues galore & remotely is slower + more complexity for exploit) https://tech.slashdot.org/comments.pl?sid=11579085&cid=55885555//
APK
P.S.=> security pros say hosts = good security https://developers.slashdot.org/comments.pl?sid=11549257&cid=55839269/ /.ers quoted support me https://hardware.slashdot.org/comments.pl?sid=11573413&cid=55871787/
From ArsTechnica:
"While Intel systems are the ones known to have the defect, they may not be the only ones affected. Some platforms, such as SPARC and IBM's S390, are immune to the problem, as their processor memory management doesn't need the split address space and shared kernel page tables; operating systems on those platforms have always isolated their kernel page tables from user mode ones."