Personal computing discussed
Moderators: renee, Flying Fox, morphine
Bauxite wrote:Honestly though the best policy is you have computer(s) just for surfing and it can't connect in any meaningful way (shares, casual file transfer, etc) to computers you care about. Its hard because you have to change your habits. You are the biggest security threat.
Glorious wrote:Given how Intel's been talking though, that could merely be them saying that they will be including microcode like they have for the old chips with the news ones from the outset
...which doesn't really mean much of anything...
chuckula wrote:Since Meltdown could not be fixed by microcode there definitely are some real hardware changes in there.
Intel wrote:SANTA CLARA, Calif., Jan. 4, 2018 — Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero.
chuckula wrote:The Spectre v2 mitigations might be microcode or hardware changes + microcode.
Glorious wrote:chuckula wrote:Since Meltdown could not be fixed by microcode there definitely are some real hardware changes in there.
You misunderstand.
I'm going by what Intel has officially said here (as, you know, I *explicitly* said previously):
https://newsroom.intel.com/news-release ... -exploits/
Intel wrote:SANTA CLARA, Calif., Jan. 4, 2018 — Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero.
Intel blatantly and publicly stated that microcode updates for "all types" of their chips will "immunize" against both exploits.
Thus, since Intel has previously said that microcode can render their products immune in the past, they equally could be making the same statement about the future.chuckula wrote:The Spectre v2 mitigations might be microcode or hardware changes + microcode.
The former is far, far more likely.
SANTA CLARA, Calif., Jan. 4, 2018 — Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero.
chuckula wrote:It said "updates". The word "microcode" never showed up in that quote. An "update" can certainly be a software update like the Linux KPTI infrastructure that was a software fix for Meltdown. Or it could be a combination of microcode + software to fix Spectre. As cited in Intel's official announcement, newer chips have hardware mitigation for Meltdown that's clearly something new because if there was a simple microcode switch that would have fixed Meltdown, Intel definitely would have flipped it on instead.
Intel wrote:We have redesigned parts of the processor to introduce new levels of protection through partitioning that will protect against both Variants 2 and 3. Think of this partitioning as additional “protective walls” between applications and user privilege levels to create an obstacle for bad actors.
While Variant 1 will continue to be addressed via software mitigations, we are making changes to our hardware design to further address the other two. We have redesigned parts of the processor to introduce new levels of protection through partitioning that will protect against both Variants 2 and 3. Think of this partitioning as additional “protective walls” between applications and user privilege levels to create an obstacle for bad actors.
Glorious wrote:Krzanich specifically says hardware here
Actually that was I *MEANT* to cite, and then I quote CHUCKULA as the quote from it.
Wow.
Let me fix my post.
Glorious wrote:EDIT: to make this more clear, I'm not coming into this out of the woods like a babe: I read the linux mailing list and Linus Torvalds was screaming about how Intel was all but saying in their patches (which were also all caps GARBAGE etc... according to him) that Intel were never going to fix this in hardware. That wasn't even three months ago.
chuckula wrote:With all due respect to Torvalds, his time long long ago at Transmeta and his reaction to this entire affair shows more about his ignorance of hardware design than anything else. I'm especially amused by his "OMG THESE BUGS ARE SO OBVIOUS" rants when he's been more than happy to accept the performance gains from speculative instruction over the years. If these bugs were so "obvious" then Torvalds should have been telling us all about them 16 years ago when he was at Transmeta and could have really helped his cause. Except he didn't. Because for all his bluster these bugs are clearly not that obvious... or else ARM wouldn't have gone out of its way to introduce Meltdown into its one and only "high performance" core design that's just beginning to hit the market this year.
chuckula wrote:As for your interpretation of what Torvalds was complaining about: There's absolutely no reason that Meltdown can't be fixed in hardware AND Intel continues to use and refine KPTI in the Linux kernel for use with future CPUs, even if Meltdown doesn't affect those CPUs. If you look at what KPTI does, it's actually a very nice security architecture that helps to enforce separation between kernel & userspace more strictly. I don't expect KPTI to just disappear after newer CPUs with Meltdown hardware fixes come to market.
chuckula wrote:Intel continues to use and refine KPTI in the Linux kernel for use with future CPUs
Glorious wrote:
Intel now dictates linux kernel development? Intel "uses" a particular feature of the kernel? Yes, if the kernel developers allow for it, Kconfig for it, or I patch it in myself, sure. But what does that have to do with Intel? I mean, yes, Intel can patch literally anything they like, but if it isn't committed to mainline or whatever...?
Unless you are talking about intel cpus USED BY INTEL, do you even realize what you are saying here?
JBI wrote:I'm sure Intel has a lot of input, if not actual devs who contribute code to the Linux kernel.
chuckula wrote:Oh please, let's ratchet the clearly disingenuous histrionics down about 100 notches or so. Unless you at least want to be consistent and accuse AMD of hijacking the Linux kernel the next time one of their developers sends in a driver patch. It's called an "open source" project. Intel is actually the #1 organizational contributor to the kernel. They can submit software patches. It's not histrionic fake-outrage, it's called completely ordinary.
chuckula wrote:As for any alleged "personal attacks" on Torvalds... for somebody who claims to read the LKML you sure have a strange definition of what constitutes a "personal attack" while reading Linus's emails.
Welch wrote:Glorious, I'm curious why exactly you think it is more likely to be just a microcode patch.
Welch wrote:Software - You can consider this anything that can be programmed to the hardware. This should include any program that may be a payload intended to make permanent changes
Welch wrote:Hardware - Physical components, as simple as that.
Welch wrote:I think from what you and Chuckla quoted, it's pretty clear that Intel is stating Hardware or physical changes for future chips, not a firmware/micro code update only. I mean we can all guess at what Intel really means *wink wink, nod nod*, but I don't see any reason to doubt hardware changes.
freebird wrote:Intel muddy the "hardware fix" waters with this information...
https://software.intel.com/sites/defaul ... ations.pdf
Which isn't really a fix, per se, but a flag to tell the processor not to speculatively execute branch predictions (in simpler terms)
freebird wrote:If this is the "hardware" fix, Intel can successfully claim they are making a hard fix in the processors without actually "fixing" the problem.
Legal semantics.
Glorious wrote:Welch wrote:Glorious, I'm curious why exactly you think it is more likely to be just a microcode patch.
Because, without slipping the schedule, how did they make serious changes to the actual silicon for a chip that was taped out roughly around when Intel was first notified of this problem (June 2017).
Remember, they goofed the initial microcode patch, but they're not even remotely gun-shy about producing new masks etc... without adjusting their launch dates in the slightest?
How is that possible?
Glorious wrote:Fair question, if the chips are already tapped out, then yes, I'd consider it software because they clearly aren't doing any hardware changes. A hardware change could include something like how AMD/Intel disable cores on modern CPUs (not just disabling via microcode)
Again, no. It is not that simple.
The explanation for this is simple: If Intel disabled the microcode update facility but deployed the most recent microcode currently publicly available, viola, what was software under your dichotomy becomes hardware. And, I must add, the transition occurred via Intel's unilateral discretion.
That is, Intel just decided what is hardware versus software according to your metric.
Which, as I hope you now see, is analogous to what I am saying they are actually doing right now.
Welch wrote:I'm not sure I can agree on that counting as making something hardware. If Intel is simply closing off future "Consumer" update ability via a final microcode update, I don't see how that is considered hardware. This is assuming they don't have a way to re-activate that ability or do an update in house after that code was applied. If you write code in a program that essentially renders the program unreachable or changeable, then I'd hardly call that hardware.
Glorious wrote:Welch wrote:I'm not sure I can agree on that counting as making something hardware. If Intel is simply closing off future "Consumer" update ability via a final microcode update, I don't see how that is considered hardware. This is assuming they don't have a way to re-activate that ability or do an update in house after that code was applied. If you write code in a program that essentially renders the program unreachable or changeable, then I'd hardly call that hardware.
Oh, I was simply using that as an extreme example to illustrate how flexible the notion of "hardware" versus "software" can become upon Intel's unilateral whim.
I do not believe that Intel is actually planning on doing anything remotely like that.
LiamC wrote:Looks like Intel will not be patching Bloomfield, Clarksfield, Gulftown, Harpertown, Jasper Forest, Penryn, Wolfdale and Yorkfield
https://www.itnews.com.au/news/intel-wo ... ips-488176
https://newsroom.intel.com/wp-content/u ... idance.pdf